基于Kubernetes容器集群環境的持續交付平臺

韓東

摘要：傳統軟件交付模式偏向于手動，軟件從源碼到編譯、打包、測試、交付生產經歷不同的形態和系統環境。手動模式效率較低，且不同環境存在差異，容易引起錯誤導致軟件部署失敗。設計基于Kubernetes容器集群環境的持續交付平臺，利用容器技術的隔離特性屏蔽程序運行環境的差異，利用git、docker、Kubernetes的C/S架構模式，集成每個平臺的客戶端及相關構建工具，使程序在拉取項目、編譯、部署過程中擺脫命令行模式，只需在持續交付平臺中通過表單方式配置每個過程中所需的各項參數即可，將軟件交付過程中所有操作集中到統一平臺上，實現自動化交付。系統測試結果表明，持續交付平臺能夠自動完成軟件交付工作，打通了軟件交付各個環節的數據流和業務流。

關鍵詞：容器集群;持續交付;Docker;Kubernetes

DOI：10. 11907/rjdk. 201144

中圖分類號：TP319文獻標識碼：A 文章編號：1672-7800（2020）010-0186-05

Abstract：The traditional software delivery model tends to be manual， and the software experiences different forms and system environments from source code to compilation， packaging， testing， and production. Manual mode is inefficient， and differences in different environments can easily cause unexpected errors and cause software deployment failure. A continuous delivery platform is designed based on the Kubernetes container cluster environment， the isolation characteristics of container technology are used to shield the differences in program operating environments， and the C / S architecture model of git， docker， and Kubernetes is used to integrate the clients of each platform and related construction tools so that the program can get rid of the command-line mode in the process of pulling the project， compiling， and deploying. It only needs to configure the various parameters required in each process through the form in the continuous delivery platform to centralize all operations in the software delivery process so that a unified platform for automated delivery can be made. The system test results show that the continuous delivery platform can automatically complete the software delivery work and open up the data flow and business flow in all links of software delivery.

Key Words： container cluster; continuous delivery; Docker; Kubernetes

0 引言

持續交付是DevOps中的一個重要方法，主要研究如何通過自動化方法使得軟件部署與交付變得更加便利[1]。DevOps強調應持續集成與部署，做到每天進行價值交付，測試人員在軟件開發過程中就參與進來，每天進行集成測試，運維人員進行持續部署。DevOps強調通過自動化“軟件交付”和“架構變更”流程，使構建、測試、發布軟件更加快捷、頻繁及可靠[2-4]。矛盾在于軟件部署通常是復雜的，經常出現測試環境、生產環境與開發環境不一致的情況，從而導致軟件交付失敗。開發人員希望每天交付新功能，而運維人員期望系統保持穩定，這似乎是不可調和的矛盾[5-6]。在傳統模式下，軟件交付花費成本過高，導致DevOps期望的每天都能集成、測試與部署不能真正實現。

面對持續交付中的矛盾，相關學者與從業人員給出多種解決方法，如周振興[7]提出通過 GitHub以及 IBM Urban Code Deploy（UCD）工具進行自動化部署實現持續交付，并通過虛擬化技術 Docker 對系統進行水平擴展;丘暉[8]利用Jenkins的Pipeline功能實現Docker容器環境下的持續交付;郭雪[9]提出基于神經網絡的自調節持續集成與交付框架，利用神經網絡的自學習和自調節優勢為開發者預測與計劃最佳的下一次構建時機，從而幫助開發者合理平衡開發與集成;金澤鋒等[10]認為軟件交付時應注重價值交付，提出面向完整價值交付的文檔DevOps，并認為產品文檔應與軟件同時交付，避免出現軟件版本與文檔不匹配的問題。

本文提出基于Kubernetes容器集群環境的持續交付平臺，利用Docker容器的隔離特性屏蔽程序不同運行環境的差異性，引入Kubernetes容器集群及應用編排技術實現自動化交付。Kubernetes能夠應對復雜的軟件架構和應用場景，在DevOps理念被普遍接受的背景下，Docker、Kubernetes在軟件交付中已得到廣泛應用[11-12]。目前使用形式大多為：開發人員將編譯完成的程序包發送給運維人員，由運維人員根據需要使用命令行方式在運行Docker引擎的服務器上生成Docker鏡像，再使用Kubernetes的kubectl命令行工具，將容器部署到容器集群環境中。整個過程偏向于手動模式，各平臺之間的數據流斷裂。本文通過分析Docker、Kubernetes及gitlab各平臺系統架構，得出三者都是基于C/S架構模式，可利用各平臺開源的客戶端，集成到持續交付平臺中，在統一的平臺上集成所有操作，以表單方式配置各流程中的參數，避免使用命令行方式，實現交付流程的自動化。

