項(xiàng)目一部署kubernetes集群

1.選擇題

(1)D(2)B(3)B(4)A(5)C

2.填空題

(1)Kube-proxyvkubeIet

(2)Etcd

(3)Iptables或者IPVS

(4)容器運(yùn)行時(shí)

(5)NerdctI

3.簡答題

(1)簡述Containerd容器引擎的特點(diǎn)

containerd是一個(gè)輕量級的容器運(yùn)行時(shí)引擎，具備如下特點(diǎn)。

(D與容器編排平臺(tái)集成

containerd作為容器編排系統(tǒng)(如Kubernetes)的基礎(chǔ)組件，用于管理容器的生命周期。它提

供了符合OCI(OpenContainerInitiative,開放容器倡議)標(biāo)準(zhǔn)的接口，可以集成到不同的容器

編排平臺(tái)中。

(2)輕量級和高性能

由于containerd的設(shè)計(jì)目標(biāo)是輕量級和高性能，它相比于一些功能更為復(fù)雜的容器引擎，如

Docker,具有更小的資源消耗和更高的運(yùn)行效率。

(3)模塊化架構(gòu)(此處表述改成以下文字)

containerd的架構(gòu)設(shè)計(jì)模塊化，它由多個(gè)組件組成，包活容器運(yùn)行時(shí)、鏡像服務(wù)、快照管理、

網(wǎng)絡(luò)管理等。

(4)簡化的功能集

containerd提供了一組基本的功能，如容器的創(chuàng)建、啟動(dòng)、停止、刪除等，而且它的設(shè)計(jì)更加

注重穩(wěn)定性和可靠性。相比于Docker這樣功能更為豐富的容器引擎，containerd更專注于容器生命

周期的管理。

(5)開源和社區(qū)支持

containerd是一個(gè)開源項(xiàng)目，擁有一個(gè)活躍的社區(qū)，用戶可以自由地獲取源代碼、提交問題和

貢獻(xiàn)代碼，containerd在容器技術(shù)領(lǐng)域具有較好的可持續(xù)性和發(fā)展?jié)摿Α?/p>

(2)簡述Kubernetes架構(gòu)和各個(gè)組件功能

Kubernetes采用主從分布式架構(gòu)，由Master控制節(jié)點(diǎn)(也稱管理節(jié)點(diǎn))和Node工作節(jié)點(diǎn)組成，

由控制節(jié)點(diǎn)發(fā)出命令，然后Node工作節(jié)點(diǎn)完成任務(wù)。Kubernetes集群的架構(gòu)如圖1-27所示。：修改

圖1如下)

圖1Kubernetes的架構(gòu)

上圖可以改為Master控制節(jié)點(diǎn)、Node工作節(jié)點(diǎn)'去掉Controller-Manager中的一

（1）Master

要對集群資源進(jìn)行調(diào)度管理，Master需要安裝APIServer（應(yīng)用程序編程接口服務(wù)器）、

ControllerManager（控制器管理服務(wù)）、Scheduler（調(diào)度服務(wù)器）、Etcd（集群狀態(tài)存儲(chǔ)）、Kubectl

等組件。

①APIServer

APIServer（應(yīng)用程序接口服務(wù)）主要用來處理REST請求操作，確保它們生效，執(zhí)行相關(guān)業(yè)務(wù)

邏輯，更新Etcd存儲(chǔ)中的相關(guān)對象。APIServer是所有REST命令的入口，它的相關(guān)結(jié)果狀態(tài)將被

保存在Etcd存儲(chǔ)中；APIServer同時(shí)是集群的網(wǎng)關(guān)，客戶端通過APIServer訪問集群。（刪除后邊

這句）客戶端需要通過認(rèn)證，并使用APIServer作為訪問NodePod以及Service的通道。

②ControllerManager（以下表述統(tǒng)一修改）

ControllerManager用于管理和控制Kubernetes集群，執(zhí)行多種生命周期管理功能，如命名

空間的創(chuàng)建和生命周期管理、事件垃圾收集、已終止Pod的垃圾收集、級聯(lián)刪除垃圾收集以及Node的

垃圾收集。同時(shí)，它還負(fù)責(zé)執(zhí)行API業(yè)務(wù)邏輯，例如Pod的彈性擴(kuò)容，提供自愈能力、擴(kuò)展、應(yīng)用生

命周期管理、服務(wù)發(fā)現(xiàn)'路由和服務(wù)綁定等功能。Kubernetes默認(rèn)提供多種控制器管理服務(wù)，包括

ReplicationController（副本控制器）、NamespaceController（命名空間控制器）、Service

Controller（服務(wù)發(fā)現(xiàn)控制器）等。

③Scheduler

Scheduler組件為容器芻動(dòng)選擇主機(jī)，依據(jù)請求資源的可用性、服務(wù)請求的質(zhì)量等約束條件，

Scheduler監(jiān)控未綁定的Pod,并將其綁定至特定的Node。

④Etcd

Kubernetes默認(rèn)使用Etcd作為集群整體存儲(chǔ)，Etcd是一個(gè)簡單的分布式鍵值對存儲(chǔ)數(shù)據(jù)庫，

用來共享配置和服務(wù)發(fā)現(xiàn)。集群的所有狀態(tài)都存儲(chǔ)在Etcd中，Etcd具有監(jiān)控的能力，因此當(dāng)信息發(fā)

生變化時(shí)，Etcd就能夠快速地通知集群中相關(guān)組件。

⑤KubectI

Kubectl可以安裝在Master上，也可以安裝在Node上，它用于通過命令行與APIServer交互，

進(jìn)而對Kubernetes進(jìn)行操作，實(shí)現(xiàn)在集群中對各種資源的增刪改查等操作。

(2)工作節(jié)點(diǎn)(Node)

Node是真正的工作節(jié)點(diǎn)，運(yùn)行容器應(yīng)用，Node工作節(jié)點(diǎn)上需要運(yùn)行Kubelet、容器引擎、

Kube-Proxy(kube代理)等組件。

①Kubelet

Kubelet是Kubernetes中最主要控制器，負(fù)責(zé)驅(qū)動(dòng)容器執(zhí)行層和整個(gè)容器生命周期。

在Kubernetes中，Pod是基木的執(zhí)行單元，它可以包括多個(gè)容器和存儲(chǔ)數(shù)據(jù)卷，將一個(gè)或者多

個(gè)容器打包成單一的Pod應(yīng)用，由Master負(fù)責(zé)調(diào)度。在Node節(jié)點(diǎn)上由Kubelet啟動(dòng)Pod內(nèi)的容器或

者數(shù)據(jù)卷，Kubelet負(fù)責(zé)管理Pod、容器'鏡像'數(shù)據(jù)卷等，實(shí)現(xiàn)集群對工作節(jié)點(diǎn)的管理，并將容器

運(yùn)行狀態(tài)匯報(bào)給APIServer,,

②容器引擎

每一個(gè)Node工作節(jié)點(diǎn)都會(huì)運(yùn)行容器引擎，負(fù)責(zé)下載鏡像'運(yùn)行容器。Kubernetes本身并不提供

容器引擎環(huán)境，但提供了接口，可以插入所選擇的容器引擎環(huán)境，本書采用containerd作為

Kubernetes的容器引擎。

