使用 KubeSphere 與極狐GitLab 打造云原生持續(xù)交付系統(tǒng)

KubeSphere 簡介

Kubernetes 是一個(gè)非常復(fù)雜的容器編排平臺(tái)，學(xué)習(xí)成本非常高，KubeSphere 所做的事情就是高度產(chǎn)品化和抽象了底層 Kubernetes，是一個(gè)面向云原生的操作系統(tǒng)。講得再通俗一點(diǎn)，Kubernetes 屏蔽了底層容器運(yùn)行時(shí)的差異，而 KubeSphere 則屏蔽了底層 Kubernetes 集群的差異，它解決了 K8s 使用門檻高和云原生生態(tài)工具龐雜的痛點(diǎn)。你可以在可視化界面上點(diǎn)幾下鼠標(biāo)即可將 Pod 調(diào)度到集群的不同節(jié)點(diǎn)中，無需編寫 YAML。

上面是 KubeSphere 的功能架構(gòu)，可以看到 KubeSphere 包含了非常多的應(yīng)用場景，比如微服務(wù)、DevOps、應(yīng)用管理、可觀測性和安全等，每一個(gè)場景生態(tài)下面都包含了很多對(duì)研發(fā)和運(yùn)維人員比較友好的組件，而且所有的組件都是可插拔的，用戶可以根據(jù)自己的意愿自由選擇啟用哪個(gè)組件。

從 v4.0 開始，KubeSphere 會(huì)提供前后端可插拔的架構(gòu)和框架，任何第三方合作伙辦和 ISV 都可以基于 KubeSphere 4.0 開放框架，開發(fā)擴(kuò)展自己想要的功能插件，這些功能插件與 KubeSphere 有完全一致的 UI 體驗(yàn)，形成更強(qiáng)大的應(yīng)用生態(tài)。這就好比 Mac OS 和 App Store 之間的關(guān)系一樣，任何企業(yè)或團(tuán)隊(duì)都可以發(fā)布自己開發(fā)的插件到應(yīng)用商店，靈活滿足各類用戶的需求，在社區(qū)與 KubeSphere 合作互利共贏。

極狐GitLab 簡介

極狐GitLab 是一個(gè)一體化的 DevOps 平臺(tái)，可以簡單理解為 GitLab 在國內(nèi)的“發(fā)行版”。是由極狐(GitLab)公司推出的產(chǎn)品（極狐(GitLab)公司是以“中外合資3.0”模式成立的公司，在國內(nèi)獨(dú)立運(yùn)營，為國內(nèi)用戶提供適合本土化的 DevOps 平臺(tái)以及支持服務(wù)）。

極狐GitLab 是開源的，任何人都可以參與開源共建，代碼托管在極狐GitLab SaaS 上：https://jihulab.com/gitlab-cn/gitlab。其提供的一體化 DevOps 能力覆蓋軟件開發(fā)全生命周期（從計(jì)劃到運(yùn)維），同時(shí)內(nèi)置了安全功能，能夠利用開箱即用的安全能力構(gòu)建 DevSecOps 體系。

更重要的一點(diǎn)是，極狐GitLab 支持自建（私有部署）和 SaaS 兩種服務(wù)。在私有部署的時(shí)候，支持多種安裝方式，其中就包括云原生的安裝方式，因此，結(jié)合 KubeSphere 和極狐GitLab，可以打造出一個(gè)適應(yīng)云原生時(shí)代的持續(xù)交付系統(tǒng)。

在 KubeSphere 上安裝極狐GitLab 和 Runner

目前在 KubeSphere 上部署極狐GitLab 非常便利，只需要利用 KubeSphere 的應(yīng)用商店即可一鍵部署。

應(yīng)用商店^[1]與應(yīng)用全生命周期管理是 KubeSphere 獨(dú)有的特色，KubeSphere 為用戶提供了一個(gè)基于 Helm 的應(yīng)用商店，用于應(yīng)用生命周期管理。而且從 3.2.0 版本開始，KubeSphere 新增了 “動(dòng)態(tài)加載應(yīng)用商店” 的功能，合作伙伴可申請(qǐng)將應(yīng)用的 Helm Chart 集成到 KubeSphere 應(yīng)用商店^[2]，相關(guān)的 Pull Request 被合并后，KubeSphere 應(yīng)用商店即可動(dòng)態(tài)加載應(yīng)用，不再受到 KubeSphere 版本的限制。目前極狐 Gitlab 就是通過動(dòng)態(tài)加載的方式將其 Helm Chart 上架到了 KubeSphere 的應(yīng)用商店。