1 持續交付平臺設計

持續交付平臺旨在管理一個軟件項目從開發到交付生產等一系列生命周期，從靜態代碼開始到編譯與打包，再到將程序包構建成Docker鏡像。Docker鏡像如果只存在于開發環境的機器中，則不便于共享與分發[13]，還需將鏡像推送至鏡像倉庫中。最后將構建好的鏡像按照軟件架構設計部署在容器集群中。在整個過程中，軟件項目從可編輯的源代碼到二進制程序包，再到容器鏡像，都需要借助相關平臺和工具。例如，使用github作為代碼版本控制工具[14]，而Docker鏡像是通過Docker引擎構建的[15]。持續交付平臺本身不是各項具體工作的實施者，而是交付流程的創建者，以及各平臺的統一組織者。持續交付平臺通過圖形化界面的方式進行操作，以表單方式配置各流程中的參數。

對于企業而言，首先要搭建一套基礎設施服務。受企業內部規定的限制，軟件項目可能只在企業內部網絡使用，并不想公開在互聯網上，例如企業不希望自己的項目源代碼托管在github上，也不希望自己的鏡像發布在Docker hub中，所以不能使用一些互聯網的公開服務，而需要企業自己在內部網絡構建一套基礎設施服務。本文使用gitlab作為代碼版本控制工具，以及harbor作為Docker鏡像Registry服務，搭建Docker引擎服務與Kubernetes服務集群。

持續交付流程是整個交付平臺的核心內容，基于各基礎平臺的持續交付平臺交付流程如圖1所示。

具體流程包括：

（1）從gitlab上拉取指定項目的源碼，并進行編譯與打包。

（2）根據項目的Dockerfile文件，向Docker平臺發出構建鏡像命令，Docker引擎會根據項目的Dockerfile進行鏡像構建。

（3）鏡像構建完成后，驅動Docker引擎將鏡像推送至指定鏡像倉庫中。

（4）根據項目架構設計，命令Kubernetes創建Deployment資源，指定相關鏡像和Pod副本數，部署至容器集群中。

（5）還需命令Kubernetes創建Service資源，用于服務發現。此時整個軟件項目完成交付，并提供訪問。

2 持續交付平臺實現

持續交付平臺實現的重點內容在于如何在平臺上操作各個基礎服務平臺，完成編譯打包、鏡像構建，以及對推送至容器集群中的各個資源進行創建與管理。幸運的是，各平臺都提供了不同語言版本的客戶端，并且開源。持續交付平臺需要集成這些客戶端，使用這些客戶端提供的API進行平臺化操作。其中，如何使用這些API實現編碼是一個關鍵問題。

2.1 客戶端選擇

持續交付平臺總體上使用Java語言加以實現，并使用Maven工具進行項目構建與管理，因此需要選擇各平臺Java版本的客戶端。各平臺客戶端Maven依賴詳情如表1所示。

2.2 編程實現

在編碼實現環節，省略了一般性通用功能的編碼實現，如平臺注冊/登錄等，而重點聚焦持續交付流程中核心功能的編碼實現。持續交付平臺需要與各基礎平臺進行交互，編碼重點在于如何利用集成的各平臺客戶端提供的API進行交互實現。

（1）將項目源碼克隆至本地。持續交付平臺與gitlab進行交互，需要傳遞代碼倉庫的URL和倉庫用戶名、密碼以及保存至本地的目錄。編碼實現如下：

public static void cloneGitRepository（GitRepository gitRepository， String localPath） throws Exception {

CloneCommand cc = Git.cloneRepository（）.setURI（gitRepository.getUrl（））;

cc.setCredentialsProvider（

new UsernamePasswordCredentialsProvider（gitRepository.getUsername（），

gitRepository.getPassword（）））;

cc.setDirectory（new File（localPath））。call（）;

}

（2）創建Docker鏡像。根據Dockerfile文件利用編譯完成的程序包構建Docker鏡像[16]，需要在操作系統的環境變量中配置Docker服務所在地址，如：DOCKER_HOST=tcp：//192.168.18.150：2375。Docker客戶端讀取DOCKER_HOST的值與Docker服務建立連接。編碼實現如下：

public String buildImage（String dockerFileDir， String tag） throws Exception {

final DockerClient dockerClient = DefaultDockerClient.fromEnv（）.build（）;

File dockerFile = new File（dockerFileDir）;

Path dockerFilePath = dockerFile.toPath（）;

DockerClient.BuildParam buildParam = new DockerClient.BuildParam（“t”， tag）;

return dockerClient.build（dockerFilePath， buildParam）;

}