③Kube-Proxy

在Kubernetes中,KubeProxy負(fù)責(zé)為Pod創(chuàng)建代理服務(wù),KubeProxy通過IptabIcs或者IPVS

規(guī)則將客戶端訪問請求路由我后端的Pod。

項(xiàng)目二使用集群核心資源部署服務(wù)

1.選擇題

(1)A(2)A(3)B(4)A(5)B

2.填空題

(1)Pod

(2)Service服務(wù)發(fā)現(xiàn)

(3)一次性任務(wù)

(4)周期性任務(wù)

(5)守護(hù)型

3.簡答題

一簡述Kubernetes的核心資源。

在Kubernetes中，核心資源是集群的基礎(chǔ)設(shè)施和運(yùn)行應(yīng)用程序的基本構(gòu)件。這些核心資源定義

了應(yīng)用程序的部署、網(wǎng)絡(luò)、存儲(chǔ)和配置等方面，使得應(yīng)用程序能夠在Kubernetes集群中可靠地運(yùn)行

和擴(kuò)展。以下是一些常用的Kubernetes資源類型。

(1)Pod

Pod是Kubernetes中最小的部署單兀，在一個(gè)Pod中，通常會(huì)有一個(gè)應(yīng)用程序容器，以及輔助

日志收集器、監(jiān)控代理等輔助容器，這些容器共享Pod網(wǎng)絡(luò)和存儲(chǔ)資源，共同協(xié)作來完成特定任務(wù)，

以下是一些關(guān)于Pod的重要特性。

①共享網(wǎng)絡(luò)命名空間

Pod內(nèi)的所有容器共享相同的網(wǎng)絡(luò)命名空間，它們可以通過localhost直接進(jìn)行通信，無須額外

的網(wǎng)絡(luò)配置。

②共享存儲(chǔ)卷

Pod可以掛載一個(gè)或多個(gè)存儲(chǔ)卷，這些存儲(chǔ)卷可以被Pod中的所有容器訪問，容器之間可以共享

數(shù)據(jù)，數(shù)據(jù)可以在容器重啟時(shí)實(shí)現(xiàn)持久化。

③生命周期管理

Pod有自己的生命周期，它可以被創(chuàng)建、啟動(dòng)、停止和刪除。當(dāng)Pod被刪除時(shí)，其中的所有容器

也會(huì)被一并刪除。

④彈性擴(kuò)展

通過創(chuàng)建多個(gè)Pod實(shí)例并將它們放置在不同節(jié)點(diǎn)上，可以實(shí)現(xiàn)應(yīng)用程序的水平擴(kuò)展和負(fù)載均衡。

⑤資源調(diào)度

Kubernetes調(diào)度器負(fù)責(zé)將Pod調(diào)度到集群中的不同節(jié)點(diǎn)上，根據(jù)資源需求、節(jié)點(diǎn)負(fù)載等因素進(jìn)

行智能調(diào)度。

⑥監(jiān)控和日志

Kubernetes提供了豐富的監(jiān)控和日志功能，可以對Pod進(jìn)行實(shí)時(shí)監(jiān)控和日志收集，幫助診斷和

調(diào)試應(yīng)用程序問題。

(2)Deployment控制器

Deployment是Kubernetes中的一種資源對象，用于管理Pod的部署和更新。它提供了一種聲明

性方式來定義應(yīng)用程序的期望狀態(tài)。并確保集群實(shí)際狀態(tài)與之一致(刪除這句)，Deployment使用

ReplicaSet來管理Pod的副本，支持滾動(dòng)更新和回滾操作，Deployment控制器的特點(diǎn)如下。

①聲明性配置

Deployment可以使用聲明性的Yami文件來定義應(yīng)用程序的部署配置，包括Pod模板、副本數(shù)量

等信息。這種方式更加清晰、可維護(hù)，并且支持版本控制。

②自動(dòng)化部署

Deployment可以自動(dòng)創(chuàng)建和管理Pod副本，確保它們按殂定義的配置進(jìn)行部署，用戶只需定義

期望的狀態(tài)，Kubernetes會(huì)按照期望的狀態(tài)自動(dòng)處理。

③滾動(dòng)更新

Deployment支持滾動(dòng)更新，可以在不中斷服務(wù)的情況下逐步將新版本的Pod部署到集群中，用

戶可以定義更新策略，如并行更新的最大副本數(shù)、延遲等。

④回滾操作

如果新版本的Pod部署后出現(xiàn)了問題，Deployment可以快速回滾到之前的穩(wěn)定版本，這種回滾

操作不會(huì)中斷服務(wù)。

⑤擴(kuò)展性和高可用性

Deployment可以輕松地?cái)U(kuò)展應(yīng)用程序的副本數(shù)量，滿足不同的負(fù)載需求，還可以與其他

Kubernetes資源，如HorizontalPodAutoscaler結(jié)合使用，實(shí)現(xiàn)自動(dòng)水平擴(kuò)展°

⑥版本管理

Deployment可以管理應(yīng)用程序的不同版本，每個(gè)版本都對應(yīng)一個(gè)DepIoyment對象，用戶可以查

看和管理應(yīng)用程序的歷史部署狀態(tài)。

(3)Service服務(wù)發(fā)現(xiàn)

Service用于定義一組Pod的訪問方式，提供服務(wù)發(fā)現(xiàn)和負(fù)載均衡功能，Service允許用戶將一

組具有相同功能的Pod組織成一個(gè)邏輯單元，為它們分配一個(gè)穩(wěn)定的虛擬IP地址和DNS(域名解析)

名稱，用戶或者其他應(yīng)用程序可以通過這些標(biāo)識來訪問Pod中的容器服務(wù)。

Service將請求均衡地分發(fā)到后端Pod實(shí)例上，以實(shí)現(xiàn)負(fù)載均衡和高可用性。Kubernetes使用內(nèi)

置的負(fù)載均衡器來管理Service,確保請求能夠均衡地分發(fā)到各個(gè)Pod實(shí)例上，提高應(yīng)用程序的性能

和可靠性。

①Service服務(wù)實(shí)現(xiàn)的機(jī)制

由于Pod存在生命周期，有銷毀，有重建，無法提供一個(gè)固定的訪問接口給客戶端，而且用戶不

可能記住所有同類型的Pod地址，這樣Service資源對象就出現(xiàn)了。Service基于標(biāo)簽選擇器將一組

Pod定義成一個(gè)邏輯單元，并通過自己的IP地址和端口調(diào)度代理請求到組內(nèi)的Pod對象，如圖2-2

所示，它向客戶端隱藏了真實(shí)處理用戶請求的Pod資源，就像是由Service直接處理并響應(yīng)一樣。

Service對象的IP地址也稱為ClusterIP,它位于為Kubernetes集群配置指定的IP地址范圍之

內(nèi)，是虛擬的IP地址，它在Service對象創(chuàng)建之后保持不變，并且能夠被同一集群中的Pod資源所

訪問。Service端口用于接受客戶端請求，并將請求轉(zhuǎn)發(fā)至后端的Pod應(yīng)用的相應(yīng)端口，這樣的代理

機(jī)制，也稱為端口代理。

Service對象的IP地址是虛擬地址，在集群內(nèi)部可以訪'可，無法響應(yīng)集群外部的訪問請求，解

