基于Kubernetes的CI/CD平臺(tái)①

陳 博,周亦敏

(上海理工大學(xué) 光電信息與計(jì)算機(jī)工程學(xué)院,上海 200093)

隨著互聯(lián)網(wǎng)規(guī)模的不斷擴(kuò)大,越來(lái)越多的公司逐漸將業(yè)務(wù)的重點(diǎn)放在了互聯(lián)網(wǎng)業(yè)務(wù)上,如何合理的開(kāi)發(fā)和管理海量的互聯(lián)網(wǎng)業(yè)務(wù)成了當(dāng)前的熱點(diǎn).云計(jì)算的概念是2006年8月份由Google 的CEO 在搜索引擎大會(huì)上提出,旨在為個(gè)人或組織提供虛擬化計(jì)算資源,使得公司可以將自己的互聯(lián)網(wǎng)業(yè)務(wù)托管于云服務(wù)商,而不用構(gòu)建自己的基礎(chǔ)設(shè)施[1].

因?yàn)樵频谋憷蜆I(yè)務(wù)量的上升,越來(lái)越多的公司開(kāi)始采用微服務(wù)的架構(gòu),如B 站推出了自己的微服務(wù)框架Kratos,阿里巴巴的Spring Cloud Alibaba 等.因?yàn)樵谠缙趥鹘y(tǒng)的單體架構(gòu)應(yīng)用中,往往各個(gè)應(yīng)用之間具有高耦合度、擴(kuò)展能力弱.微服務(wù)的提出很好地解決了這一痛點(diǎn)[2].相比較傳統(tǒng)的架構(gòu),微服務(wù)架構(gòu)能夠更好地幫助企業(yè)將新的功能點(diǎn)快速的迭代插入到現(xiàn)有的生產(chǎn)環(huán)境中去,它減少了開(kāi)發(fā)的復(fù)雜性以及部署的復(fù)雜性.同時(shí),架構(gòu)本身也降低了資源的消耗[3].表1是傳統(tǒng)單體架構(gòu)與微服務(wù)架構(gòu)的對(duì)比.微服務(wù)因?yàn)槠洳鸱值脑瓌t,往往一個(gè)業(yè)務(wù)會(huì)被拆分成多個(gè)微服務(wù),無(wú)論是開(kāi)發(fā)或是部署都是非常的繁瑣.Kubernetes 是一款分布式容器編排引擎[4],它能夠很好的管理各個(gè)服務(wù),可以自動(dòng)實(shí)現(xiàn)容器伸縮,方便運(yùn)維人員對(duì)容器的管理,是一個(gè)得到生產(chǎn)實(shí)踐證明的容器編排管理系統(tǒng).本文就將基于Kubernetes,研究在其上構(gòu)建持續(xù)集成持續(xù)部署的自動(dòng)化流水線平臺(tái)的最佳實(shí)踐.

表1 單體架構(gòu)與微服務(wù)架構(gòu)的對(duì)比

1 Kubernetes 架構(gòu)

在研究基于Kubernetes 的CI/CD 平臺(tái)之前,我們有必要先了解下它的整體架構(gòu)及運(yùn)作方式,以便于我們更好的針對(duì)其架構(gòu)特點(diǎn)設(shè)計(jì)出更符合其特性的CI/CD流水線.Kubernetes(簡(jiǎn)稱(chēng)k8s)是Google 使用go 語(yǔ)言開(kāi)發(fā)的一個(gè)自動(dòng)化容器操作的開(kāi)源平臺(tái).使用Kubernetes可以：

(1)自動(dòng)化彈性構(gòu)建容器；

(2)自動(dòng)管理容器；

(3)提供容器之間的負(fù)載均衡；

(4)方便對(duì)容器版本回滾更新；

(5)易于擴(kuò)容.

1.1 Kubernetes 組件

Kubernetes 的集群主要由若干個(gè)Master 節(jié)點(diǎn)和Node 節(jié)點(diǎn)構(gòu)成.Master 節(jié)點(diǎn)在其上運(yùn)行相應(yīng)的Master組件和Node 組件,Node 節(jié)點(diǎn)運(yùn)行Node 組件,圖1是Kubernetes 集群的架構(gòu)圖.

Master 組件是集群的管理控制中心[4],如下是Master組件：

(1)Kube-Apiserver[5]：提供Restful 風(fēng)格的API 接口,通過(guò)它我們可以對(duì)k8s 的資源對(duì)象進(jìn)行增刪改查,同樣apiserver 也是k8s 集群的數(shù)據(jù)總線和數(shù)據(jù)中心.