（3）推送鏡像至Harbor鏡像倉庫。持續交付平臺與Docker平臺交互，將Docker鏡像推送至harbor鏡像倉庫中。一般來說，企業內部使用的是私有倉庫，需要提供倉庫的用戶名和密碼。編碼實現如下：

public void pushImage（String username， String pw， String image） throws Exception {

final DockerClient dockerClient = DefaultDockerClient.fromEnv（）.build（）;

final RegistryAuth registryAuth = RegistryAuth.create（username， pw， null，

HarborServerAddress， null， null）;

dockerClient.push（image， registryAuth）;

}

（4）創建Deployment資源，實現應用程序部署。持續交付平臺與Kubernetes進行交互，創建Deployment資源實例，由Deployment指揮 Kubernetes 創建與更新應用程序實例[17]。創建 Deployment 后，Kubernetes master 將應用程序實例調度到集群中的各個節點上[18]。首先需要創建Kubernetes客戶端，默認讀取當前系統用戶文件夾下的.kube/config文件。該文件是創建Kubernetes集群時生成的配置文件， config文件中描述了Kubernetes master節點地址信息，以及其它認證信息，然后與Kubernetesmaster節點建立連接。需要指定應用程序容器鏡像以及要運行Pod的副本數，對于私有倉庫，需要指定倉庫用戶名、密碼。編碼實現如下：

public void newDeployment（String deploymentName， String ns， int rs， Map labels， Map podSelector） {

Config config = new ConfigBuilder（）.build（）;

KubernetesClient client = new DefaultKubernetesClient（config）;

Deployment deployment = new DeploymentBuilder（）。build（）;

deployment.setKind（KubernetesConstraint.KUBERNETES_DEPLOYMENT）;

ObjectMeta deploymentMeta = new ObjectMeta（）;

deploymentMeta.setNamespace（ns）;

deploymentMeta.setName（deploymentName）;

deploymentMeta.setLabels（labels）;

deployment.setMetadata（deploymentMeta）;

DeploymentSpec spec = new DeploymentSpec（）;

spec.setReplicas（rs）;

LabelSelector labelSelector = new LabelSelector（）;

labelSelector.setMatchLabels（podSelector）;

spec.setSelector（labelSelector）;

PodTemplateSpec podTemplateSpec = newPodTemplate（）;

spec.setTemplate（podTemplateSpec）;

deployment.setSpec（spec）;

client.apps（）.deployments（）.create（deployment）;

}

（5）創建Service資源，實現服務暴露與發現。此時， Kubernetes僅為Pod創建了集群內部的虛擬IP，只有集群內部才能訪問[19]。Service資源可以暴露程序運行的服務，并且具有負載均衡功能。創建Service資源需要指定Service的name屬性，并通過Service選擇器與Pod標簽進行綁定。編碼實現如下：

public void newService（String serviceName， String ns， Map labels， Map selector） {

Config config = new ConfigBuilder（）.build（）;

KubernetesClient client = new DefaultKubernetesClient（config）;

Service service = new Service（）;

service.setKind（KubernetesConstraint.KUBERNETES_SERVICE）;

ObjectMeta serviceMeta = new ObjectMeta（）;

serviceMeta.setName（serviceName）;

serviceMeta.setNamespace（ns）;

serviceMeta.setLabels（labels）;

ServiceSpec serviceSpec = new ServiceSpec（）;

serviceSpec.setType（“NodePort”）;

serviceSpec.setSelector（selector）;

service.setSpec（serviceSpec）;

service.setMetadata（serviceMeta）;

client.services（）.create（service）;

}

3 案例測試

通過創建一個springboot微服務程序驗證持續交付平臺功能是否達到預期。測試程序能夠讀取主機名，以驗證負載均衡功能是否實現。主要測試能否正確構建Docker鏡像并推送至Harbor鏡像倉庫中;能否通過持續交付平臺在Kubernetes中部署該程序，并創建副本;能否通過持續交付平臺正確創建服務，實現從集群外部網絡進行訪問。

（1）鏡像構建與推送測試。構建Docker鏡像主要使用Dockerfile文件，Dockerfile文件中明確了Docker鏡像創建步驟[20]。測試程序的Dockerfile如下所示：

# 基礎鏡像

FROM openjdk：8-jdk-alpine

# 對應pom.xml文件中dockerfile-maven-plugin插件buildArgs配置項JAR_FILE的值