決該問題的辦法是在單一的節(jié)點(diǎn)上做端口暴露或讓Pod資源共享工作節(jié)點(diǎn)的網(wǎng)絡(luò)命名空間，除此之外,

還可以使用NodePort類型的Service資源，或者是有7層負(fù)載均衡能力的Ingress資源。

②Service服務(wù)的實(shí)現(xiàn)原理

在Kubernetes集群中，每個(gè)Node工作節(jié)點(diǎn)運(yùn)行一個(gè)Kube-proxy組件，這個(gè)組件進(jìn)程始

線監(jiān)視著ApiScrvcr中有關(guān)Service的變動(dòng)信息，獲取任何一個(gè)與Scrvicc資源相關(guān)的變動(dòng)狀態(tài)，通

過Watch監(jiān)視，一旦有Service資源相關(guān)的變動(dòng)，Kube-proxy使用Iptables或者IPVS規(guī)則在當(dāng)前

node節(jié)點(diǎn)上實(shí)現(xiàn)資源調(diào)度，如圖2-3所示。

圖2-3服務(wù)發(fā)現(xiàn)工作原理

③Iptables代理模式

客戶端訪問ServiceIP時(shí)，ServiceIP根據(jù)Iptables的規(guī)則直接將請求轉(zhuǎn)發(fā)到各Pod上，因

為使用Iptables來完成轉(zhuǎn)發(fā)，也存在不可忽視的性能損耗，如果集群中存在上萬的Pod,那么Node

上的Iptables規(guī)則將會(huì)非常龐大，代理轉(zhuǎn)發(fā)的性能就會(huì)受影響。

④IPVS代理模式（以下內(nèi)容統(tǒng)改）

Kubernetes自1.9-alpha版本引入了IPVS代理模式，當(dāng)客戶端請求到達(dá)內(nèi)核空間時(shí)，IPVS根據(jù)

規(guī)則將請求轉(zhuǎn)發(fā)到各Pod上，Kube-proxy會(huì)監(jiān)視Service對象和后端Pod,確保IPVS狀態(tài)與期望

一致。

如果某個(gè)后端Pod發(fā)生變化，對應(yīng)的信息會(huì)立即反映到ApiServer上,而Kube-proxy通過Natch

（監(jiān)視）Etcd數(shù)據(jù)庫中的信息變化，將它立即轉(zhuǎn)為IPVS或者Iptables規(guī)則，這些動(dòng)作都是動(dòng)態(tài)和實(shí)

時(shí)的，如圖2-4所示。

圖中翻逐userspace（用戶空間）、kernelspace（內(nèi)核空間）

⑤Servie服務(wù)類型

ClusterIP：ClusterIPService是默認(rèn)的Service類型。ClusterIPService創(chuàng)建一個(gè)集群內(nèi)

部的虛擬IP,只有集群內(nèi)部的其他對象可以訪問該Savice。這種類型的Service對外部世界是不

可見的。

NodePort：NodePortService為每個(gè)Node節(jié)點(diǎn)在一個(gè)固定的端口上暴露Service。通過任何

Node節(jié)點(diǎn)的IP地址和該端口來訪問Service。NodePortService也會(huì)創(chuàng)建—ClusterIP,允許從

集群內(nèi)部訪問Serviceo

LoadBalancer：LoadBalancerService將外部負(fù)載均衡器(如云提供商的負(fù)載均衡器)流量引

導(dǎo)到集群中的Service。這種類型的Service通常在云環(huán)境中使用，通過公共IP地址向外部暴露服

務(wù)。

ExternalName：ExternaINameService允許將Service映射到集群外部的任意DNS名稱。當(dāng)集

群內(nèi)的應(yīng)用程序需要訪問集群外部的服務(wù)時(shí)，可以使用ExternalNameService。

Headless：HeadlessService是一種特殊類型的Service,它將DNS解析直接映射到其后端Pod

的IP地址，這對于需要直接訪問每個(gè)Pod的場景非常有用，通常應(yīng)用在集群部署有狀態(tài)服務(wù)時(shí)。

(4)VoIume數(shù)據(jù)卷

Volume存儲(chǔ)卷是用于持久化數(shù)據(jù)的抽象概念，它可以附加一個(gè)或多個(gè)容器到Pod中，Volumes提

供了在容器之間共享和存儲(chǔ)數(shù)據(jù)的機(jī)制，包括空目錄、主機(jī)路徑、網(wǎng)絡(luò)存儲(chǔ)(并列沒問題)等。

(5)Configmap和Secret

Configmap和Secret用于管理應(yīng)用程序的配置信息和敏感數(shù)據(jù)，configmap用于存儲(chǔ)鍵值對形式

的配置數(shù)據(jù)，而secret則用于存儲(chǔ)敏感信息，如密碼、令牌等。

(6)Namespace命名空間

Namespace是Kubernetes中用于將集群資源進(jìn)行邏輯隔離的機(jī)制，通過Namespace可以將不同

的資源分組到不同的命名空間中，以便進(jìn)行管理和控制訪問權(quán)限。

(7)Serviceaccount

Serviceaccount是用于身份驗(yàn)證和授權(quán)的實(shí)體，允許Pod與KubernetesAPI進(jìn)行交互并訪問其

他集群資源，每個(gè)Pod都會(huì)關(guān)聯(lián)一個(gè)Serviceaccount,用于確定其操作權(quán)限。

Kubernetes集群還包括一些其他的核心資源，當(dāng)使用時(shí)再進(jìn)行具體講解。

-簡述使用Yami創(chuàng)建資源的優(yōu)勢。

在生產(chǎn)環(huán)境下，使用Yami腳本方式部署應(yīng)用是一種常見做法，這種方式具有以下5個(gè)優(yōu)點(diǎn)。

(1)可維護(hù)性

Yami腳本可以輕松地保存在版本控制系統(tǒng)中，方便管理和跟蹤變更，確保對資源的修改有記錄

可查，也方便團(tuán)隊(duì)協(xié)作。

(2)可重復(fù)性

使用Yami腳本創(chuàng)建資源，可以輕松地重復(fù)部署相同的配置，確保在不同環(huán)境部署的一致性。

(3)可讀性

相對于其他編程語言或配置文件，Yami格式文本具備可讀性，團(tuán)隊(duì)成員更容易理解和修改配置。

(4)靈活性

Yami腳本支持豐富的語法，可以描述各種類型的資源和配置。

(5)自動(dòng)化部署

可以通過Yami腳本完成自動(dòng)化部署任務(wù)，提高部署的效率和可靠性。__________

項(xiàng)目三使用集群核心資源部署服務(wù)

1.選擇題

(1)B(2)A(3)A(4)B(5)A

2.填空題

(1)列出

(2)觀察

(3)修改

(4)命名空間級別綁定、集群級別綁定

(5)所有組

3.簡答題

-簡述命名空間的作用。

Kubernetes中的Namespace命名空間是一種用于將集群資源劃分為多個(gè)虛擬集群的方式，使不

同的團(tuán)隊(duì)或項(xiàng)目可以在同一個(gè)Kubernetes集群中獨(dú)立地工作，不會(huì)互相干擾。命名空間組織和管理

資源的優(yōu)勢有以下幾種。

