k8s架構(gòu)基礎(chǔ)介紹

kubernetes架構(gòu)

在這張系統(tǒng)架構(gòu)圖中，我們把服務(wù)分為運(yùn)行在工作節(jié)點(diǎn)上的服務(wù)和組成集群級(jí)別控制板的服務(wù)。
Kubernetes節(jié)點(diǎn)有運(yùn)行應(yīng)用容器必備的服務(wù)，而這些都是受Master的控制。
每次個(gè)節(jié)點(diǎn)上當(dāng)然都要運(yùn)行Docker。Docker來(lái)負(fù)責(zé)所有具體的映像下載和容器運(yùn)行。
Kubernetes主要由以下幾個(gè)核心組件組成：

kubectl：k8s是命令行端，用來(lái)發(fā)送客戶的操作指令。

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

1. API server[資源操作入口]：是k8s集群的前端接口，各種各樣客戶端工具以及k8s的其他組件可以通過(guò)它管理k8s集群的各種資源。它提供了HTTP/HTTPS RESTful API,即K8S API。

• 提供了資源對(duì)象的唯一操作入口，其他所有組件都必須通過(guò)它提供的API來(lái)操作資源數(shù)據(jù)，只有API Server與存儲(chǔ)通信，其他模塊通過(guò)API Server訪問(wèn)集群狀態(tài)。

第一，是為了保證集群狀態(tài)訪問(wèn)的安全。

第二，是為了隔離集群狀態(tài)訪問(wèn)的方式和后端存儲(chǔ)實(shí)現(xiàn)的方式：API Server是狀態(tài)訪問(wèn)的方式，不會(huì)因?yàn)楹蠖舜鎯?chǔ)技術(shù)etcd的改變而改變。

• 作為kubernetes系統(tǒng)的入口，封裝了核心對(duì)象的增刪改查操作，以RESTFul接口方式提供給外部客戶和內(nèi)部組件調(diào)用。對(duì)相關(guān)的資源數(shù)據(jù)“全量查詢”+“變化監(jiān)聽(tīng)”，實(shí)時(shí)完成相關(guān)的業(yè)務(wù)功能。

2. Scheduler[集群分發(fā)調(diào)度器]：負(fù)責(zé)決定將Pod放在哪個(gè)Node上運(yùn)行。在調(diào)度時(shí)，會(huì)充分考慮集群的拓?fù)浣Y(jié)構(gòu)，當(dāng)前各個(gè)節(jié)點(diǎn)的負(fù)載情況，以及應(yīng)對(duì)高可用、性能、數(shù)據(jù)親和性和需求。

1.Scheduler收集和分析當(dāng)前Kubernetes集群中所有Minion節(jié)點(diǎn)的資源(內(nèi)存、CPU)負(fù)載情況，然后依此分發(fā)新建的Pod到Kubernetes集群中可用的節(jié)點(diǎn)。

2.實(shí)時(shí)監(jiān)測(cè)Kubernetes集群中未分發(fā)和已分發(fā)的所有運(yùn)行的Pod。

3.Scheduler也監(jiān)測(cè)Minion節(jié)點(diǎn)信息，由于會(huì)頻繁查找Minion節(jié)點(diǎn)，Scheduler會(huì)緩存一份最新的信息在本地。

4.最后，Scheduler在分發(fā)Pod到指定的Minion節(jié)點(diǎn)后，會(huì)把Pod相關(guān)的信息Binding寫回API Server。

4. Controller Manager[內(nèi)部管理控制中心]：負(fù)責(zé)管理集群的各種資源，保證資源處于預(yù)期的狀態(tài)。它由多種Controller組成，包括Replication Controller、Endpoints Controller、Namespace Controller、Serviceaccounts Controller等。

實(shí)現(xiàn)集群故障檢測(cè)和恢復(fù)的自動(dòng)化工作，負(fù)責(zé)執(zhí)行各種控制器，主要有：

1.endpoint-controller：定期關(guān)聯(lián)service和pod(關(guān)聯(lián)信息由endpoint對(duì)象維護(hù))，保證service到pod的映射總是最新的。