(2)Kube-Scheduler：負(fù)責(zé)分配調(diào)度Pod 到集群內(nèi)的節(jié)點(diǎn)上,它監(jiān)聽(tīng)Kube-Apiserver,查詢(xún)還未分配N(xiāo)ode的Pod,然后根據(jù)調(diào)度策略為這些Pod 分配節(jié)點(diǎn).

(3)ETCD：是一個(gè)高可用的分布式鍵值數(shù)據(jù)庫(kù),Kubernetes 集群使用其作為它的數(shù)據(jù)后端.

(4)Kube-Controller-Manager：集群內(nèi)部的管理控制中心,它會(huì)及時(shí)發(fā)現(xiàn)并執(zhí)行自動(dòng)化修復(fù)流程,確保集群始終處于預(yù)期的工作狀態(tài).

圖1 Kubernetes 集群的架構(gòu)圖

Node 組件在每個(gè)節(jié)點(diǎn)上運(yùn)行,維護(hù)運(yùn)行的Pod 并提供Kubernetes 運(yùn)行時(shí)環(huán)境.

(1)Kubelet：是主要的節(jié)點(diǎn)代理,它監(jiān)測(cè)已分配給其節(jié)點(diǎn)的Pod.

(2)Kube-Proxy：在每個(gè)節(jié)點(diǎn)上運(yùn)行網(wǎng)絡(luò)代理,并反映每個(gè)節(jié)點(diǎn)上Kubernetes API 中定義的服務(wù).

在該分布式系統(tǒng)中,各個(gè)服務(wù)運(yùn)行在node 節(jié)點(diǎn)上,由master 節(jié)點(diǎn)自動(dòng)管理.所以考量將CI/CD 服務(wù)放置集群中運(yùn)行,方便自動(dòng)化運(yùn)維,鏡像倉(cāng)庫(kù)因需要頻繁讀寫(xiě)操作,可放置于集群外進(jìn)行管理,減少對(duì)Kubernetes集群的壓力.Kubernetes 使用docker 來(lái)進(jìn)行容器的管理和云上的自動(dòng)運(yùn)維,減少了相應(yīng)的成本,也不會(huì)再生產(chǎn)相應(yīng)的環(huán)境沖突了,總而言之是一種非常便利的工具[6].

2 CI/CD 平臺(tái)設(shè)計(jì)

CI 即持續(xù)集成是指開(kāi)發(fā)將代碼提交到GIT 服務(wù)器上,會(huì)觸發(fā)一次集成服務(wù)器的相關(guān)功能,比如編譯、測(cè)試、輸出結(jié)果等,往往一天內(nèi)會(huì)有多次的集成,確保新增代碼能與原先代碼正確集成,這樣有利于及時(shí)檢查代碼的缺陷.CD 即持續(xù)部署是指通過(guò)自動(dòng)化部署的手段將軟件功能頻繁的進(jìn)行交付,加快了代碼的上線速度.

2.1 CI 工具選型

往往持續(xù)集成持續(xù)部署是相繼進(jìn)行的CI 的常用工具有Jenkins、Circle CI、Codeship 等,Jenkins 因其開(kāi)源和完善的社區(qū)豐富的插件被廣大公司所采用,因此本文選型CI 工具為Jenkins.

2.2 版本控制

在持續(xù)集成中,版本控制是不可或缺的一部分.若部署時(shí),代碼發(fā)生災(zāi)難性缺陷,通過(guò)使用版本控制可及時(shí)回溯至上個(gè)正常的代碼版本.在常用的版本控制中,GIT 含有的是分布式代碼庫(kù)與文件快照的設(shè)計(jì)思想,相對(duì)于傳統(tǒng)CVS、SVN 等集中式、文件差異式版本控制工具是一種挑戰(zhàn)與顛覆[7].所以本文采用GIT 作為版本控制器,在實(shí)驗(yàn)中將把代碼托管給Github.

2.3 集成測(cè)試

在持續(xù)集成中,測(cè)試是必不可少的部分,若未經(jīng)過(guò)測(cè)試直接集成于生產(chǎn)環(huán)境,會(huì)有重大的隱患.在構(gòu)建過(guò)程中考慮從倉(cāng)庫(kù)下拉代碼完畢后執(zhí)行開(kāi)發(fā)寫(xiě)完的單元測(cè)試用例,并生成XML 格式的測(cè)試報(bào)告給Jenkins 識(shí)別.測(cè)試成功則繼續(xù)后續(xù)的構(gòu)建步驟,若失敗則退出構(gòu)建.

2.4 CI/CD 應(yīng)用與Kubernetes 關(guān)鍵點(diǎn)