(1)資源隔離

每個(gè)命名空間提供了一個(gè)獨(dú)立的資源作用域，同一集群中不同命名空間的資源是隔離的，一個(gè)命

名空間中的資源不會(huì)直接影響另一個(gè)命名空間中的資源。

(2)命名空間范圍內(nèi)唯一性

在同一個(gè)命名空間內(nèi)，資源的名稱必須是唯一的，可以在不同的命名空間中使用相同的名稱來標(biāo)

識不同的資源。

(3)資源配額

通過為每個(gè)命名空間設(shè)置資源配額，可以限制該命名空出?中可以使用費(fèi)源的數(shù)量。

(4)訪問控制

通過使用RBAC控制哪些系統(tǒng)賬戶或服務(wù)賬戶有權(quán)訪問特定命名空間中的資源。

(5)環(huán)境隔離

使用命名空間將開發(fā)'測試和生產(chǎn)環(huán)境分開，從而更好地管理不同環(huán)境中的資源。

二簡述RBAC中的角色、授權(quán)和角色綁定

RBAC是Kubernetes中常用的一種訪問控制方式，管理員通過定義角色和角色綁定控制用戶操作

集群資源的權(quán)限，包括以下重要內(nèi)容。

(1)角色

角色定義了用戶操作集群資源的權(quán)限，分為Role命名空間級別角色和ClusterRole集群級別角

色(所有命名空間)，在創(chuàng)建Role角色時(shí)，需要定義該角色對某個(gè)命名空間具有哪些權(quán)限，在創(chuàng)建

ClusterRole角色時(shí)，需要定義該角色對集群具備哪些權(quán)限。

(2)權(quán)限

權(quán)限用于指定角色對集群資源的操作范圍，以下是一些常用的權(quán)限。

get:允許用戶獲取資源的信息。

list:允許用戶列出資源的信息。

watch:允許用戶監(jiān)視資源的變化。

create:允許用戶創(chuàng)建資源.

update:允許用戶更新(修改)資源。

delete:允許用戶刪除資源。

patch:允許用戶通過patch操作對資源進(jìn)行局部更新。

exec:允許用戶執(zhí)行Pod內(nèi)的命令。

(3)RoleBinding(命名空間級別角色綁定)和ClusterRoleBinding(集群角色綁定)

在定義了角色后，就可以將用戶綁定到角色上，角色綁定包括以下2種。

RoleBinding：將命名空間角色綁定到系統(tǒng)用戶、組或者服務(wù)賬戶，授予用戶命名空間級別權(quán)限。

ClusterRoleBinding：將集群角色綁定到特定的用戶、組或者服務(wù)賬戶，授予用戶整個(gè)集群權(quán)限。

項(xiàng)目四使用集群核心資源部署服務(wù)

1.選擇題

(1)B(2)D(3)C(4)C(5)A

2.填空題

(1)節(jié)點(diǎn)

(2)污點(diǎn)

(3)NoExecute

(4)Pod、節(jié)點(diǎn)

(5)容忍性

3.簡答題

—簡述Scheduler調(diào)度器的工作過程。

Scheduler是Kubernetes中的默認(rèn)調(diào)度器，負(fù)責(zé)將新創(chuàng)建的Pod分配到集群的某個(gè)節(jié)點(diǎn)上。其

調(diào)度過程如下。

(1)用戶創(chuàng)建Pod

當(dāng)用戶提交Pod配置或通過其他方式創(chuàng)建Pod時(shí)，KubernetesAPI服務(wù)器會(huì)接收到該請求，并

將其保存到etcd中。

(2)調(diào)度器監(jiān)聽

調(diào)度器會(huì)監(jiān)聽API服務(wù)器中新創(chuàng)建的Pod,一旦有新的Poc需要調(diào)度,調(diào)度器就會(huì)觸發(fā)調(diào)度流程。

(3)篩選可調(diào)度節(jié)點(diǎn)

調(diào)度器首先會(huì)根據(jù)Pod的調(diào)度要求(如資源需求、節(jié)點(diǎn)選擇標(biāo)準(zhǔn)等)篩選出集群中符合條件的節(jié)

點(diǎn)，調(diào)度要求通常包括節(jié)點(diǎn)的資源可用性、污點(diǎn)和親和性等因素。

(4)評分節(jié)點(diǎn)

對于符合條件的節(jié)點(diǎn)，調(diào)度器會(huì)對它們進(jìn)行評分，為每個(gè)節(jié)點(diǎn)分配一個(gè)分?jǐn)?shù)。節(jié)點(diǎn)的評分考慮了

多種因素，包括節(jié)點(diǎn)的資源利用率、已部署Pod的數(shù)量、硬件特性等。

(5)選擇最佳節(jié)點(diǎn)

調(diào)度器會(huì)根據(jù)節(jié)點(diǎn)的評分選擇最佳的節(jié)點(diǎn)，如果有多個(gè)節(jié)點(diǎn)具有相同的最高分?jǐn)?shù)，調(diào)度器會(huì)應(yīng)用

其他策略來進(jìn)行選擇，例如負(fù)載均衡或隨機(jī)選擇。

(6)綁定Pod

一旦選擇了最佳節(jié)點(diǎn)，調(diào)度器會(huì)將Pod綁定到該節(jié)點(diǎn)上，并更新Pod對應(yīng)的調(diào)度狀態(tài)。

(7)更新API服務(wù)器

調(diào)度器會(huì)將更新后的Pod信息提交給KubernetesAPI服務(wù)器，以更新集群狀態(tài),并通知Kubelet

在選擇的節(jié)點(diǎn)上運(yùn)行該P(yáng)odo

(8)Kubelet執(zhí)行

Kubelet在被指定的節(jié)點(diǎn)上接收到Pod的調(diào)度請求后，負(fù)責(zé)拉取容器鏡像并啟動(dòng)Pod中的容器。

二簡述污點(diǎn)配置中effect的作用。

為Node節(jié)點(diǎn)配置污點(diǎn)的命令格式為KubectItaintnodes節(jié)點(diǎn)名稱key=value:effect,其中

key和value是由管理員根據(jù)實(shí)際場景定義的，effect是關(guān)鍵字，描述污點(diǎn)的作用，包括以下3種動(dòng)

作。

(1)NoSchedule(不調(diào)度)

表示K8s不會(huì)把Pod調(diào)度到具有該污點(diǎn)的Node節(jié)點(diǎn)上

(2)PreferNoSchedule(盡量避免調(diào)度)

表示K8s將盡量避免把Pod調(diào)度到具有該污點(diǎn)的Node節(jié)點(diǎn)上

(3)NoExecute(驅(qū)逐)

表示Kubernetec將不會(huì)把Pod調(diào)度到具有該污點(diǎn)的Node節(jié)點(diǎn)上，它不但影響Pod的調(diào)度，還會(huì)

影響已經(jīng)在節(jié)點(diǎn)上運(yùn)行的Pod,正在該節(jié)點(diǎn)運(yùn)行的Pod分為以下三種情況。

①Pod不能容忍污點(diǎn)

如果Pod不能容忍effect值為NoExecute的taint,那么Pod將馬上被驅(qū)逐。

②Pod能夠容忍污點(diǎn)