安裝極狐GitLab

直接選擇下圖紅色方框中的 jh-gitlab 即可開始部署。

下一步需要修改一些參數(shù)，即 Helm Chart 中的 values。

大家需要根據(jù)自己的實(shí)際情況修改，我的私有環(huán)境不需要 Ingress，可以通過 Cluster IP 直連，所以才將域名全部設(shè)置成了 Service Name。除此之外，還需要取消安裝 Runner，后續(xù)再單獨(dú)安裝。其他參數(shù)可以自己酌情修改，比如我取消了 Certmanager 和 Ingress-Nginx。

查看創(chuàng)建好的工作負(fù)載：

部署完成后，就可以通過設(shè)置好的域名訪問極狐GitLab。

默認(rèn)用戶名是 root，初始密碼可以通過以下命令獲取：

$?kubectl?-n?jh-gitlab?get?secret?jh-gitlab-gitlab-initial-root-password?-o?go-template?--template='{{.data.password}}'?|?base64?-D

登錄之后可以先創(chuàng)建一個(gè)項(xiàng)目，下面安裝 Runner 和演示 Demo 的章節(jié)都會(huì)用到。

安裝極狐GitLab Runner

極狐GitLab Runner 只是極狐GitLab 的其中一個(gè)組件，所以不能再通過應(yīng)用商店來安裝。KubeSphere 除了過應(yīng)用商店之外，還可以通過應(yīng)用倉庫和應(yīng)用模板來安裝應(yīng)用。所謂應(yīng)用倉庫，就是一個(gè)寬松版的應(yīng)用商店，應(yīng)用商店是所有用戶共用的，應(yīng)用倉庫只是個(gè)人版的應(yīng)用商店，不需要審批，只會(huì)存在于你自己的集群中。只需將相關(guān)應(yīng)用 Helm Chart 的 URL 導(dǎo)入，即可變成應(yīng)用倉庫中的一個(gè)應(yīng)用。這里我們選擇導(dǎo)入極狐GitLab 的 Helm Chart。

然后在『應(yīng)用』中點(diǎn)擊『創(chuàng)建』。

然后選擇『從應(yīng)用模板』，在彈出面板的下拉框中選擇 GitLab。

選擇 gitlab-runner，然后設(shè)置應(yīng)用名稱，繼續(xù)點(diǎn)擊下一步，開始修改部署參數(shù)。

其中，gitlabUrl 的值為極狐GitLab 的可視化界面地址，runnerRegistrationToken 的值可以設(shè)置為想要使用該 Runner 的項(xiàng)目的 CI/CD Specific runners 的 registration token，例如：

同時(shí)還需要開啟 RBAC：

rbac:
??create:?true
??rules:?[]
??clusterWideAccess:?false
??podSecurityPolicy:
????enabled:?false
????resourceNames:
??????-?gitlab-runner

其他參數(shù)可根據(jù)實(shí)際情況酌情修改，修改完成后點(diǎn)擊下一步開始安裝。安裝完成后，可以進(jìn)入 Pod 查看注冊(cè)情況：

$?kubectl?-n?jh-gitlab?get?pod?-l?release=gitlab-runner
NAME??????????????????????????????????????????READY???STATUS????????RESTARTS???AGE
gitlab-runner-gitlab-runner-c7c999dfc-wgg56???1/1?????Running???????0??????????61s

$?kubectl?-n?jh-gitlab?exec?-it?gitlab-runner-gitlab-runner-c7c999dfc-wgg56?--?bash
Defaulted?container?"gitlab-runner-gitlab-runner"?out?of:?gitlab-runner-gitlab-runner,?configure?(init)
bash-5.0$?gitlab-runner?list
Runtime?platform????????????????????????????????????arch=amd64?os=linux?pid=106?revision=f761588f?version=14.10.1
Listing?configured?runners??????????????????????????ConfigFile=/home/gitlab-runner/.gitlab-runner/config.toml
gitlab-runner-gitlab-runner-c7c999dfc-wgg56?????????Executor=kubernetes?Token=dSz6WoJzpD5bjkDhP5xN?URL=https://jihulab.com/
bash-5.0$