ARG JAR_FILE=target/*.jar

# 將打包完成后的jar文件復制到/opt目錄下

COPY ${JAR_FILE} /opt/app.jar

# 啟動容器時執行

ENTRYPOINT [“java”，“-Djava.security.egd=file：/dev/./urandom”，“-jar”，“/opt/app.jar”]

# 使用端口80

EXPOSE 80

使用持續交付平臺將鏡像打上標簽：hub.devops.com.helloworld/hello-app：v1，并推送至Harbor鏡像倉庫中。推送成功后，Habror平臺顯示如圖2所示。

（2）部署測試。通過持續交付平臺創建Deployment資源，資源名稱為springboot-app-depolyment，鏡像為hub.devops.com/helloworld/hello-app：v1，標簽為app=helloworld，Pod副本數為4。資源創建成功后，通過命令查看Kubernetes集群中的Deployment資源狀態如圖3所示。

圖3顯示成功創建并運行4個副本，查看Pod狀態如圖4所示。圖中顯示4個Pod正在運行。

（3）測試service資源能否將服務暴露出去。持續交付平臺創建service資源，類型為NodePort，節點端口為30715，目標Pod內部端口為80，需要作用于Pod的標簽為app=helloworld。使用命令查看創建結果如圖5所示。

使用Linux curl命令進行服務訪問，curl每次只訪問192.168.18.22：30715，結果顯示，返回的主機名每4次重復1次，說明service資源正常工作。每次訪問服務時，service使用輪詢算法進行負載均衡，如圖6所示。

4 結語

本文利用Kubernetes容器集群技術整合各基礎服務平臺客戶端，構建自動化的持續交付平臺，打通了軟件交付各環節數據流和業務流。然而，本文對持續交付平臺的研究仍存在不足之處，例如本文只研究了基于Java語言的構建工具，而在實際生產環境中有多種開發語言和技術架構，還需進一步研究基于其它語言與技術架構的構建工具，以應對更加復雜的應用場景。持續交付平臺關注軟件交付環節，因此面向軟件完整生命周期，對從需求提出到測試運維進行全流程管理的DevOps平臺將是未來研究的重點方向，以進一步將DevOps理念落地，打破開發/運維的隔閡之墻。

參考文獻：

[1] 付大亮. 拉動DevOps持續交付的三匹馬——快速交付實踐總結與思考[J]. 金融電子化，2018（3）：58-60.

[2] 高棟，王殿勝，張思琪，等. DevOps平臺建設分析[J]. 中國科技信息，2019，10（24）：39-40.

[3] 劉博涵，張賀，董黎明. DevOps中國調查研究[J]. 軟件學報，2019，30（10）：3206-3226.

[4] 牛曉玲，吳蕾. DevOps發展現狀研究[J]. 電信網技術，2017（10）：48-51.

[5] 李超，花磊，宋云奎. OpsFlow：一種面向DevOps的應用自動化部署引擎 [J]. 計算機與數字工程，2019，47（1）：190-194.

[6] 小棗菌. DevOps到底是什么意思[EB/OL]. https：//zhuanlan.zhihu.com/p/91371659.

[7] 周振興. 基于 Docker 和持續交付的項目管理系統設計與實現[D]. 大連：大連理工大學，2016.

[8] 丘暉. 基于容器的持續集成和部署方法研究[J]. 廣東通信技術，2017（10）：62-66.

[9] 郭雪. 基于神經網絡的過程自調節持續集成工具設計與實現[D]. 南京：南京大學，2019.

[10] 金澤鋒，張佑文，葉文華，等. 面向完整價值交付的文檔DevOps應用研究[J]. 軟件學報，2019，30（10）：3127-3147.

[11] 張文林. 持續交付及其在大型項目中的應用[J]. 軟件導刊，2017，16（10）：159-161.

[12] 梁惠惠. 對軟件開發模式變遷的研究[J]. 現代信息科技，2019，3（22）：1-8.

[13] MARKO L. Kubernetes in action[M]. 北京：電子工業出版社，2019.

[14] LEN B. The software architect and DevOps[J]. IEEE Software，2017，14（4）：8-10.

[15] 邊俊峰. 基于Docker的資源調度及應用容器集群管理系統設計與實現[D]. 濟南：山東大學，2017.

[16] 楊保華，戴王劍，曹亞侖. Docker技術入門與實踐[M]. 北京：機械工業出版社，2018.

[17] 馬征，繆凱，張廣溫. 淺析 Kubernetes 容器虛擬化技術[J]. 應用技術，2019，10（2）：63-64.

[18] ERIK D. The path to DevOps[J]. IEEE Software，2018（2）：71-75.

[19] 鄭冰. 基于Kubernetes的企業級容器云平臺設計[J]. 數字技術與應用，2019，37（6）：138-141.

[20] 翁湦元，單杏花，閻志遠，等. 基于Kubernetes的容器云平臺設計與實踐[J]. 鐵路計算機應用，2019，28（12）：49-53.

（責任編輯：黃 健）