如果Pod能夠容忍effect值為NoExecute的taint,且在toleration定義中沒有指定

tolerationSeconds,則Pod會(huì)一直在這個(gè)節(jié)點(diǎn)上運(yùn)行。

③Pod配置了toIerationSeconds(容忍時(shí)間)

如果Pod能夠容忍effect值為NoExecute的taint,但是在toleration定義中指定了

tolerationSeconds,則toIerationSeconds表示Pod還能在這個(gè)節(jié)點(diǎn)J_繼續(xù)運(yùn)行的時(shí)間。

項(xiàng)目五使用集群核心資源部署服務(wù)

1.選擇題

(1)C(2)B(3)B(4)B(5)A

2.填空題

(1)ReadWriteOnce

(2)Retain

(3)AvaiIable

(4)解耦

(5)環(huán)境變量

3.簡答題

一簡述存儲(chǔ)卷的類型。

存儲(chǔ)卷(Volume)是用于持久化數(shù)據(jù)的一種抽象概念。它提供了一種方法，使容器能夠在不受宿

主機(jī)生命周期影響的情況下訪問和存儲(chǔ)數(shù)據(jù)。存儲(chǔ)卷可以與一個(gè)或多個(gè)容器進(jìn)行關(guān)聯(lián)，使它們鍍夠共

享和訪問相同的數(shù)據(jù)。

Kubernetes提供了多種類型的存儲(chǔ)卷，以滿足不同的需求和使用場景，以下是一些常見的存儲(chǔ)

卷類型。

(1)空目錄卷(EmptyDirVolume)

空目錄卷在Pod的生命周期內(nèi)存在，并且可以由Pod中的多個(gè)容器共享。它適合用于臨時(shí)數(shù)據(jù)的

存儲(chǔ)，當(dāng)Pod重啟或遷移時(shí)，其中的數(shù)據(jù)會(huì)丟失，在實(shí)際生產(chǎn)環(huán)境下很少使用。

(2)本地存儲(chǔ)卷(HostPathVolume)

本地存儲(chǔ)卷將主機(jī)操作系統(tǒng)上的目錄或文件掛載到Pod容器中。這種卷類型適用于需要與主機(jī)操

作系統(tǒng)進(jìn)行直接交互的場景，使用本地存儲(chǔ)卷會(huì)導(dǎo)致Pod在不同節(jié)點(diǎn)上的遷移困難，如果一個(gè)Fod固

定調(diào)度在一個(gè)工作節(jié)點(diǎn)，可以使用本地存儲(chǔ)卷持久化數(shù)據(jù)。

(3)網(wǎng)絡(luò)存儲(chǔ)卷(NetworkStorageVolume)

網(wǎng)絡(luò)存儲(chǔ)卷是通過將外部的網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)連接到Kubernetes集群中，為應(yīng)用程序提供可靠的持

久化存儲(chǔ)，有多種類型的網(wǎng)絡(luò)存儲(chǔ)卷可供選擇，其中一種常見的是NFS(NetworkFileSystem)卷.

NFS卷使用NFS協(xié)議連接到遠(yuǎn)程的NFS服務(wù)器，并將共享的文件系統(tǒng)掛載到Pod中的容器中，除了

NFS,還有其他的網(wǎng)絡(luò)存儲(chǔ)卷類型，如GlusterFS、Ceph等。在實(shí)際生產(chǎn)環(huán)境下，根據(jù)需求選擇適合

的網(wǎng)絡(luò)存儲(chǔ)卷類型。

(4)持久卷(PersistentVolume)

持久卷提供了一種將存儲(chǔ)資源與Pod解耦的方式，使得Pod能夠獨(dú)立于底層存儲(chǔ)技術(shù)，持久卷聲

明(PersistentVolumeClaim)用于請求和使用持久卷資源，這種卷類型支持各種外部存儲(chǔ)解決方

案,如NFS、Ceph等。

二簡述創(chuàng)建ConfigMap的兩種方法。

(1)編寫Yami腳本

在project5目錄下，創(chuàng)建文件為redis-cm.yamI,在文件中輸入以下內(nèi)容。

apiVersion:v1

kind:ConfigMap

metadata:

name:redis-cm

data:

redis-config:

bind0.0.0.0

port6380

以上Yami腳本創(chuàng)建了名字為redis-cm的ConfigMap資源，保存數(shù)據(jù)的鍵是redis-conf,值是

關(guān)于redis的的兩行配置，bind0.0.0.0表示監(jiān)聽本機(jī)的所有IP地址，port6380表示使用6380端

口提供服務(wù)。

(2)基于Yami文件創(chuàng)建ConfigMap

基于redis-cm.yamI文件，創(chuàng)建名稱為redis-cm的ConfigMap,如下所示。

[rootl^masterprojects]#kubectIappIy-fredis-cm.yamI

創(chuàng)建完成后，使用kubectIdescribe命令查看名稱為redis-cm的ConfigMap,結(jié)果如圖5-25

所示。

—nutterX#(1)?node，?nod*2^27.106*114217(1)??

[rootQmasterprojects]#kubect!describe-configmaps-redis-cm-

Name:redis-cm

Namespace:default

Labels:<none>

Annotations:<none>

Data

圖5-25查看ConfigMap保存的鍵值對數(shù)據(jù)

從結(jié)果中發(fā)現(xiàn)，名稱為redis-cm的ConfigMap中，保存的數(shù)據(jù)鍵值為redis-conf,值為:

bind0.0.0.0

port6380

項(xiàng)目6使用Ingress發(fā)布項(xiàng)目

1.選擇題

(1)D(2)A(3)B(4)0(5)A

2.填空題

(1)NodePort

(2)注解

(3)IngressClassName

(4)F12

(5)不需要

3.簡答題

一簡述kubernetes集群暴露服務(wù)的方式。

Kubernetes通常使用以下幾種方式將集群中的服務(wù)暴露給外部訪問。

(1)Ingress(入口)資源

Ingress是Kubernetes中管理外部訪問的API對象。它允許定義HTTP和HTTPS路由規(guī)則，可

以基于主機(jī)名、路徑等條件將流量路由到不同的服務(wù)。Ingress需要配合IngressControlIer使用，

IngressControlIer負(fù)責(zé)實(shí)現(xiàn)Ingress規(guī)則的具體路由和負(fù)載均衡功能，Ingress通常支持高級功

能如SSL終止、虛擬主機(jī)路由等，適用于復(fù)雜的多服務(wù)和多域名場景。

(2)NodePort(節(jié)點(diǎn)端口)

NodePort是Kubernetes中一種簡單的服務(wù)暴露方式。它會(huì)在每個(gè)節(jié)點(diǎn)上打開一個(gè)固定的端口

(通常在30000-32767范圍內(nèi))，并將該端口映射到Service指定的端口。外部用戶可以通過訪問任

意節(jié)點(diǎn)的該端口來訪問服務(wù)。NodePort方式適合于開發(fā)和測試環(huán)境，不適合復(fù)雜路由和負(fù)載均衡的

情況。

(3)LoadBalancer(負(fù)載均衡)

LoadBalancer類型的服務(wù)通過云服務(wù)提供商(如AWS、Azure、GCP)的負(fù)載均衡器來暴露服務(wù)。