可以看到 Pod 里面已經(jīng)內(nèi)置了 gitlab-runner 命令，且有注冊(cè)成功的 Runner 實(shí)例 gitlab-runner-gitlab-runner-c7c999dfc-wgg56，而這就是剛剛用應(yīng)用模板安裝的 Runner。在極狐GitLab 的 Web 頁面也可以看到注冊(cè)成功的 Runner。

CI/CD Demo 演示

接下來我們通過一個(gè)簡單的流水線示例來演示極狐GitLab 的 CI/CD 流水線工作原理。演示流水線之前，先來了解幾個(gè)基本概念。

極狐GitLab 流水線包含兩個(gè)核心組件：

• Job : 描述需要執(zhí)行的任務(wù)；
• Stage : 定義 Job 執(zhí)行的順序。

而流水線（Pipeline）則是一組運(yùn)行在各個(gè) Stage 中的 Job 集合，可以包含多個(gè)流程：編譯、測試、部署等等，任何提交或 Merge Request 都能觸發(fā)流水線。

負(fù)責(zé)執(zhí)行 Job 的就是 Runner，Runner 的本體，是運(yùn)行在某臺(tái)機(jī)器上的守護(hù)進(jìn)程，類似于 Jenkins agent。在 Runner 自己看來，沒有類型的區(qū)別，它只是根據(jù) Token 和 URL，注冊(cè)到指定的極狐GitLab 而已。

講完了基礎(chǔ)概念，直接來看示例倉庫。

這個(gè)示例應(yīng)用是用 Go 寫的 HTTP Server，代碼很簡單，我就不解釋了。

package?main

import?(
????"fmt"
????"log"
????"net/http"
)

func?handler(w?http.ResponseWriter,?r?*http.Request)?{
????fmt.Fprintf(w,?"Hello?this?is?kubesphere")
}

func?main()?{
????http.HandleFunc("/ks",?handler)
????log.Fatal(http.ListenAndServe(":9999",?nil))
}

流水線編排文件是 .gitlab-ci.yml，內(nèi)容如下：

stages:
??-?build
??-?deploy

build:
??image:?
????name:?gcr.io/kaniko-project/executor:debug
????entrypoint:?[""]
??stage:?build
??tags:?
????-?kubernetes
??script:
????-?mkdir?-p?/kaniko/.docker
????-?echo?"{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf?"%s:%s"?"${CI_REGISTRY_USER}"?"${CI_REGISTRY_PASSWORD}"?|?base64?|?tr?-d?'\n')\"}}}"?>?/kaniko/.docker/config.json
????-?>-
??????/kaniko/executor
??????--context?"${CI_PROJECT_DIR}"
??????--dockerfile?"${CI_PROJECT_DIR}/Dockerfile"
??????--destination?"${CI_REGISTRY_IMAGE}:1.0.0"

deploy:
??image:?bitnami/kubectl:latest
??stage:?deploy
??tags:?
????-?kubernetes
??variables:
????KUBERNETES_SERVICE_ACCOUNT_OVERWRITE:?jh-gitlab
??only:
????-?main
??script:
????-?kubectl?-n?jh-gitlab?apply?-f?deployment.yaml

由于最新版的 Kubernetes 無情地拋棄了 Docker，推薦使用 Containerd 作為運(yùn)行時(shí)，所以就沒法使用 Docker 來構(gòu)建鏡像啦，我們可以選擇使用 Kaniko。Kaniko 是谷歌開源的一款用來構(gòu)建容器鏡像的工具。與 Docker 不同，Kaniko 并不依賴于 Docker Daemon 進(jìn)程，完全是在用戶空間根據(jù) Dockerfile 的內(nèi)容逐行執(zhí)行命令來構(gòu)建鏡像，這就使得在一些無法獲取 Docker Daemon 進(jìn)程的環(huán)境下也能夠構(gòu)建鏡像，比如在標(biāo)準(zhǔn)的 Kubernetes 集群上。

這個(gè)流水線總共包含兩個(gè)階段：構(gòu)建和部署。部署階段需要注意的是，默認(rèn)情況下 Kubernetes 中的 Pod 是沒有權(quán)限創(chuàng)建工作負(fù)載的，所以我們需要?jiǎng)?chuàng)建一個(gè)新的 ServiceAccount，將其綁定到具有權(quán)限的 ClusterRole 上面。

