一、背景
基于分布式的架構(gòu)中,需要管理的服務(wù)是非常多的,無(wú)論是服務(wù)的數(shù)量還是體系劃分;
從服務(wù)的能力上看,可以進(jìn)行分層管控,只是其中有相當(dāng)一部分服務(wù)層,改動(dòng)更新的頻率很低,所以感知也不明顯;

1.png
就以自己當(dāng)下參與研發(fā)的系統(tǒng)來(lái)說(shuō);
通過(guò)K8S進(jìn)行管理的服務(wù)近百個(gè),這中間有部分服務(wù)采用集群模式,即便是這個(gè)規(guī)模的系統(tǒng),也幾乎不可能依賴(lài)純?nèi)斯み\(yùn)維的形式,自動(dòng)化流程必不可少;
二、持續(xù)集成
此前圍繞該主題寫(xiě)過(guò)一個(gè)完整的實(shí)踐案例,主要圍繞Jenkins、Docker、K8S等組件的使用層面,總結(jié)源碼編譯、打包、鏡像構(gòu)建、部署等自動(dòng)化管理的流程;

2.png
Jenkins:是一個(gè)擴(kuò)展性非常強(qiáng)的軟件,用于自動(dòng)化各種任務(wù),包括構(gòu)建、測(cè)試和部署等;
Docker:作為開(kāi)源的應(yīng)用容器引擎,可以把應(yīng)用程序和其相關(guān)依賴(lài)打包生成一個(gè)Image鏡像文件,是一個(gè)標(biāo)準(zhǔn)的運(yùn)行環(huán)境,提供可持續(xù)交付的能力;
Kube.NETes:作為開(kāi)源的容器編排引擎,用來(lái)對(duì)容器化應(yīng)用進(jìn)行自動(dòng)化部署、 擴(kuò)縮和管理;
三、K8S架構(gòu)
1、核心組件

3.png
Control-Plane-Components:控制平面組件
對(duì)集群做出全局決策,例如:資源調(diào)度、檢測(cè)、事件響應(yīng),可以在集群中的任何節(jié)點(diǎn)上運(yùn)行;
- api:開(kāi)放K8S的API,組件之間通過(guò)API交互,相當(dāng)于控制面的前端;
- controllermanager:運(yùn)行控制器進(jìn)程,邏輯上是一個(gè)單獨(dú)的進(jìn)程;
- scheduler:監(jiān)聽(tīng)新建未指定運(yùn)行節(jié)點(diǎn)的Pods,并為Pod選擇運(yùn)行節(jié)點(diǎn);
- etcd:兼具一致性和高可用性的鍵值數(shù)據(jù)庫(kù),作為保存K8S數(shù)據(jù)的后臺(tái)庫(kù);
Node:節(jié)點(diǎn)組件
該組件會(huì)在每個(gè)節(jié)點(diǎn)上運(yùn)行,負(fù)責(zé)維護(hù)運(yùn)行的Pod并提供Kubernetes運(yùn)行環(huán)境;
- kubelet:在每個(gè)節(jié)點(diǎn)上運(yùn)行的代理,保證容器都運(yùn)行在Pod中;
- kube-proxy:每個(gè)節(jié)點(diǎn)上運(yùn)行的網(wǎng)絡(luò)代理, 維護(hù)節(jié)點(diǎn)上的網(wǎng)絡(luò)規(guī)則;
ContAIner-Runtime:容器運(yùn)行時(shí)
負(fù)責(zé)運(yùn)行容器的軟件,支持Docker、containerd、CRI-O等多個(gè)容器運(yùn)行環(huán)境,以及任何實(shí)現(xiàn)Kubernetes-CRI容器運(yùn)行環(huán)境接口;
2、分層結(jié)構(gòu)
從整體的功能上來(lái)考慮,K8S集群可以分為:用戶(hù)、控制平面、節(jié)點(diǎn)三個(gè)模塊;