Kubernetes會(huì)為該服務(wù)分配一個(gè)外部IP地址，并將外部流量通過負(fù)載均衡器轉(zhuǎn)發(fā)到集群中的對應(yīng)服

務(wù)。這種方式適合生產(chǎn)環(huán)境，能夠提供負(fù)載均衡、自動(dòng)擴(kuò)展即高可用性。

(4)ExternaIName(外部名字)

ExternalName是一種特殊類型的Kubernetes服務(wù)，它允許將Kubernetes內(nèi)部的服務(wù)映射到

外部服務(wù)的DNS名稱。它不提供負(fù)載均衡或路由功能，僅僅通過DNSCNAME記錄將服務(wù)名映射到外部

服務(wù)的地址，適合需要引用外部服務(wù)的場景。

二簡述灰度發(fā)布的作用。

灰度發(fā)布(GrayorGreyRelease)是一種應(yīng)用發(fā)布策略，主要用于降低新版本發(fā)布帶來的風(fēng)險(xiǎn)，

基本思想是在全量發(fā)布之前，先將新版本的功能或者代碼在一小部分用戶中進(jìn)行限制性地部署，以便

于觀察新版本的表現(xiàn)和影響，主要功能有以下3種。

(1)風(fēng)險(xiǎn)控制和測試

灰度發(fā)布能夠控制新功能或者代碼對整個(gè)系統(tǒng)穩(wěn)定性的影響。通過在少數(shù)用戶中先行發(fā)布，可以

及早發(fā)現(xiàn)和解決潛在的問題，從而降低全面發(fā)布帶來的風(fēng)險(xiǎn)。

(2)收集用戶反饋

在灰度發(fā)布期間，開發(fā)團(tuán)隊(duì)可以收集到用戶的反饋和體驗(yàn),進(jìn)一步優(yōu)化新版本的功能和用戶體瞼。

這種反饋對于決定是否進(jìn)行全量發(fā)布非常重要。

(3)逐步升級

灰度發(fā)布允許開發(fā)團(tuán)隊(duì)逐步將新版本擴(kuò)展到更多的用戶，可以逐步增加用戶比例，這種逐步升級

可以有效地分散風(fēng)險(xiǎn)，確保整個(gè)系統(tǒng)的穩(wěn)定性和可用性。

項(xiàng)目7使用Helm包管理工具部署應(yīng)用

1.選擇題

(1)B(2)A(3)B(4)A(5)A

2.填空題

(1)templates

(2)基本元數(shù)據(jù)

(3)uninstall

(4)默認(rèn)的配置值

(5)生成Kubernetes資源的模板

3.簡答題

一簡述Helm包管理工具的功能。

Heml包管理工具具備以下5種功能。

(1)簡化部署和管理

HeIm包管理工具將復(fù)雜的應(yīng)用程序打包為一個(gè)Chart,包含相關(guān)的Kubernetes資源定義和配置。

這樣，部署團(tuán)隊(duì)可以通過簡單的Helm命令快速部署和管理應(yīng)用程序，而不必手動(dòng)創(chuàng)建和配置每個(gè)

Kubernetes資源。

(2)版本控制

Helm能夠管理應(yīng)用程序的不同版本和配置，使用戶可以方便地升級和回滾應(yīng)用程序。通過Helm,

可以輕松地在不同環(huán)境(如開發(fā)、測試、生產(chǎn))中管理和維護(hù)應(yīng)用程序的不同版本。

(3)依賴管理

Helm支持Charts之間的依賴關(guān)系。這使得開發(fā)團(tuán)隊(duì)可以建立和管理復(fù)雜的應(yīng)用程序棧，每個(gè)

Chart可以依賴于其他Chart,從而形成一個(gè)完整的應(yīng)用程序解決方案。

(4)參數(shù)化部署

使用Helm,可以通過參數(shù)化配置文件來定制應(yīng)用程序的部署，這些參數(shù)可以根據(jù)不同的環(huán)境或

需求進(jìn)行調(diào)整，使得同一個(gè)Chart可以適應(yīng)不同的部署場景。

<5)持續(xù)集成和持續(xù)部署(CI/CD)

Helm可以集成到CI/CD流程中，使得開發(fā)團(tuán)隊(duì)可以通過自動(dòng)化工具鏈來自動(dòng)化構(gòu)建、測試和部

署Kubernetes應(yīng)用程序。這樣可以大大提高部署的效率和一致性。

二簡述Helm包管理工具的功能。

(1)創(chuàng)建新的HeImChart

使用Helm命令行工具創(chuàng)建一個(gè)Chart,如下所示。

helmcreatemychart

以上命令在當(dāng)前目錄下創(chuàng)建一個(gè)名為mychart的新目錄，包含Chart的基本結(jié)構(gòu)和文件。

(2)編輯Chart

①編輯Chart.yaml文件

在mychart目錄中，編輯Chart,yaml文件，指定Chart的基本信息，如版本號'描述等。

②配置Deployment文件

在templates目錄中編輯deployment,yaml文件，定義Deployment資源模板。根據(jù)應(yīng)用程序的需

求配置容器鏡像、環(huán)境變量,資源請求等。

③配置Service

編輯service,yaml文件，定義Service資源模板。根據(jù)需要定義Service的類型和端口等信息。

④配置其他資源

如果有需要，在templates目錄中添加其他資源的模板文件，如ConfigMap、SecreteIngress

(3)添加依賴

如果應(yīng)用程序依賴于其他的Chart,可以使用Helm的依賴管理功能。在requirements,yaml文件

中列出依賴的Chart,然后運(yùn)行heImdependencyupdate來下載和管理這些依賴。

(4)本地測試

在開發(fā)階段，使用Helm將Chart安裝到本地集群中進(jìn)行測試，如下所示。

helminstalImychart./mychart-dry-run

使用一dry-run參數(shù)可以查看HeIm安裝過程中生成的YANL文件，確保生成的資源符合預(yù)期。

(5)打包和發(fā)布

①打包Chart

發(fā)布Chart前，使用Helm打包成.tgz文件，如下所示。

helmpackagemychart

這將在當(dāng)前目錄下生成一個(gè)名為mychart-x.x.x.tgz的壓縮包，其中x.x.x是Chart的版本號。

②發(fā)布Chart

如果要將Chart分享給團(tuán)隊(duì)或者社區(qū)使用，可以將打包好的.tgz文件上傳到Helm倉庫，或者直接

使用helminstalI命令部署服務(wù)到本地集群中。

項(xiàng)目8使用operator自定義控制器部署中間件

1.選擇題

(2)C(2)B(3)B(4)A(5)D

2.填空題

(1)主從

(2)主從復(fù)制、哨兵、集群

(3)擴(kuò)展

(4)CRD定制資源定義

(5)部署管理

3.簡答題

-簡述有狀態(tài)服務(wù)的應(yīng)用場景。

有狀態(tài)服務(wù)通常指的是依賴持久性存儲(chǔ)和穩(wěn)定標(biāo)識的應(yīng)用程序。相比無狀態(tài)服務(wù)，有狀態(tài)服務(wù)需

要保留特定的狀態(tài)信息或數(shù)據(jù)，這些數(shù)據(jù)對應(yīng)用的正確性和運(yùn)行非常重要。以下是一些適合使用有狀