Jenkins 集群為Master 和Agent 節(jié)點(diǎn),在Kubernetes中,所有服務(wù)均為容器化構(gòu)建并由Kubernetes 管理,所以采用容器化搭建Jenkins Master 和Agent 服務(wù),并托管與Kubernetes 中.當(dāng)用戶觸發(fā)一次CI 時(shí),Jenkins Master 節(jié)點(diǎn)會(huì)向Agent 節(jié)點(diǎn)派送相應(yīng)的CI 任務(wù).考慮到在空閑時(shí),Agent 節(jié)點(diǎn)并無(wú)用處,故采用動(dòng)態(tài)構(gòu)建Agent節(jié)點(diǎn),在有CI 任務(wù)時(shí)由Jenkins Master 向Kubernetes Apiserver 發(fā)出構(gòu)建請(qǐng)求,可由Jenkins 中Kubernetes 該插件完成.

2.5 構(gòu)建具體流程

我們將CI/CD 的步驟可分為如下幾步[4],流程如圖2所示.

(1)開(kāi)發(fā)將代碼提交至GIT 倉(cāng)庫(kù).

(2)代碼發(fā)生變化后觸發(fā)GIT HOOK,Jenkins Master 節(jié)點(diǎn)請(qǐng)求Kubernetes Apiserver 生成新的Jenkins Agent Pod.

(3)Jenkins Slave Pod 生成后開(kāi)始構(gòu)建Jenkins Master 節(jié)點(diǎn)下發(fā)的任務(wù),從GIT 倉(cāng)庫(kù)中拉取代碼.

(4)代碼拉取成功后,開(kāi)始執(zhí)行單元測(cè)試,單元測(cè)試成功則繼續(xù)執(zhí)行,失敗則退出構(gòu)建任務(wù).

(5)CI 服務(wù)器根據(jù)預(yù)先定義的Pipeline 文件,將代碼進(jìn)行編譯.

(6)編譯完成后,打包成鏡像將鏡像推送至鏡像倉(cāng)庫(kù),并打上最新標(biāo)簽.

(7)CI 調(diào)用Kubernetes Cli,將預(yù)先設(shè)定好的Deployment 中的鏡像更改為剛剛構(gòu)建已推送至私用倉(cāng)庫(kù)的鏡像,從而完成部署.

圖2 構(gòu)建流程

3 實(shí)驗(yàn)測(cè)試

實(shí)驗(yàn)環(huán)境為3 臺(tái)已組成Kubernetes 集群的虛擬機(jī).系統(tǒng)為Ubuntu19.04 并對(duì)外暴露集群IP 為192.168.11.31.已將第一版本的代碼,使用Flask 框架編寫(xiě)的后端打包部署至該集群lab 的命名空間里,并通過(guò)NodePort 的方式對(duì)外暴露服務(wù),端口為30010,模擬生產(chǎn)環(huán)境的后端接口.此時(shí)我們使用curl 192.168.11.31：30010 命令,可返回預(yù)先設(shè)置好的字符串“This is first version code!”

(1)修改代碼,設(shè)置返回字符串為“This is second version code!”

(2)提交代碼并推送至GIT 倉(cāng)庫(kù).

(3)發(fā)現(xiàn)Jenkins Slave Pod 已經(jīng)自動(dòng)生成并開(kāi)始構(gòu)建任務(wù).

(4)稍等片刻,Jenkins Slave Pod 顯示終止中,查看Jenkins console output,發(fā)現(xiàn)已成功完成構(gòu)建任務(wù).

(5)再次嘗試curl 192.168.11.31：30010,返回的字符串是“This is second version code!”,即服務(wù)端代碼已成功更新.

實(shí)驗(yàn)測(cè)試過(guò)程如圖3所示.

圖3 實(shí)驗(yàn)測(cè)試

4 結(jié)論與展望

本文通過(guò)實(shí)踐可以發(fā)現(xiàn),比起傳統(tǒng)的需要人力去打包并手動(dòng)部署到服務(wù)器上從而需要大量的人力物力,該CI/CD 流水線僅需開(kāi)發(fā)人員上傳代碼后即能自動(dòng)打包部署至相應(yīng)的環(huán)境中,展現(xiàn)了符合期望的基于Kubernetes 的CI/CD 自動(dòng)化流水線,可大大提升開(kāi)發(fā)到交付的效率,并且可實(shí)現(xiàn)高并發(fā)彈性構(gòu)自動(dòng)化建流水線.對(duì)于擁有多個(gè)在Kubernetes 集群中的服務(wù)、需要快速迭代頻繁修改代碼并部署的項(xiàng)目具有省時(shí)省力且不容易出錯(cuò)的優(yōu)勢(shì).