2.replication-controller：定期關(guān)聯(lián)replicationController和pod，保證replicationController定義的復(fù)制數(shù)量與實(shí)際運(yùn)行pod的數(shù)量總是一致的。

5. Etcd：負(fù)責(zé)保存k8s集群的配置信息和各種資源的狀態(tài)信息。當(dāng)數(shù)據(jù)發(fā)生變化時(shí)，etcd會(huì)快速的通知k8s相關(guān)組件。[（第三方組件）它有可替換方案。Consul、zookeeper]()

6. Pod: k8s集群的最小組成單位。一個(gè)Pod內(nèi)，可以運(yùn)行一個(gè)或多個(gè)容器。大多數(shù)情況下，一個(gè)Pod內(nèi)只有一個(gè)Container容器。

7. Flanner：是k8s集群網(wǎng)絡(luò)，可以保證Pod的跨主機(jī)通信。也有替換方案。

[root@master ~]# kubectl get pod --all-namespaces
//查看pod信息

[root@master ~]# kubectl get pod --all-namespaces -o wide
//顯示pod的節(jié)點(diǎn)信息

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

Kubelet[節(jié)點(diǎn)上的Pod管家]：它是Node的agent(代理)，當(dāng)Scheduler確定某 個(gè)Node上運(yùn)行Pod之后，會(huì)將Pod的具體配置信息發(fā)送給該節(jié)點(diǎn)的kubelet,kubelet會(huì)根據(jù)這些信息創(chuàng)建和運(yùn)行容器，并向Master報(bào)告運(yùn)行狀態(tài)。

• 負(fù)責(zé)Node節(jié)點(diǎn)上pod的創(chuàng)建、修改、監(jiān)控、刪除等全生命周期的管理
• 定時(shí)上報(bào)本Node的狀態(tài)信息給API Server。
• kubelet是Master API Server和Minion之間的橋梁，接收Master API Server分配給它的commands和work，與持久性鍵值存儲(chǔ)etcd、file、server和http進(jìn)行交互，讀取配置信息。
• 具體的工作如下：

設(shè)置容器的環(huán)境變量、給容器綁定Volume、給容器綁定Port、根據(jù)指定的Pod運(yùn)行一個(gè)單一容器、給指定的Pod創(chuàng)建network 容器。

同步Pod的狀態(tài)、同步Pod的狀態(tài)、從cAdvisor獲取Container info、 pod info、 root info、 machine info。

在容器中運(yùn)行命令、殺死容器、刪除Pod的所有容器。

kube-proxy[負(fù)載均衡、路由轉(zhuǎn)發(fā)]:負(fù)責(zé)將訪問(wèn)service的TCP/UDP數(shù)據(jù)流轉(zhuǎn)發(fā)到后端的容器。如果有多個(gè)
副本，kube-proxy會(huì)實(shí)現(xiàn)負(fù)載均衡。

• Proxy是為了解決外部網(wǎng)絡(luò)能夠訪問(wèn)跨機(jī)器集群中容器提供的應(yīng)用服務(wù)而設(shè)計(jì)的，運(yùn)行在每個(gè)Node上。Proxy提供TCP/UDP sockets的proxy，每創(chuàng)建一種Service，Proxy主要從etcd獲取Services和Endpoints的配置信息（也可以從file獲?。缓蟾鶕?jù)配置信息在Minion上啟動(dòng)一個(gè)Proxy的進(jìn)程并監(jiān)聽(tīng)相應(yīng)的服務(wù)端口，當(dāng)外部請(qǐng)求發(fā)生時(shí)，Proxy會(huì)根據(jù)Load Balancer將請(qǐng)求分發(fā)到后端正確的容器處理。
• Proxy不但解決了同一主宿機(jī)相同服務(wù)端口沖突的問(wèn)題，還提供了Service轉(zhuǎn)發(fā)服務(wù)端口對(duì)外提供服務(wù)的能力，Proxy后端使用了隨機(jī)、輪循負(fù)載均衡算法。

除了核心組件，還有一些推薦的Add-ons：

kube-dns負(fù)責(zé)為整個(gè)集群提供DNS服務(wù)
Ingress Controller為服務(wù)提供外網(wǎng)入口
Heapster提供資源監(jiān)控
Dashboard提供GUI
Federation提供跨可用區(qū)的集群
Fluentd-elasticsearch提供集群日志采集、存儲(chǔ)與查詢