4.png
用戶(hù)側(cè):不論是CLI命令行還是UI界面,會(huì)與控制面板的APIserver進(jìn)行交互,APIserver再與其他組件交互,最終執(zhí)行相應(yīng)的操作命令;
控制平面:以前也稱(chēng)為Master,核心組件包括APIserver、controller、scheduler、etcd,主要用來(lái)調(diào)度整個(gè)集群,以及做出全局決策;
節(jié)點(diǎn):通過(guò)將容器放入在節(jié)點(diǎn)上運(yùn)行的Pod中來(lái)執(zhí)行工作負(fù)載,簡(jiǎn)單的理解工作負(fù)載就是各種應(yīng)用程序等,節(jié)點(diǎn)上的核心組件包括Pod、kubelet、Container-Runtime、kube-proxy等;
3、核心能力
站在研發(fā)的視角來(lái)看,K8S提供極其強(qiáng)大的應(yīng)用服務(wù)管理能力;
3.1 發(fā)現(xiàn)與負(fù)載
服務(wù)Service可以將運(yùn)行在一個(gè)或一組Pod上的網(wǎng)絡(luò)應(yīng)用程序公開(kāi)為網(wǎng)絡(luò)服務(wù)的方法,通常使用標(biāo)簽對(duì)資源對(duì)象進(jìn)行篩選過(guò)濾;

5.png
3.2 調(diào)度
調(diào)度器通過(guò)監(jiān)測(cè)機(jī)制來(lái)發(fā)現(xiàn)集群中新創(chuàng)建且尚未被調(diào)度到節(jié)點(diǎn)上的Pod,由于Pod中的容器和Pod本身可能有不同的資源要求,調(diào)度會(huì)將Pod放置到合適的節(jié)點(diǎn)上;

6.png
3.3 自動(dòng)伸縮
K8S可以通過(guò)指標(biāo)檢查工作負(fù)載的資源需求,例如CPU利用率、響應(yīng)時(shí)長(zhǎng)、內(nèi)存利用率、或者其他,從而判斷是否需要執(zhí)行伸縮,垂直維度可以是更多的資源分配,水平維度可以是更多的集群部署;

7.png
K8S可以自動(dòng)伸縮,也具備自動(dòng)修復(fù)的能力,當(dāng)節(jié)點(diǎn)故障或者應(yīng)用服務(wù)異常時(shí),會(huì)被檢查到,可能會(huì)進(jìn)行節(jié)點(diǎn)遷移或者重啟;
四、應(yīng)用案例
1、服務(wù)部署
在此前的實(shí)踐案例中,用CLI命令行和腳本文件的方式,完成的部署動(dòng)作,而在整個(gè)流程中涉及集群的多個(gè)組件協(xié)作,多次的通信和調(diào)度;
kubectl create -f pod.yaml

8.png
2、交互流程

9.png
【1】CLI命令行和UI界面,都是通過(guò)APIserver接口,與集群內(nèi)部組件交互,比如上述的Pod部署操作;
【2】在APIserver收到請(qǐng)求之后,會(huì)將序列化狀態(tài)的對(duì)象寫(xiě)入到etcd中完成存儲(chǔ)操作;
【3】Scheduler調(diào)度器通過(guò)監(jiān)測(cè)(Watch)機(jī)制來(lái)發(fā)現(xiàn)集群中新創(chuàng)建且尚未被調(diào)度到節(jié)點(diǎn)上的Pod;
【4】在集群中找到一個(gè)Pod的所有可調(diào)度節(jié)點(diǎn),對(duì)這些可調(diào)度節(jié)點(diǎn)打分,選出其中得分最高的節(jié)點(diǎn)來(lái)運(yùn)行Pod,然后調(diào)度器將這個(gè)調(diào)度決定通知給APIserver;
【5】APIserver完成信息存儲(chǔ)后,然后通知相應(yīng)節(jié)點(diǎn)的Kubelet;
【6】Kubelet是基于PodSpec來(lái)工作的,確保這些PodSpec中描述的容器處于運(yùn)行狀態(tài)且運(yùn)行狀況良好,每個(gè)PodSpec是一個(gè)描述Pod的YAML或JSON對(duì)象;
【7】Pod是可以在Kubernetes中創(chuàng)建和管理的、最小的可部署的計(jì)算單元,包括一個(gè)或多個(gè)容器;
五、參考源碼
文檔倉(cāng)庫(kù):
https://gitee.com/cicadasmile/butte-JAVA-note
腳本倉(cāng)庫(kù):
https://gitee.com/cicadasmile/butte-auto-parent作者:知了一笑
鏈接:https://www.jianshu.com/p/9b4af059d58f
來(lái)源:簡(jiǎn)書(shū)
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán),非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。