態(tài)服務(wù)的應(yīng)用場景：

(1)數(shù)據(jù)庫服務(wù)：

關(guān)系型數(shù)據(jù)庫(如MySQL、PostgreSQL)或NoSQL數(shù)據(jù)庫(如MongoDB、Cassandra)通常需要持

久性存儲(chǔ)來保存數(shù)據(jù)，并且需要穩(wěn)定的標(biāo)識以便應(yīng)用程序可以可靠地訪問。

(2)分布式緩存：

如Redis或Memcached,這些緩存服務(wù)通常存儲(chǔ)了應(yīng)用程序的臨時(shí)數(shù)據(jù)或者頻繁訪問的數(shù)據(jù)，

需要持久性存儲(chǔ)以確保數(shù)據(jù)不會(huì)因?yàn)楣?jié)點(diǎn)重啟而丟失。

(3)消息隊(duì)列和事件驅(qū)動(dòng)系統(tǒng)：

例如Kafka.RabbitMQ等，它們需要確保事件或消息的順序性和一致性，同時(shí)需要持久性存儲(chǔ)

以保證在節(jié)點(diǎn)重啟或故障后不會(huì)丟失數(shù)據(jù)。

(4)分布式文件系統(tǒng)：

如NFS、GlusterFS等,這些文件系統(tǒng)需要在集群內(nèi)部提供穩(wěn)定的文件訪問服務(wù)，并且通常需要

持久性存儲(chǔ)來保存文件數(shù)據(jù),

—簡述Operator自定義控制器

(1)自定義控制器

自定義控制器是一種Kubernetes控制器，負(fù)責(zé)管理自定義資源。這種控制器由開發(fā)人員編寫和

擴(kuò)展，以適應(yīng)特定應(yīng)用程序的管理和運(yùn)維需求。

Operator是一種Kubernetes的目定義控制器，它允許開發(fā)人員擴(kuò)展KubernetesAPI,引入新

的自定義資源，通過定義自定義控制器和資源，能夠在Kubernetes上運(yùn)行和管理復(fù)雜的系統(tǒng)和服務(wù)。

(2)Operator的作用和優(yōu)勢

①自動(dòng)化運(yùn)維任務(wù)

Operator可以自動(dòng)化運(yùn)維常見任務(wù)，如應(yīng)用程序的部署,配置更新、擴(kuò)展和故障恢復(fù)。它們基

于事先定義的規(guī)則和策略執(zhí)行操作，從而減少了手動(dòng)管理的需求，提高了運(yùn)維效率和一致性。

②聲明式管理

Operator基于Kuberne二es的聲明式API,實(shí)現(xiàn)了一種更高級別的抽象，允許用戶使用聲明性配

置來描述應(yīng)用程序和其相關(guān)資源的期望狀態(tài),系統(tǒng)將自動(dòng)調(diào)節(jié)以使當(dāng)前狀態(tài)與所需狀態(tài)一致。

③增強(qiáng).應(yīng)用程序特定的管理能力

通過自定義控制器和資源，Operator為特定的應(yīng)用程序或服務(wù)引入更高級別的管理能力，包括

了對應(yīng)用程序生命周期的端到端管理，從部署、配置、監(jiān)控到自動(dòng)伸縮和故障處理等。

④與運(yùn)維工具的集成

Operator可以與現(xiàn)有的運(yùn)維工具和流程集成，利用Kubernetes的API和擴(kuò)展機(jī)制來管理和操作

應(yīng)用程序，使Operator可以無縫地融入現(xiàn)有的開發(fā)和運(yùn)維工作流程中。

(3)Operator的實(shí)現(xiàn)方式

①基于控制器模式的編寫

Operator通常是基于Go或其他編程語言的Kubernetes控制器。它們監(jiān)聽自定義資源對象的變

更事件，并執(zhí)行相應(yīng)的邏輯以實(shí)現(xiàn)所需的操作。

②使用OperatorSDK

OperatorSDK是一個(gè)開源工具集，簡化了Operator的開發(fā)和部署，提供了生成和管理Operator

項(xiàng)目的命令行工具，幫助開發(fā)者快速上手并遵循最佳實(shí)踐。

(4)應(yīng)用場景

Operator在各種場景中都有廣泛的應(yīng)用，包括數(shù)據(jù)庫管理、監(jiān)控和日志收集、應(yīng)用程序部署和

運(yùn)維、自動(dòng)化配萱管理等。在Kubernetes上運(yùn)行復(fù)雜的應(yīng)用程序和服務(wù)變得更加簡單和可靠。

項(xiàng)目9部署項(xiàng)目到Kubernetes集群

1.選擇題

(1)B(2)A(3)C

2.填空題

(1)build:prod

(2)gobuild

(3)Maven

3.簡答題

-簡述部署項(xiàng)目到Kubernetes集群的流程。

(1)分析項(xiàng)目

拿到項(xiàng)目后，首先分析項(xiàng)目，包括項(xiàng)目是否需要提供對外訪問'項(xiàng)目是否需要數(shù)據(jù)庫、緩存等存

儲(chǔ)支持、項(xiàng)目是有狀態(tài)的服務(wù)還是無狀態(tài)的服務(wù)。

(2)部署數(shù)據(jù)庫管理系統(tǒng)

一般項(xiàng)目都需要數(shù)據(jù)庫管理系統(tǒng)的支持，包括持久化存儲(chǔ)和管理結(jié)構(gòu)化數(shù)據(jù)的關(guān)系型數(shù)據(jù)庫管理

系統(tǒng)，如Mysql,還包括提高數(shù)據(jù)訪問速度和性能的緩存數(shù)據(jù)庫管理系統(tǒng)，如Redis。本任務(wù)使用在項(xiàng)

目8中部署的Mysql主從數(shù)據(jù)庫。

(3)構(gòu)建鏡像

在Kubernetes集群上，服務(wù)是通過容器部署的，所有需要首先構(gòu)建項(xiàng)目的鏡像，然后通過鏡像運(yùn)

行容器，為用戶提供服務(wù)。

(4)編寫需要的YAML文件

分析項(xiàng)目需要使用到的資源,如Deploymnet、StatefuISet、Service%Ingress、ConfigMap、Secret

等，編寫相對應(yīng)的YAML腳本＜

（5）部署測試服務(wù)

通過YAML腳本部署項(xiàng)目后，進(jìn)行訪問測試，解決遇到的部署問題。

—簡述SpringCloud微服務(wù)項(xiàng)目優(yōu)勢。

SpringCloud是一個(gè)基于SpringBoot的開發(fā)工具集合，用于快速構(gòu)建分布式系統(tǒng)中的微服務(wù)架

構(gòu)。它提供了開發(fā)分布式系統(tǒng)所需的各種組件和工具，包括配置管理、服務(wù)發(fā)現(xiàn)、斷路器、路由、微

代理、控制總線、分布式消息傳遞等，幫助開發(fā)者快速實(shí)現(xiàn)微服務(wù)架構(gòu)的各種功能。

微服務(wù)是一種軟件架構(gòu)風(fēng)格，其中單個(gè)應(yīng)用程序被拆分為一組小型、松耦合的服務(wù)，每個(gè)服務(wù)運(yùn)

