基于 KubeVela 的 GitOps 交付
KubeVela 作為一個(gè)聲明式的應(yīng)用交付控制平面，天然就可以以 GitOps 的方式進(jìn)行使用，并且這樣做會(huì)在 GitOps 的基礎(chǔ)上為用戶(hù)提供更多的益處和端到端的體驗(yàn)，包括：
- 應(yīng)用交付工作流（CD 流水線(xiàn)）：KubeVela 支持在 GitOps 模式中描述過(guò)程式的應(yīng)用交付，而不只是簡(jiǎn)單的聲明終態(tài)；
- 處理部署過(guò)程中的各種依賴(lài)關(guān)系和拓?fù)浣Y(jié)構(gòu)；
- 在現(xiàn)有各種 GitOps 工具的語(yǔ)義之上提供統(tǒng)一的上層抽象，簡(jiǎn)化應(yīng)用交付與管理過(guò)程；
- 統(tǒng)一進(jìn)行云服務(wù)的聲明、部署和服務(wù)綁定；
- 提供開(kāi)箱即用的交付策略（金絲雀、藍(lán)綠發(fā)布等）；
- 提供開(kāi)箱即用的混合云/多云部署策略（放置規(guī)則、集群過(guò)濾規(guī)則等）；
- 在多環(huán)境交付中提供 Kustomize 風(fēng)格的 Patch 來(lái)描述部署差異，而無(wú)需學(xué)習(xí)任何 Kustomize 本身的細(xì)節(jié)
GitOps 模式需要依賴(lài) FluxCD 插件，所以在使用 GitOps 模式下交付應(yīng)用之前需要先啟用 FluxCD 插件。
vela addon enable fluxcdGitOps 工作流分為 CI 和 `CD 兩個(gè)部分：
- CI：持續(xù)集成對(duì)業(yè)務(wù)代碼進(jìn)行代碼構(gòu)建、構(gòu)建鏡像并推送至鏡像倉(cāng)庫(kù)。目前有許多成熟的 CI 工具：如開(kāi)源項(xiàng)目常用的 GitHub Action、Travis 等，以及企業(yè)中常用的 Jenkins、Tekton 等，KubeVela 圍繞 GitOps 可以對(duì)接任意工具下的 CI 流程。
- CD：持續(xù)部署會(huì)自動(dòng)更新集群中的配置，如將鏡像倉(cāng)庫(kù)中的最新鏡像更新到集群中。目前主要有兩種方案的 CD：
- Push-Based：Push 模式的 CD 主要是通過(guò)配置 CI 流水線(xiàn)來(lái)完成的，這種方式需要將集群的訪問(wèn)秘鑰共享給 CI，從而使得 CI 流水線(xiàn)能夠通過(guò)命令將更改推送到集群中。前面我們講解的 Jenkins 方式就屬于該方案。
- Pull-Based：Pull 模式的 CD 會(huì)在集群中監(jiān)聽(tīng)倉(cāng)庫(kù)（代碼倉(cāng)庫(kù)或者配置倉(cāng)庫(kù)）的變化，并且將這些變化同步到集群中。這種方式與 Push 模式相比，由集群主動(dòng)拉取更新，從而避免了秘鑰暴露的問(wèn)題。前面課程中我們講解的 Argo CD 與 Flux CD 就屬于這種模式。
而交付面向的人員有以下兩種：
- 面向平臺(tái)管理員/運(yùn)維人員的基礎(chǔ)設(shè)施交付，用戶(hù)可以通過(guò)直接更新倉(cāng)庫(kù)中的配置文件，從而更新集群中的基礎(chǔ)設(shè)施配置，如系統(tǒng)的依賴(lài)軟件、安全策略、存儲(chǔ)、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施配置。
- 面向終端開(kāi)發(fā)者的交付，用戶(hù)的代碼一旦合并到應(yīng)用代碼倉(cāng)庫(kù)，就自動(dòng)化觸發(fā)集群中應(yīng)用的更新，可以更高效的完成應(yīng)用的迭代，與 KubeVela 的灰度發(fā)布、流量調(diào)撥、多集群部署等功能結(jié)合可以形成更為強(qiáng)大的自動(dòng)化發(fā)布能力。
面向平臺(tái)管理員/運(yùn)維人員的交付
如下圖所示，對(duì)于平臺(tái)管理員/運(yùn)維人員而言，他們并不需要關(guān)心應(yīng)用的代碼，所以只需要準(zhǔn)備一個(gè) Git 配置倉(cāng)庫(kù)并部署 KubeVela 配置文件，后續(xù)對(duì)于應(yīng)用及基礎(chǔ)設(shè)施的配置變動(dòng)，便可通過(guò)直接更新 Git 配置倉(cāng)庫(kù)來(lái)完成，使得每一次配置變更可追蹤。
這里我們將部署一個(gè) MySQL 數(shù)據(jù)庫(kù)作為項(xiàng)目的基礎(chǔ)設(shè)施，同時(shí)部署一個(gè)業(yè)務(wù)應(yīng)用，使用這個(gè)數(shù)據(jù)庫(kù)。配置倉(cāng)庫(kù)的目錄結(jié)構(gòu)如下:
- clusters/ 中包含集群中的 KubeVela GitOps 配置，用戶(hù)需要將 clusters/ 中的文件手動(dòng)部署到集群中。這個(gè)是一次性的管控操作，執(zhí)行完成后，KubeVela 便能自動(dòng)監(jiān)聽(tīng)配置倉(cāng)庫(kù)中的文件變動(dòng)且自動(dòng)更新集群中的配置。其中，clusters/apps.yaml 將監(jiān)聽(tīng) apps/ 下所有應(yīng)用的變化，clusters/infra.yaml 將監(jiān)聽(tīng) infrastructure/ 下所有基礎(chǔ)設(shè)施的變化。
- apps/ 目錄中包含業(yè)務(wù)應(yīng)用的所有配置，在本例中為一個(gè)使用數(shù)據(jù)庫(kù)的業(yè)務(wù)應(yīng)用。
- infrastructure/ 中包含一些基礎(chǔ)設(shè)施相關(guān)的配置和策略，在本例中為 MySQL 數(shù)據(jù)庫(kù)。
├── apps
│ └── my-app.yaml
├── clusters
│ ├── apps.yaml
│ └── infra.yaml
└── infrastructure
└── mysql.yamlKubeVela 建議使用如上的目錄結(jié)構(gòu)管理你的 GitOps 倉(cāng)庫(kù)。clusters/ 中存放相關(guān)的 KubeVela GitOps 配置并需要被手動(dòng)部署到集群中，apps/ 和 infrastructure/ 中分別存放你的應(yīng)用和基礎(chǔ)設(shè)施配置。通過(guò)把應(yīng)用和基礎(chǔ)配置分開(kāi)，能夠更為合理的管理你的部署環(huán)境，隔離應(yīng)用的變動(dòng)影響。
clusters/ 目錄
首先，我們來(lái)看下 clusters 目錄，這也是 KubeVela 對(duì)接 GitOps 的初始化操作配置目錄。
以 clusters/infra.yaml 為例：
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: infra
spec:
components:
- name: database-config
type: kustomize
properties:
repoType: git
# 將此處替換成你需要監(jiān)聽(tīng)的 git 配置倉(cāng)庫(kù)地址
url: https://github.com/cnych/KubeVela-GitOps-Infra-Demo
# 如果是私有倉(cāng)庫(kù)，還需要關(guān)聯(lián) git secret
# secretRef: git-secret
# 自動(dòng)拉取配置的時(shí)間間隔，由于基礎(chǔ)設(shè)施的變動(dòng)性較小，此處設(shè)置為十分鐘
pullInterval: 10m
git:
# 監(jiān)聽(tīng)變動(dòng)的分支
branch: main
# 監(jiān)聽(tīng)變動(dòng)的路徑，指向倉(cāng)庫(kù)中 infrastructure 目錄下的文件
path: ./infrastructureapps.yaml 與 infra.yaml 幾乎保持一致，只不過(guò)監(jiān)聽(tīng)的文件目錄有所區(qū)別。在 apps.yaml 中，properties.path 的值將改為 ./apps，表明監(jiān)聽(tīng) apps/ 目錄下的文件變動(dòng)。
cluster 文件夾中的 GitOps 管控配置文件需要在初始化的時(shí)候一次性手動(dòng)部署到集群中，在此之后 KubeVela 將自動(dòng)監(jiān)聽(tīng) apps/ 以及 infrastructure/ 目錄下的配置文件并定期更新同步。
apps/ 目錄
apps/ 目錄中存放著應(yīng)用配置文件，這是一個(gè)配置了數(shù)據(jù)庫(kù)信息以及 Ingress 的簡(jiǎn)單應(yīng)用。該應(yīng)用將連接到一個(gè) MySQL 數(shù)據(jù)庫(kù)，并簡(jiǎn)單地啟動(dòng)服務(wù)。在默認(rèn)的服務(wù)路徑下，會(huì)顯示當(dāng)前版本號(hào)。在 /db 路徑下，會(huì)列出當(dāng)前數(shù)據(jù)庫(kù)中的信息。
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: my-app
namespace: default
spec:
components:
- name: my-server
type: webservice
properties:
image: cnych/kubevela-gitops-demo:main-76a34322-1697703461
port: 8088
env:
- name: DB_HOST
value: mysql-cluster-mysql.default.svc.cluster.local:3306
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: ROOT_PASSWORD
traits:
- type: scaler
properties:
replicas: 1
- type: gateway
properties:
class: nginx
classInSpec: true
domain: vela-gitops-demo.k8s.local
http:
/: 8088
pathType: ImplementationSpecific這是一個(gè)使用了 KubeVela 內(nèi)置組件類(lèi)型 webservice 的應(yīng)用，該應(yīng)用綁定了 gateway 運(yùn)維特征。通過(guò)在應(yīng)用中聲明運(yùn)維能力的方式，只需一個(gè)文件，便能將底層的 Deployment、Service、Ingress 集合起來(lái)，從而更為便捷地管理應(yīng)用。
infrastructure/ 目錄
infrastructure/ 目錄下存放一些基礎(chǔ)設(shè)施的配置。此處我們使用 mysql controller 來(lái)部署了一個(gè) MySQL 集群。
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: mysql
namespace: default
spec:
components:
- name: mysql-secret
type: k8s-objects # 需要添加一個(gè)包含 ROOT_PASSWORD 的 secret
properties:
objects:
- apiVersion: v1
kind: Secret
metadata:
name: mysql-secret
type: Opaque
stringData:
ROOT_PASSWORD: root321
- name: mysql-operator
type: helm
properties:
repoType: helm
url: https://helm-charts.bitpoke.io
chart: mysql-operator
version: 0.6.3
- name: mysql-cluster
type: raw
dependsOn:
- mysql-operator
- mysql-secret
properties:
apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
name: mysql-cluster
spec:
replicas: 1
secretName: mysql-secret在這個(gè) MySQL 應(yīng)用中，我們添加了 3 個(gè) KubeVela 的組件，第一個(gè)是一個(gè) k8s-objects 類(lèi)型的組件，也就是直接應(yīng)用 Kubernetes 資源對(duì)象，我們這里需要部署一個(gè) Secret 對(duì)象；然后添加一個(gè) helm 類(lèi)型的組件，用來(lái)部署 MySQL 的 Operator。當(dāng) Operator 部署成功且正確運(yùn)行后，最后我們將開(kāi)始部署 MySQL 集群。
部署 clusters/ 目錄下的文件
配置完以上文件并存放到 Git 配置倉(cāng)庫(kù)后，我們需要在集群中手動(dòng)部署 clusters/ 目錄下的 KubeVela GitOps 配置文件。
首先，在集群中部署 clusters/infra.yaml?？梢钥吹剿詣?dòng)在集群中拉起了 infrastructure/ 目錄下的 MySQL 部署文件：
$ kubectl apply -f clusters/infra.yaml
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
infra database-config kustomize running healthy 2023-10-19 15:27:28 +0800 CST
mysql mysql-operator helm running healthy Fetch repository successfully, Create helm release 2023-10-19 15:27:31 +0800 CST
successfully
└─ mysql-cluster raw running healthy 2023-10-19 15:27:31 +0800 CST至此，我們通過(guò)部署 KubeVela GitOps 配置文件，自動(dòng)在集群中拉起了數(shù)據(jù)庫(kù)基礎(chǔ)設(shè)施。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mysql-cluster-mysql-0 4/4 Running 0 35m
mysql-operator-0 2/2 Running 0 35m通過(guò)這種方式，我們可以方便地通過(guò)更新 Git 配置倉(cāng)庫(kù)中的文件，從而自動(dòng)化更新集群中的配置。
面向終端開(kāi)發(fā)者的交付
對(duì)于終端開(kāi)發(fā)者而言，在 KubeVela Git 配置倉(cāng)庫(kù)以外，還需要準(zhǔn)備一個(gè)應(yīng)用代碼倉(cāng)庫(kù)。在用戶(hù)更新了應(yīng)用代碼倉(cāng)庫(kù)中的代碼后，需要配置一個(gè) CI 來(lái)自動(dòng)構(gòu)建鏡像并推送至鏡像倉(cāng)庫(kù)中。KubeVela 會(huì)監(jiān)聽(tīng)鏡像倉(cāng)庫(kù)中的最新鏡像，并自動(dòng)更新配置倉(cāng)庫(kù)中的鏡像配置，最后再更新集群中的應(yīng)用配置。使用戶(hù)可以達(dá)成在更新代碼后，集群中的配置也自動(dòng)更新的效果，代碼倉(cāng)庫(kù)位于 https://github.com/cnych/KubeVela-GitOps-App-Demo。
準(zhǔn)備代碼倉(cāng)庫(kù)
準(zhǔn)備一個(gè)代碼倉(cāng)庫(kù)，里面包含一些源代碼以及對(duì)應(yīng)的 Dockerfile。這些代碼將連接到一個(gè) MySQL 數(shù)據(jù)庫(kù)，并簡(jiǎn)單地啟動(dòng)服務(wù)。在默認(rèn)的服務(wù)路徑下，會(huì)顯示當(dāng)前版本號(hào)。在 /db 路徑下，會(huì)列出當(dāng)前數(shù)據(jù)庫(kù)中的信息，基本代碼如下所示：
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
})
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
rows, err := db.Query("select * from userinfo;")
if err != nil {
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
}
for rows.Next() {
var username string
var desc string
err = rows.Scan(&username, &desc)
if err != nil {
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
}
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
}
})
if err := http.ListenAndServe(":8088", nil); err != nil {
panic(err.Error())
}我們希望用戶(hù)改動(dòng)代碼進(jìn)行提交后，自動(dòng)構(gòu)建出最新的鏡像并推送到鏡像倉(cāng)庫(kù)。這一步 CI 可以通過(guò)前面我們講解的 Jenkins 來(lái)實(shí)現(xiàn)，基本一致。
首先為代碼倉(cāng)庫(kù)創(chuàng)建一個(gè) Webhook，指向 Jenkins 的觸發(fā)器地址：
然后在 Jenkins 中創(chuàng)建一個(gè)名為 KubeVela-GitOps-App-Demo 的流水線(xiàn)：
并勾選 GitHub hook trigger for GITScm polling 觸發(fā)器。
觸發(fā)器
然后添加如下所示的流水線(xiàn)腳本：
void setBuildStatus(String message, String state) {
step([
$class: "GitHubCommitStatusSetter",
reposSource: [$class: "ManuallyEnteredRepositorySource", url: "https://github.com/cnych/KubeVela-GitOps-App-Demo"],
contextSource: [$class: "ManuallyEnteredCommitContextSource", context: "ci/jenkins/deploy-status"],
errorHandlers: [[$class: "ChangingBuildStatusErrorHandler", result: "UNSTABLE"]],
statusResultSource: [ $class: "ConditionalStatusResultSource", results: [[$class: "AnyBuildResult", message: message, state: state]] ]
]);
}
pipeline {
agent {
kubernetes {
cloud 'Kubernetes'
defaultContainer 'jnlp'
yaml '''
spec:
serviceAccountName: jenkins
containers:
- name: golang
image: golang:1.16-alpine3.15
command:
- cat
tty: true
- name: docker
image: docker:latest
command:
- cat
tty: true
env:
- name: DOCKER_HOST
value: tcp://docker-dind:2375
'''
}
}
stages {
stage('Prepare') {
steps {
script {
def checkout = git branch: 'main', url: 'https://github.com/cnych/KubeVela-GitOps-App-Demo.git'
env.GIT_COMMIT = checkout.GIT_COMMIT
env.GIT_BRANCH = checkout.GIT_BRANCH
def unixTime = (new Date().time.intdiv(1000))
def gitBranch = env.GIT_BRANCH.replace("origin/", "")
env.BUILD_ID = "${gitBranch}-${env.GIT_COMMIT.substring(0,8)}-${unixTime}"
echo "env.GIT_BRANCH=${env.GIT_BRANCH},env.GIT_COMMIT=${env.GIT_COMMIT}"
echo "env.BUILD_ID=${env.BUILD_ID}"
setBuildStatus("Deploy running", "PENDING");
}
}
}
stage('Test') {
steps {
container('golang') {
sh 'GOPROXY=https://goproxy.io CGO_ENABLED=0 GOCACHE=$(pwd)/.cache go test *.go'
}
}
}
stage('Build') {
steps {
withCredentials([[$class: 'UsernamePasswordMultiBinding',
credentialsId: 'docker-auth',
usernameVariable: 'DOCKER_USER',
passwordVariable: 'DOCKER_PASSWORD']]) {
container('docker') {
sh """
docker login -u ${DOCKER_USER} -p ${DOCKER_PASSWORD}
docker build -t cnych/kubevela-gitops-demo:${env.BUILD_ID} .
docker push cnych/kubevela-gitops-demo:${env.BUILD_ID}
"""
}
}
}
}
}
post {
success {
setBuildStatus("Deploy success", "SUCCESS");
}
failure {
setBuildStatus("Deploy failed", "FAILURE");
}
}
}構(gòu)建后我們就可以將應(yīng)用的鏡像打包后推送到 Docker Hub 去。
配置秘鑰信息
在新的鏡像推送到鏡像倉(cāng)庫(kù)后，KubeVela 會(huì)識(shí)別到新的鏡像，并更新倉(cāng)庫(kù)及集群中的 Application 配置文件。因此，我們需要一個(gè)含有 Git 信息的 Secret，使 KubeVela 向 Git 倉(cāng)庫(kù)進(jìn)行提交。部署如下文件，將其中的用戶(hù)名和密碼替換成你的 Git 用戶(hù)名及密碼（或 Token）：
apiVersion: v1
kind: Secret
metadata:
name: git-secret
type: kubernetes.io/basic-auth
stringData:
username: <your username>
password: <your password>準(zhǔn)備配置倉(cāng)庫(kù)
配置倉(cāng)庫(kù)與之前面向運(yùn)維人員的配置大同小異，只需要加上與鏡像倉(cāng)庫(kù)相關(guān)的配置即可。
修改 clusters/ 中的 apps.yaml，該 GitOps 配置會(huì)監(jiān)聽(tīng)倉(cāng)庫(kù)中 apps/ 下的應(yīng)用文件變動(dòng)以及鏡像倉(cāng)庫(kù)中的鏡像更新：
# ...... 省略其他的
imageRepository:
# 鏡像地址
image: <your image>
# 如果這是一個(gè)私有的鏡像倉(cāng)庫(kù)，可以通過(guò) `kubectl create secret docker-registry` 創(chuàng)建對(duì)應(yīng)的鏡像秘鑰并相關(guān)聯(lián)
secretRef: dockerhub-secret
filterTags:
# 可對(duì)鏡像 tag 進(jìn)行過(guò)濾
pattern: "^main-[a-f0-9]+-(?P<ts>[0-9]+)"
extract: "$ts"
# 通過(guò) policy 篩選出最新的鏡像 Tag 并用于更新
policy:
numerical:
order: asc
# 追加提交信息
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"修改 apps/my-app.yaml 中的 image 字段，在后面加上 # {"$imagepolicy": "default:apps"} 的注釋?zhuān)琄ubeVela 會(huì)通過(guò)該注釋去更新對(duì)應(yīng)的鏡像字段，default:apps 是上面 GitOps 配置對(duì)應(yīng)的命名空間和名稱(chēng)。
spec:
components:
- name: my-server
type: webservice
properties:
image: cnych/kubevela-gitops-demo:main-9e8d2465-1697703645 # {"$imagepolicy": "default:apps"}將 clusters/ 中包含鏡像倉(cāng)庫(kù)配置的文件更新到集群中后，我們便可以通過(guò)修改代碼來(lái)完成應(yīng)用的更新。
部署 clusters/apps.yaml：
$ kubectl apply -f clusters/apps.yaml
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
apps apps kustomize running healthy 2023-10-19 16:31:49 +0800 CST
my-app my-server webservice scaler,gateway runningWorkflow unhealthy Ready:0/1 2023-10-19 16:32:11 +0800 CST
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-server-6947fd65f9-84zhv 1/1 Running 0 2m這樣我們就可以通過(guò)部署 KubeVela GitOps 配置文件，自動(dòng)在集群中拉起應(yīng)用了。我們可以通過(guò) curl 應(yīng)用的 Ingress 來(lái)驗(yàn)證結(jié)果是否正確，可以看到目前的版本是 0.1.5，并且成功地連接到了數(shù)據(jù)庫(kù)：
$ kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server nginx vela-gitops-demo.k8s.local 80 115s
$ curl -H "Host:vela-gitops-demo.k8s.local" http://192.168.0.100
Version: 0.1.8
$ curl -H "Host:vela-gitops-demo.k8s.local" http://192.168.0.100/db
User: KubeVela
Description: It's a test user修改代碼
將代碼文件中的 Version 改為 0.2.0，并修改數(shù)據(jù)庫(kù)中的數(shù)據(jù):
const VERSION = "0.2.0"
...
func InsertInitData(db *sql.DB) {
stmt, err := db.Prepare(insertInitData)
if err != nil {
panic(err)
}
defer stmt.Close()
_, err = stmt.Exec("KubeVela2", "It's another test user")
if err != nil {
panic(err)
}
}提交該改動(dòng)至代碼倉(cāng)庫(kù)，正常我們配置的 CI 流水線(xiàn)就會(huì)自動(dòng)開(kāi)始構(gòu)建鏡像并推送至鏡像倉(cāng)庫(kù)。
而 KubeVela 會(huì)通過(guò)監(jiān)聽(tīng)鏡像倉(cāng)庫(kù)，根據(jù)最新的鏡像 Tag 來(lái)更新配置倉(cāng)庫(kù)中 apps/ 下的應(yīng)用 my-app。
此時(shí)，可以看到配置倉(cāng)庫(kù)中有一條來(lái)自 kubevelabot 的提交，提交信息均帶有 Update image automatically. 前綴。你也可以通過(guò) {{range .Updated.Images}}{{println .}}{{end}} 在 commitMessage 字段中追加你所需要的信息。
經(jīng)過(guò)一段時(shí)間后，應(yīng)用 my-app 就自動(dòng)更新了。KubeVela 會(huì)通過(guò)你配置的 interval 時(shí)間間隔，來(lái)每隔一段時(shí)間分別從配置倉(cāng)庫(kù)及鏡像倉(cāng)庫(kù)中獲取最新信息：
- 當(dāng) Git 倉(cāng)庫(kù)中的配置文件被更新時(shí)，KubeVela 將根據(jù)最新的配置更新集群中的應(yīng)用。
- 當(dāng)鏡像倉(cāng)庫(kù)中多了新的 Tag 時(shí)，KubeVela 將根據(jù)你配置的 policy 規(guī)則，篩選出最新的鏡像 Tag，并更新到 Git 倉(cāng)庫(kù)中。而當(dāng)代碼倉(cāng)庫(kù)中的文件被更新后，KubeVela 將重復(fù)第一步，更新集群中的文件，從而達(dá)到了自動(dòng)部署的效果。
通用我們可以通過(guò) curl 對(duì)應(yīng)的 Ingress 查看當(dāng)前版本和數(shù)據(jù)庫(kù)信息：
$ kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server nginx vela-gitops-demo.k8s.local 80 12m
$ curl -H "Host:vela-gitops-demo.k8s.local" http://<ingress-ip>
Version: 0.2.0
$ curl -H "Host:vela-gitops-demo.k8s.local" http://<ingress-ip>/db
User: KubeVela
Description: It's a test user
User: KubeVela2
Description: It's another test user版本已被成功更新！至此，我們完成了從變更代碼，到自動(dòng)部署至集群的全部操作。
總結(jié)
在運(yùn)維側(cè)，如若需要更新基礎(chǔ)設(shè)施（如數(shù)據(jù)庫(kù)）的配置，或是應(yīng)用的配置項(xiàng)，只需要修改配置倉(cāng)庫(kù)中的文件，KubeVela 將自動(dòng)把配置同步到集群中，簡(jiǎn)化了部署流程。
在研發(fā)側(cè)，用戶(hù)修改代碼倉(cāng)庫(kù)中的代碼后，KubeVela 將自動(dòng)更新配置倉(cāng)庫(kù)中的鏡像，從而進(jìn)行應(yīng)用的版本更新。通過(guò)與 GitOps 的結(jié)合，KubeVela 加速了應(yīng)用從開(kāi)發(fā)到部署的整個(gè)流程?？赡苣銜?huì)覺(jué)得這和 Flux CD 不是差不多嗎？的確是這樣的，KubeVela 的 GitOps 功能本身就是依賴(lài) Flux CD 的，但是 KubeVela 的功能可遠(yuǎn)遠(yuǎn)不止于此，比如說(shuō)上面我們的應(yīng)用使用的 MySQL 數(shù)據(jù)我們是通過(guò) MySQL Operator 來(lái)部署的，那如果我現(xiàn)在還換成云資源 RDS 呢？按照以前的方式方法，那么我們需要去云平臺(tái)手動(dòng)開(kāi)通 RDS 或者使用 Terraform 來(lái)進(jìn)行管理，但在 KubeVela 中我們完全可以幫助開(kāi)發(fā)者集成、編排不同類(lèi)型的云資源，涵蓋混合多云環(huán)境，讓你用統(tǒng)一地方式去使用不同廠商的云資源。同樣的我們只需要在 GitOps 倉(cāng)庫(kù)中的配置文件 Application 對(duì)象中去添加云資源的管理配置即可，這樣做到了一個(gè)對(duì)象管理多種資源的能力，這也是 KubeVela 的核心能力之一。
最后如果你覺(jué)得應(yīng)用太多管理不太方便，那么我們還可以使用 vela top 命令獲取平臺(tái)的概覽信息以及對(duì)應(yīng)用程序的資源狀態(tài)進(jìn)行診斷。
參考文檔：https://kubevela.io/zh/docs/end-user/gitops/fluxcd/。
