Kubernetes如何加速UCloud內部代碼部署的CI/CD流程

UCloud內部長期使用 Gitlab 來管理代碼。雖然Gitlab作為一套開源平臺已很優秀，但我們對于其能為CI/CD提供的敏捷性并不十分滿意，內部實踐中的代碼發布周期仍需按天計算。為此，我們打造了一個基于Kubernetes的內部容器服務平臺（名為KUN），用于托管內部服務，并將Gitlab對接到KUN平臺，從而借助Kubernetes的云原生優勢，獲得更好的CI/CD效果。這套系統運行一年內，Gitlab的Pipeline一共觸發了994次，執行了約20000+次Job，在測試環境和正式環境一共進行了7000+次部署，即每天部署約20次。以下是該項目的一些實踐經驗。

我們對CI/CD的目標

CI即Continuous Integration（持續集成），指代碼集成到主干之前必須通過自動化測試，只要有一個測試用例失敗，就不能集成。目的是讓產品快速迭代的同時還能保持高質量。

CD有兩種意思：

Continuous Delivery，持續交付，指的是任何的修改都經過驗證，可以隨時實施部署到生產環境。
Continuous Deployment，持續部署，是持續交付的更高階段，指的是任何修改后的內容都經過驗證，自動化的部署到生產環境。
兩者的區別，在于是否自動部署到生產環境。對UCloud而言，肯定要以后者，也就是持續部署為目標。

Gitlab分支管理

我們采用的Gitlab分支管理模型在接入KUN平臺前后并未發生變化，故簡述如下：

master：主分支，代碼經過驗證。從 master 創建 tag 進行 Release。
dev：研發主分支，用于合入特性分支和補丁分支，在此分支。

臨時分支：
特性分支：用于開發某個特性；
補丁分支：用于修復線上 bug。
下面以一個實例來介紹CI/CD開發流程。StepFlow是UCloud新近推出的一款可視化工作流產品，通過StepFlow用戶可以靈活便捷地定義自己的工作流，快速實現業務功能。整套StepFlow系統由多個模塊組成，并全部部署在Kubernetes集群上。

在實例中，我們需要開發其中名為optimize-allocate 的一個feature：

則開發流程為：

1. 首先，在 Gitlab 上創建了編號為80的Issue，跟進這個optimize-allocate的feature；

2. 從dev分支創建一個新分支，名為feature/80-optimize-allocate，在該分支上進行開發；

3. 在feature/80-optimize-allocate上開發完成，進行commit，此時會觸發靜態測試、單元測試、Review等Pipeline Job；

4. 測試通過后，創建一個從feature/80-optimize-allocate到dev的merge request，由負責人進行審核。審核通過并且merge成功后，觸發靜態測試、單元測試、鏡像構建、鏡像部署、集成測試等Pipeline Job；

5. 測試通過后，創建一個從dev到master的mergerequest，由負責人進行審核。審核通過并且merge成功后，負責人創建tag v1.1.1，然后觸發靜態測試、單元測試、鏡像構建、鏡像部署、集成測試等Pipeline Job；

注：版本號tag是有命令規范的，v{x}.{y}.{z}代表著v{主版本}.{次版本}.{小修訂版本}

Gitlab CI/CD Pipeline

Gitlab 8.0版本以后，默認集成并開啟了Gitlab-CI，是可以提供一定CI能力的，我們以此搭建持續集成的流水線，其中有Pipeline、Stage和Job三個層級需要設計。

Pipeline

Gitlab 會檢測一個項目的根目錄下的 .Gitlab-CI.yml 文件，用戶可在該文件中定義 CI/CD Pipeline，一個 Pipeline 代表了 CI/CD 的整個過程。代碼發生變化時（比如 push、tag、merge等），將觸發一個 Pipeline 的運行。

Stage

一個 Pipeline 包含多個 Stage，比如“靜態檢查”、“單元測試”、“構建鏡像”等等，這些 Stage 一個接一個順序執行。

Job

每一個 Stage 可以包含多個 Job，同一個 Stage 的所有 Job 同時執行。每個Job需指定若干個重要屬性如image, stage, tags, service等。

在StepFlow例子中，針對要開發的feature，其Pipeline設計如下，包括靜態檢查、單元測試和最后的兩個手動 Code Review：

當其需要發布到公共測試環境（類似預發布環境），則設計另一個Pipeline，包括：執行完整的靜態檢查, 單元測試, 預發布鏡像 build, 預發布部署, 預發布集成測試。

而合并 master 之后觸發 prod 環境的另一個 Pipeline，包括靜態檢查、生產環境鏡像的 build、生產環節的部署、最后集成測試：

Gitlab Runner