一. 分層架構(gòu)

Kubernetes設(shè)計(jì)理念和功能其實(shí)就是一個(gè)類似Linux的分層架構(gòu)，如下圖所示。

核心層：Kubernetes最核心的功能，對(duì)外提供API構(gòu)建高層的應(yīng)用，對(duì)內(nèi)提供插件式應(yīng)用執(zhí)行環(huán)境
應(yīng)用層：部署（無(wú)狀態(tài)應(yīng)用、有狀態(tài)應(yīng)用、批處理任務(wù)、集群應(yīng)用等）和路由（服務(wù)發(fā)現(xiàn)、DNS解析等）
管理層：系統(tǒng)度量（如基礎(chǔ)設(shè)施、容器和網(wǎng)絡(luò)的度量），自動(dòng)化（如自動(dòng)擴(kuò)展、動(dòng)態(tài)Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
接口層：kubectl命令行工具、客戶端SDK以及集群聯(lián)邦
生態(tài)系統(tǒng)：在接口層之上的龐大容器集群管理調(diào)度的生態(tài)系統(tǒng)，可以劃分為兩個(gè)范疇
Kubernetes外部：日志、監(jiān)控、配置管理、CI、CD、Workflow、FaaS、OTS應(yīng)用、ChatOps等
Kubernetes內(nèi)部：CRI、CNI、CVI、鏡像倉(cāng)庫(kù)、Cloud Provider、集群自身的配置和管理等

二. 在K8s中運(yùn)行一個(gè)容器應(yīng)用

? 下面通過(guò)運(yùn)行一個(gè)容器應(yīng)用的過(guò)程，來(lái)一起理解一下K8s組件是如何協(xié)作的。

開(kāi)發(fā)者開(kāi)發(fā)一個(gè)應(yīng)用后，打包Docker鏡像，上傳到Docker registry；然后編寫一個(gè)yaml部署描述文件，以描述應(yīng)用的結(jié)構(gòu)和資源需求。開(kāi)發(fā)者通過(guò)kubectl（或其它應(yīng)用），將部署描述文件提交到API server，API server將部署需求更新到etcd。etcd在K8s管理結(jié)點(diǎn)中的作用相當(dāng)于數(shù)據(jù)庫(kù)，其它組件提交到API server的數(shù)據(jù)都存儲(chǔ)于etcd。API server非常輕量，并不會(huì)直接去創(chuàng)建或管理Pod等資源，在多數(shù)場(chǎng)景下甚至不會(huì)去主動(dòng)調(diào)用其它的K8s組件發(fā)出指令。其它組件通過(guò)建立和API server的長(zhǎng)連接，監(jiān)視關(guān)心的對(duì)象，監(jiān)視到變化后，執(zhí)行所負(fù)責(zé)的操作。

繼續(xù)我們的啟動(dòng)應(yīng)用之旅，如圖所示，Controller Manager中的控制器監(jiān)視到新的部署描述后，根據(jù)部署描述，創(chuàng)建ReplicaSet、Pod等資源。Scheduler監(jiān)視到新的Pod資源后，結(jié)合集群的資源情況，選定一或多個(gè)工作結(jié)點(diǎn)運(yùn)行Pod。工作結(jié)點(diǎn)上的Kubelet監(jiān)視到有Pod被計(jì)劃在自己的結(jié)點(diǎn)后，向Docker等Container runtime發(fā)出啟動(dòng)容器的指令，Docker engineer將按照指令從Docker registy拉取鏡像，然后啟動(dòng)并運(yùn)行容器。

三. K8s集群的高可用部署

? 通過(guò)之前的介紹，我們看到K8s可以在多個(gè)工作結(jié)點(diǎn)上啟動(dòng)并管理容器，下面來(lái)學(xué)習(xí)一下，如何實(shí)現(xiàn)管理結(jié)點(diǎn)的高可用部署。

