陳 博,周亦敏

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

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

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

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

1 Kubernetes 架構(gòu)

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

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

(2)自動管理容器；

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

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

(5)易于擴容.

1.1 Kubernetes 組件

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

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

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

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

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

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

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

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

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

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

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

2 CI/CD 平臺設(shè)計

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

2.1 CI 工具選型

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

2.2 版本控制

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

2.3 集成測試

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

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

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

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

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

(1)開發(fā)將代碼提交至GIT 倉庫.

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

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

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

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

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

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

圖2 構(gòu)建流程

3 實驗測試

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

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

(2)提交代碼并推送至GIT 倉庫.

(3)發(fā)現(xiàn)Jenkins Slave Pod 已經(jīng)自動生成并開始構(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ù)端代碼已成功更新.

實驗測試過程如圖3所示.

圖3 實驗測試

4 結(jié)論與展望

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