#?rbac.yaml
apiVersion:?v1
kind:?ServiceAccount
metadata:
??name:?jh-gitlab
??namespace:?jh-gitlab
---
apiVersion:?rbac.authorization.k8s.io/v1
kind:?ClusterRoleBinding
metadata:
??name:?gitlab-admin
roleRef:
??apiGroup:?rbac.authorization.k8s.io
??kind:?ClusterRole
??name:?cluster-admin
subjects:
??-?kind:?ServiceAccount
????name:?jh-gitlab
????namespace:?jh-gitlab

$?kubectl?apply?-f?rbac.yaml

最后再讓 Runner 使用這個(gè)新的 ServiceAccount，即：

??variables:
????KUBERNETES_SERVICE_ACCOUNT_OVERWRITE:?jh-gitlab

但是這樣還不行，默認(rèn)情況下流水線沒有權(quán)限修改 Runner 的 ServiceAccount，需要修改 Runner 的部署清單，賦予其修改權(quán)限。

注意圖中右側(cè)的高亮部分，表示允許 jh-gitlab 這個(gè) namespace 下面的 Pod 更改其 ServiceAccount。修改完畢后點(diǎn)擊更新即可。

這是我的完整配置，供大家參考：

imagePullPolicy:?IfNotPresent
gitlabUrl:?'https://jihulab.com/'
runnerRegistrationToken:?GR1348941fycCAhY3_LnRFPqy3DL4
terminationGracePeriodSeconds:?3600
concurrent:?10
checkInterval:?30
sessionServer:
??enabled:?false
rbac:
??create:?true
??rules:?[]
??clusterWideAccess:?false
??podSecurityPolicy:
????enabled:?false
????resourceNames:
??????-?gitlab-runner
metrics:
??enabled:?false
??portName:?metrics
??port:?9252
??serviceMonitor:
????enabled:?false
service:
??enabled:?false
??type:?ClusterIP
runners:
??config:?|
????[[runners]]
??????[runners.kubernetes]
????????namespace?=?"{{.Release.Namespace}}"
????????image?=?"ubuntu:16.04"
??privileged:?true
??tags:?"kubernetes"
??cache:?{}
??builds:?{}
??services:?{}
??helpers:?{}
securityContext:
??runAsUser:?100
??fsGroup:?65533
resources:?{}
affinity:?{}
nodeSelector:?{}
tolerations:?[]
envVars:
??-?name:?KUBERNETES_SERVICE_ACCOUNT_OVERWRITE_ALLOWED
????value:?jh-gitlab
hostAliases:?[]
podAnnotations:?{}
podLabels:?{}
secrets:?[]
configMaps:?{}

現(xiàn)在隨便修改倉庫中的文件（比如 README）來觸發(fā)流水線。

可以看到流水線被成功觸發(fā)并執(zhí)行成功。最后我們來看看構(gòu)建好的鏡像有沒有被成功部署。

從 KubeSphere 可視化界面里可以看到應(yīng)用被成功部署了。最后可以測試一下這個(gè) HTTP Server 是否正常工作：

$?kubectl?-n?jh-gitlab?get?pod?-l?app=cicd-demo?-owide
NAME?????????????????????????READY???STATUS????RESTARTS???AGE?????IP?????????????NODE???????????NOMINATED?NODE???READINESS?GATES
cicd-demo-86d7fb797c-428xs???1/1?????Running???0??????????4m40s???10.233.65.81???k3s-worker02??????????????

$?curl?http://10.233.65.81:9999/ks
Hello?this?is?kubesphere

總結(jié)

本文給大家介紹了 KubeSphere 和極狐GitLab 以及各自的優(yōu)勢，并探討了如何結(jié)合 KubeSphere 和極狐GitLab 來打造一個(gè)云原生時(shí)代的持續(xù)交付系統(tǒng)，最后通過一個(gè)流水線示例來展示極狐 GiLab 流水線的工作原理。

從最后的示例可以看出，CD（即部署階段）的過程還是比較麻煩的，比如需要安裝配置額外工具（kubectl），還需要 Kubernetes 對(duì)其進(jìn)行授權(quán)，如果 Kubernetes 部署在云平臺(tái)中，還需要云平臺(tái)對(duì)其授權(quán)。最重要的是，它無法感知部署的狀態(tài)，部署完了之后無法獲知該工作負(fù)載是否正常提供服務(wù)。

那么這個(gè)問題有沒有解決辦法呢？我將在下一篇文章中給大家介紹如何通過 GitOps 來解決這個(gè)問題。

引用鏈接