行在自己的進(jìn)程中，并通過輕量級機(jī)制（通常是HTTPAPI）進(jìn)行通信。每個(gè)微服務(wù)都專注于解決特

定的業(yè)務(wù)問題，并可以獨(dú)立部署、擴(kuò)展和更新，這種架構(gòu)風(fēng)格有助于提升開發(fā)團(tuán)隊(duì)的靈活性和可維護(hù)

性，同時(shí)支持更快的交付速度和更高的可擴(kuò)展性。

微服務(wù)架構(gòu)相比傳統(tǒng)的單體應(yīng)用架構(gòu)具有多方面的優(yōu)勢，這些優(yōu)勢使得微服務(wù)在當(dāng)今的軟件開發(fā)

中越來越受歡迎。微服務(wù)架構(gòu)的主要優(yōu)勢包括以下8個(gè)方面。

（1）靈活性和可擴(kuò)展性

微服務(wù)架構(gòu)將應(yīng)用程序拆分為多個(gè)小型服務(wù)，每個(gè)服務(wù)都專注于解決特定的業(yè)務(wù)問題。這種模塊

化的架構(gòu)使得每個(gè)服務(wù)可以獨(dú)立開發(fā)、部署、擴(kuò)展和更新，不影響整體系統(tǒng)的穩(wěn)定性和可用性。開發(fā)

團(tuán)隊(duì)可以根據(jù)需求獨(dú)立擴(kuò)展或更新單個(gè)服務(wù)，而不需要重新構(gòu)建整個(gè)應(yīng)用程序。

（2）技術(shù)多樣性和獨(dú)立部署

每個(gè)微服務(wù)可以使用不同的編程詒言'框架和技術(shù)棧，因?yàn)樗鼈冎g通過輕量級的通信機(jī)制（通

常是HTTPAPI）進(jìn)行交互。可以獨(dú)立部署每個(gè)服務(wù)，無需依賴其他服務(wù)的部署。

（3）容錯(cuò)性和彈性設(shè)計(jì)

微服務(wù)架構(gòu)通過斷路器模式和自動(dòng)擴(kuò)展等技術(shù)來提高系統(tǒng)的容錯(cuò)性和彈性。如果一個(gè)服務(wù)出現(xiàn)故

障，其余的服務(wù)仍然可以繼續(xù)運(yùn)行，而不會(huì)導(dǎo)致整個(gè)系統(tǒng)的崩潰。

（6）快速交付和持續(xù)集成/持續(xù)部署

微服務(wù)架構(gòu)支持敏捷開發(fā)，因?yàn)槊總€(gè)服務(wù)可以獨(dú)立進(jìn)行構(gòu)建、測試和部署。這種靈活性和獨(dú)立性

使團(tuán)隊(duì)可以快速地交付新功能和更新，實(shí)現(xiàn)持續(xù)集成和持續(xù)乳署。

（7）擴(kuò)展性和性能優(yōu)化

微服務(wù)架構(gòu)允許按需擴(kuò)展特定的服務(wù)，而不是整個(gè)應(yīng)用程序。

（8）易于管理和維護(hù)

每個(gè)微服務(wù)都是相對較小且聚焦于特定業(yè)務(wù)功能，使得理解、測試、修改和維護(hù)單個(gè)服務(wù)更加簡

單。此外由于每個(gè)服務(wù)獨(dú)立部署，開發(fā)者可以更輕松地管理不同服務(wù)的版本和更新。

項(xiàng)目10構(gòu)建企業(yè)級devOps云平臺(tái)

1.選擇題

（1）B（2）C（3）B（4）B（5）D

2.填空題

（1）b持續(xù)集成/持續(xù)交付

（2）版本

（3）集成

（4）部署

（5）流水線

3.簡答題

一簡述Devops的功能,

DevOps中的Dev是Devlopment（開發(fā)），Ops是Operation（運(yùn)維）,DevOps能夠打通開發(fā)與運(yùn)維的

壁壘，實(shí)現(xiàn)敏捷開發(fā)、持續(xù)集成、持續(xù)交付、持續(xù)部署，功能架構(gòu)如圖10-2所示。

圖10-2項(xiàng)目10DevOps云平臺(tái)功能架構(gòu)

如圖所示，Jenkins自動(dòng)化工具從Git上拉取代碼，推送到Harbor鏡像倉庫，再部署到測試和生產(chǎn)

環(huán)境。具體功能如下。

(1)持續(xù)集成(ContinuousIntegration,Cl)

代碼管理和版本控制：提供源代碼的管理和版本控制功能，通常集成了Git等版本控制系統(tǒng)。

白動(dòng)化構(gòu)建：白動(dòng)化執(zhí)行軟件構(gòu)建過程，包括編譯、打包和生成可執(zhí)行的軟件組件。

單元測試和代碼質(zhì)量分析：集成單元測試工具，自動(dòng)運(yùn)行測試用例并生成測試報(bào)告，同時(shí)進(jìn)行代

碼質(zhì)量分析和靜態(tài)代碼檢查，

(2)持續(xù)交付(ContinuousDelivery,CD)

自動(dòng)化部署：將經(jīng)過測試的應(yīng)用程序自動(dòng)部署到不同環(huán)境，如開發(fā)、測試'預(yù)發(fā)布和生產(chǎn)那境。

環(huán)境管理：提供環(huán)境配置和管理功能，支持環(huán)境快速復(fù)制和調(diào)整，確保部署的一致性和可重復(fù)性。

配置管理：管理應(yīng)用程序的配置文件和參數(shù)，支持不同環(huán)境的配置管理和自動(dòng)化變更。

(3)持續(xù)部署(ContinuousDeployment)

自動(dòng)化部署到生產(chǎn)環(huán)境：在通過自動(dòng)化測試和審批流程后，將應(yīng)用程序自動(dòng)部署到生產(chǎn)環(huán)境，

以實(shí)現(xiàn)持續(xù)部署的自動(dòng)化流程。

(4)監(jiān)控和日志管理：

應(yīng)用性能監(jiān)控：實(shí)時(shí)監(jiān)控應(yīng)用程序的性能指標(biāo)，如響應(yīng)時(shí)間、吞吐量和錯(cuò)誤率等。

日志收集和分析：收集,存儲(chǔ)和分析應(yīng)用程序和基礎(chǔ)設(shè)施的日志，以便于故障排除和性能優(yōu)化。

安全和權(quán)限管理：

訪問控制和身份驗(yàn)證：管理用戶和團(tuán)隊(duì)的訪問權(quán)限，確保只有授權(quán)人員可以訪問和操作關(guān)鍵系統(tǒng)。

安全審計(jì)和合規(guī)性：監(jiān)控和記錄平臺(tái)的操作活動(dòng)，支持合規(guī)性要求和安全審計(jì)。

(5)自動(dòng)化工具集成：

支持與CI/CD過程相關(guān)的各種第三方工具和服務(wù)的集成，如測試自動(dòng)化工具、部署工具、持續(xù)集

成服務(wù)器等。

(6)報(bào)告和可視化

提供關(guān)于構(gòu)建'部署和運(yùn)行過程的報(bào)告和分析，幫助團(tuán)隊(duì)了解和改進(jìn)整體效率和質(zhì)量。

二簡述Pipeline腳本功能。

Pipeline腳本是一種用于自動(dòng)化軟