我們將Gitlab Runner和Gitlab-CI配合使用，負責具體 Job 的運行。Gitlab Runner Kubernetes Executor 提供了在 Kubernetes 中運行 Job 的能力。運行原理如下：

Gitlab Runner 需要事先部署并注冊到 Gitlab 上；
當代碼發生更新時，Gitlab 根據用戶的配置，通知 runner 來運行 Job；
Gitlab Runner 使用某個鏡像來創建一個 Pod，然后在其中運行某些命令；
Gitlab Runner 將整個運行過程以及運行結果告訴 Gitlab。

Kaniko集成和改造：在容器中構建Docker鏡像

為了使用 CI/CD 將代碼變成最終運行在 Kubernetes 中的服務，必不可少的一步就是容器鏡像的構建。由于CI Job本身就是以容器的形式運行的，所以需要在容器中構建出 Docker 鏡像。

已有的方法，包括把 Host 上的 Docker Socket 掛載到 Pod 里面去（Docker Socket Mounting），或者是在 Pod 再啟動一個 Docker Daemon（Docker-in-Docker），然而，前者有安全風險，后者需要 Pod 具備特權，兩種方法都不適合。

Kaniko（https://github.com/GoogleContainerTools/kaniko）是 Google開源的一個工具，可以實現在 docker 容器里面制作 docker 鏡像，并且不需要任何特權。

但是原生的 Kaniko 鏡像由于缺少一些必要的工具，無法和Gitlab CI集成。為此我們修改了Kaniko鏡像，添加了整個busybox工具包進去，以支持其作為一個CI Job來運行。然后就可以把Gitlab往內部容器服務平臺KUN對接了。代碼示例如下:

use Docker:$ cd /path/to/project && \ docker build -t uhub.service.ucloud.cn/myimage:0.0.1 -f deploy/Dockerfile && \ docker push uhub.service.ucloud.cn/myimage:0.0.1# use Kaniko:$ /kaniko/executor -c /path/to/project -f deploy/Dockerfile -d uhub.service.ucloud.cn/myimage:0.0.1

KUN+Gitlab：基于Kubernetes的CI/CD流程

KUN中CI/CD的整個流程如上圖所示。從圖中我們可以看到，CI部分是一個單元測試，預發布部署，集成測試，Debug，提交代碼的循環過程。在CI過程中預發布的部署是通過CD系統來實現的，CI其中一個步驟是生成部署文件，然后按照項目、資源集、版本等參數提交到CD后端系統。CD系統提供了頁面入口，當部署文件推送到CD系統后，用戶可以在頁面查找對應的部署文件。如果需要部署，在頁面點擊“部署”按鈕即可實現部署。

YAML編輯器

為方便用戶使用，我們為KUN開發了專門的YAML編輯器，相比用普通的文本編輯器寫YAML，可以提供智能模板補全、搜索替換等能力。

上圖展示了一個使用案例，目前頁面編輯器支持的功能有：

Snippet：模版補全，用戶編輯文檔時，會提示相關模版，可選擇直接模版輸入

Hover：用戶鼠標放置關鍵字，提示關鍵字含義和官方文檔鏈接

搜索替換：使用?+F/Ctrl+F打開頁面搜索支持頁面直接查詢

部署系統

為了在Gitlab CI Job中把服務部署到Kubernetes上，我們研發了部署系統。在CI Pipeline的最后一步，用戶生成一個YAML文件，定義需要部署到Kubernetes上的資源，然后使用部署系統提供的一個工具鏡像，該鏡像會調用部署系統的API，將YAML提交給部署系統。接下來部署系統將使用用戶的權限，調用Kubernetes API實現真正的部署。

目前部署系統主要包含兩部分功能：

1. 資源集管理：

資源集是用戶項目下一個或多個資源的集合，資源指 Kubernetes 的 object 的描述文件，一般為 YAML 文件；
資源集分為多個版本，不同的版本對應資源的不同的描述文件；
用戶可以選擇某個版本，然后指定集群執行部署。

2. 部署任務

用戶每次部署都會生成一個 job，就是部署任務
執行部署后，用戶可在任務詳情頁直接查看部署任務日志。

當完成上述所有工作，Gitlab能很好嵌入KUN平臺，運行在Kubernetes上的各模塊就可像齒輪一樣有序運轉，從而獲得CI/CD上的良好效果。

前面提到的StepFlow項目，從一開始就實施了這樣一套 CI/CD，效率獲得了很大提升，每個編譯Job耗時約3分鐘，其他Job耗時在1分鐘以內。

總結

CI/CD是提供高質量互聯網服務必不可少的一環。Gitlab和Kubernetes都是非常優秀的開源軟件，在此基礎上，我們根據自己的實際情況，結合兩者打造了一套高效的CI/CD平臺，努力提升研發效率，為用戶提供更優質的服務。