上圖的K8s高可用部署中有3個(gè)管理結(jié)點(diǎn)。etcd自身是一個(gè)分布式數(shù)據(jù)存儲(chǔ)系統(tǒng)，按照其多實(shí)例部署方案，結(jié)點(diǎn)只需在啟動(dòng)時(shí)知道其它結(jié)點(diǎn)的IP和端口號(hào)即可組成高可用環(huán)境。和通常的應(yīng)用服務(wù)器一樣，API Server是無(wú)狀態(tài)的，可以運(yùn)行任意多個(gè)實(shí)例，且彼此之間無(wú)需互相知道。為了能使kubectl等客戶端和Kubelet等組件連接到健康的API Server、減輕單臺(tái)API Server的壓力，需使用基礎(chǔ)架構(gòu)提供的負(fù)載均衡器作為多個(gè)API Server實(shí)例的入口。如上圖的部署方法，每個(gè)主結(jié)點(diǎn)上都運(yùn)行了一個(gè)etcd實(shí)例，這樣API Server只需連接本地的etcd實(shí)例即可，無(wú)需再使用負(fù)載均衡器作為etcd的入口。

Controller Manager和Scheduler需要修改K8s集群，同時(shí)修改時(shí)可能引發(fā)并發(fā)問(wèn)題。假設(shè)兩個(gè)ReplicaSet Controller同時(shí)監(jiān)視到需創(chuàng)建一個(gè)Pod，然后同時(shí)進(jìn)行創(chuàng)建操作，就會(huì)創(chuàng)建出兩個(gè)Pod。K8s為了避免這個(gè)問(wèn)題，一組此類組件的實(shí)例將選舉出一個(gè)leader，僅有l(wèi)eader處于活動(dòng)狀態(tài)，其它實(shí)例處于待命狀態(tài)。Controller Manager和Scheduler也可以獨(dú)立于API server部署，通過(guò)負(fù)載均衡器連接到多個(gè)API server實(shí)例。

范例

分析各個(gè)組件的作用以及架構(gòu)工作流程:

1) kubectl發(fā)送部署 請(qǐng)求到API server
2) APIserver通知Controller Manager創(chuàng)建一個(gè)Deployment資源。
3) Scheduler執(zhí)行調(diào)度任務(wù),將兩個(gè)副本Pod分發(fā)到node01和node02. 上。
4) node01和node02, 上的kubelet在各自節(jié)點(diǎn)上創(chuàng)建并運(yùn)行Pod。

補(bǔ)充

1.應(yīng)用的配置和當(dāng)前的狀態(tài)信息保存在etcd中，執(zhí)行kubectl get pod時(shí)API server會(huì)從etcd中讀取這些數(shù)據(jù)。

2.flannel會(huì)為每個(gè)Pod分配一個(gè)IP。 但此時(shí)沒(méi)有創(chuàng)建Service資源，目前kube-proxy還沒(méi)有參與進(jìn)來(lái)。

運(yùn)行一個(gè)例子（創(chuàng)建一個(gè)deployment資源對(duì)象<pod控制器>）

[root@master ~]# kubectl run test-web --image=httpd --replicas=2
//創(chuàng)建一個(gè)deployment資源對(duì)象。

運(yùn)行完成之后，如果有鏡像可直接開(kāi)啟，沒(méi)有的話需要等待一會(huì)兒，node節(jié)點(diǎn)要在docker hup上下載

查看一下

[root@master ~]# kubectl get  deployments.或 kubectl get  deploy

[root@master ~]# kubectl get pod

[root@master ~]# kubectl get pod  -o wide
//顯示pod的節(jié)點(diǎn)信息

如果，node節(jié)點(diǎn)沒(méi)有運(yùn)行test-web服務(wù)，需要在節(jié)點(diǎn)上重啟一下<systemctl restart kubelet>

如果刪除一個(gè)pod

[root@master ~]# kubectl delete pod test-web-5b56bdff65-2njqf 

查看一下

[root@master ~]# kubectl get pod -o wide

現(xiàn)在發(fā)現(xiàn)容器還存在，因?yàn)榭刂破鲿?huì)自動(dòng)發(fā)現(xiàn)，一旦與之前執(zhí)行的命令有誤差，他會(huì)自動(dòng)補(bǔ)全。

參考：
https://blog.csdn.net/gongxsh00/article/details/79932136
https://www.jianshu.com/p/18edac81c718