[[403388]]

在這篇指南中，你將獲得使用 Kubernetes 和 Istio 使用 GitOps 進(jìn)行漸進(jìn)式交付(Progressive Delivery)的實(shí)際經(jīng)驗(yàn)。

介紹

Demo: https://github.com/stefanprodan/gitops-istio

GitOps 是什么?

GitOps 是一種進(jìn)行持續(xù)交付的方式，它使用 Git 作為聲明性(declarative)基礎(chǔ)設(shè)施和工作負(fù)載(workloads)的真實(shí)來(lái)源。對(duì)于 Kubernetes，這意味著使用 git push 而不是 kubectl apply/delete 或 helm install/upgrade。

在這個(gè) workshop 中，您將使用 GitHub 來(lái)托管配置存儲(chǔ)庫(kù)，并將 Flux 作為 GitOps 交付解決方案。

什么是漸進(jìn)式交付?

漸進(jìn)交付是高級(jí)部署模式(如金絲雀canaries、功能標(biāo)志feature flags和A/B測(cè)試A/B testing)的總稱(chēng)。漸進(jìn)交付技術(shù)通過(guò)讓?xiě)?yīng)用程序開(kāi)發(fā)人員和 SRE 團(tuán)隊(duì)對(duì)爆炸半徑blast radius進(jìn)行細(xì)粒度控制，從而降低在生產(chǎn)中引入新軟件版本的風(fēng)險(xiǎn)。

在這個(gè) workshop 中，您將使用 Flagger 和 Prometheus 為您的應(yīng)用程序自動(dòng)執(zhí)行 Canary 發(fā)布和 A/B Testing。

準(zhǔn)備工作

您將需要具有 LoadBalancer 支持的 Kubernetes 集群 v1.16 或更高版本。出于測(cè)試目的，您可以使用帶有 2 個(gè) CPU 和 4GB 內(nèi)存的 Minikube。

使用 Homebrew 安裝 flux CLI：

brew install fluxcd/tap/flux 

macOS AMD64/ARM64、Linux AMD64/ARM 和 Windows 的二進(jìn)制文件可在 flux2 release page 下載。

驗(yàn)證您的集群是否滿足前提條件：

flux check --pre 

使用 Homebrew 安裝 jq 和 yq：

brew install jq yq 

Fork 這個(gè)倉(cāng)庫(kù)并克隆它：

git clone https://github.com/<YOUR-USERNAME>/gitops-istio 
cd gitops-istio 

Cluster bootstrap

使用 flux bootstrap 命令，您可以在 Kubernetes 集群上安裝 Flux 并將其配置為從 Git 存儲(chǔ)庫(kù)管理自身。如果集群上存在 Flux 組件，則 bootstrap 命令將在需要時(shí)執(zhí)行升級(jí)。

通過(guò)指定您的 GitHub 存儲(chǔ)庫(kù) fork URL 來(lái)引導(dǎo) Flux：

flux bootstrap git \ 
  --author-email=<YOUR-EMAIL> \ 
  --url=ssh://git@github.com/<YOUR-USERNAME>/gitops-istio \ 
  --branch=main \ 
  --path=clusters/my-cluster 

上面的命令需要 ssh-agent，如果您使用的是 Windows，請(qǐng)參閱 flux bootstrap github 文檔。

在引導(dǎo)時(shí)，F(xiàn)lux 生成一個(gè) SSH key 并打印 public key。為了用 git 同步你的集群狀態(tài)，你需要復(fù)制 public key 并使用 write 創(chuàng)建一個(gè) deploy key 訪問(wèn)你的 GitHub 倉(cāng)庫(kù)。在 GitHub 上轉(zhuǎn)到 Settings > Deploy keys 點(diǎn)擊 Add deploy key， 勾選☑️ Allow write access，粘貼 Flux public key 并單擊 Add key。

當(dāng) Flux 訪問(wèn)你的存儲(chǔ)庫(kù)時(shí)，它會(huì)做以下事情：

• 安裝 Istio operator
• 等待 Istio 控制平面準(zhǔn)備好
• 安裝 Flagger、Prometheus 和 Grafana
• 創(chuàng)建 Istio 公共網(wǎng)關(guān)
• 創(chuàng)建 prod 命名空間namespace
• 創(chuàng)建負(fù)載測(cè)試器(load tester) deployment
• 創(chuàng)建前端(frontend) deployment 和金絲雀canary
• 創(chuàng)建后端(backend) deployment 和金絲雀canary

使用 Istio 引導(dǎo)集群時(shí)，定義 apply 順序很重要。對(duì)于要使用 Istio sidecar 注入的應(yīng)用程序 pod，Istio 控制平面必須在應(yīng)用程序之前啟動(dòng)并運(yùn)行。

在 Flux v2 中，你可以通過(guò)定義對(duì)象之間的依賴(lài)關(guān)系來(lái)指定執(zhí)行順序。例如，在 clusters/my-cluster/apps.yaml 中我們告訴 Flux，apps 的協(xié)調(diào)取決于一個(gè) istio-system ：

apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 
kind: Kustomization 
metadata: 
  name: apps 
  namespace: flux-system 
spec: 
  interval: 30m0s 
  dependsOn: 
    - name: istio-system 
  sourceRef: 
    kind: GitRepository 
    name: flux-system 
  path: ./apps 

首先觀測(cè) Flux 安裝 Istio，然后觀測(cè) demo apps：

watch flux get kustomizations 

您可以使用以下命令跟蹤 Flux reconciliation 日志：

flux logs --all-namespaces --follow --tail=10 

Istio 定制和升級(jí)

您可以使用位于 istio/system/profile.yaml 的 IstioOperator 資源自定義 Istio 安裝：

apiVersion: install.istio.io/v1alpha1 
kind: IstioOperator 
metadata: 
  name: istio-default 
  namespace: istio-system 
spec: 
  profile: demo 
  components: 
    pilot: 
      k8s: 
        resources: 
          requests: 
            cpu: 10m 
            memory: 100Mi 

修改 Istio 設(shè)置后，您可以將更改推送到 git，F(xiàn)lux 將在集群上應(yīng)用它。Istio operator 將根據(jù)您的更改重新配置 Istio 控制平面。

當(dāng)新的 Istio 版本可用時(shí)，update-istio GitHub Action workflow 工作流將打開(kāi)一個(gè)pull request，其中包含升級(jí) Istio Operator 所需的清單更新。新的 Istio 版本通過(guò) e2e workflow 在 Kubernetes Kind 上進(jìn)行測(cè)試，當(dāng) PR 合并到主分支時(shí)，F(xiàn)lux 將在集群內(nèi)升級(jí) Istio。

應(yīng)用程序引導(dǎo)

當(dāng) Flux 將 Git 存儲(chǔ)庫(kù)與您的集群同步時(shí)，它將創(chuàng)建前端/后端部署(frontend/backend deployment)、HPA 和一個(gè)金絲雀對(duì)象canary object。Flagger 使用 canary 定義創(chuàng)建了一系列對(duì)象：Kubernetes deployments、ClusterIP services、Istio 目標(biāo)規(guī)則(destination rules)和虛擬服務(wù)(virtual services)。這些對(duì)象在網(wǎng)格(mesh)上公開(kāi)(expose)應(yīng)用程序，并推動(dòng)金絲雀分析(canary analysis)和推廣(promotion)。

# applied by Flux 
deployment.apps/frontend 
horizontalpodautoscaler.autoscaling/frontend 
canary.flagger.app/frontend 
 
# generated by Flagger 
deployment.apps/frontend-primary 
horizontalpodautoscaler.autoscaling/frontend-primary 
service/frontend 
service/frontend-canary 
service/frontend-primary 
destinationrule.networking.istio.io/frontend-canary 
destinationrule.networking.istio.io/frontend-primary 
virtualservice.networking.istio.io/frontend 

檢查 Flagger 是否成功初始化了金絲雀：

kubectl -n prod get canaries 
 
NAME       STATUS        WEIGHT 
backend    Initialized   0 
frontend   Initialized   0 

當(dāng) frontend-primary 部署上線時(shí)，F(xiàn)lager 會(huì)將所有流量路由到主 Pod，并將 frontend 部署 scale 到零。

使用以下命令查找 Istio 入口網(wǎng)關(guān)(ingress gateway)地址：

kubectl -n istio-system get svc istio-ingressgateway -ojson | jq .status.loadBalancer.ingress 

打開(kāi)瀏覽器并導(dǎo)航到入口地址，您將看到前端 UI。

金絲雀發(fā)布

Flagger 實(shí)現(xiàn)了一個(gè)控制循環(huán)，該控制循環(huán)在測(cè)量關(guān)鍵性能指標(biāo)(如 HTTP 請(qǐng)求成功率、請(qǐng)求平均持續(xù)時(shí)間和 pod 運(yùn)行狀況)的同時(shí)，逐步將流量轉(zhuǎn)移到金絲雀。在分析 KPI 的基礎(chǔ)上，將金絲雀升級(jí)或中止，并將分析結(jié)果發(fā)布到 Slack。

金絲雀分析由以下任何對(duì)象的更改觸發(fā)：

部署 PodSpec(容器鏡像、命令、端口、環(huán)境等)

ConfigMaps 和 Secrets 作為卷(volumes)掛載或映射到環(huán)境變量

對(duì)于不接收恒定流量的工作負(fù)載，F(xiàn)lagger 可以配置一個(gè) webhook，當(dāng)它被調(diào)用時(shí)，將啟動(dòng)一個(gè)目標(biāo)工作負(fù)載的負(fù)載測(cè)試。canary 配置可以在 apps/backend/canary.yaml 上找到。

從 GitHub 拉取更改：

git pull origin main 

要觸發(fā)后端應(yīng)用程序的金絲雀部署，請(qǐng)碰撞容器鏡像：

yq e '.images[0].newTag="5.0.1"' -i ./apps/backend/kustomization.yaml 

提交和推送更改：

git add -A && \ 
git commit -m "backend 5.0.1" && \ 
git push origin main 

告訴 Flux 拉取更改或等待一分鐘讓 Flux 自行檢測(cè)更改：

flux reconcile source git flux-system 

觀測(cè) Flux 將您的集群與最新提交進(jìn)行協(xié)調(diào)：

watch flux get kustomizations 

幾秒鐘后，F(xiàn)lager 檢測(cè)到部署修訂(deployment revision)已更改并開(kāi)始新的 rollout：

$ kubectl -n prod describe canary backend 
 
Events: 
 
New revision detected! Scaling up backend.prod 
Starting canary analysis for backend.prod 
Pre-rollout check conformance-test passed 
Advance backend.prod canary weight 5 
... 
Advance backend.prod canary weight 50 
Copying backend.prod template spec to backend-primary.prod 
Promotion completed! Scaling down backend.prod 

在分析過(guò)程中，Grafana 可以監(jiān)控金絲雀的進(jìn)程。您可以通過(guò)端口轉(zhuǎn)發(fā)訪問(wèn)儀表板：

kubectl -n istio-system port-forward svc/flagger-grafana 3000:80 

Istio 儀表板的 URL 是 http://localhost:3000/d/flagger-istio/istio-canary?refresh=10s&orgId=1&var-namespace=prod&var-primary=backend-primary&var-canary=backend

請(qǐng)注意，如果在金絲雀分析(canary analysis)期間對(duì)部署應(yīng)用了新的更改，F(xiàn)lagger 將重新啟動(dòng)分析階段。

A/B 測(cè)試

除了加權(quán)路由(weighted routing)，F(xiàn)lagger 還可以配置為根據(jù) HTTP 匹配條件將流量路由到金絲雀。在 A/B 測(cè)試場(chǎng)景中，您將使用 HTTP headers 或 cookie 來(lái)定位用戶(hù)的特定部分。這對(duì)于需要會(huì)話(session)關(guān)聯(lián)的前端應(yīng)用程序特別有用。

您可以通過(guò)指定 HTTP 匹配條件和迭代次數(shù)來(lái)啟用 A/B 測(cè)試：

analysis: 
  # schedule interval (default 60s) 
  interval: 10s 
  # max number of failed metric checks before rollback 
  threshold: 10 
  # total number of iterations 
  iterations: 12 
  # canary match condition 
  match: 
    - headers: 
        user-agent: 
          regex: ".*Firefox.*" 
    - headers: 
        cookie: 
          regex: "^(.*?;)?(type=insider)(;.*)?$" 

上述配置將針對(duì) Firefox 用戶(hù)和擁有內(nèi)部 cookie 的用戶(hù)運(yùn)行兩分鐘的分析。前端配置可以在 apps/frontend/canary.yaml 中找到。

通過(guò)更新前端容器鏡像觸發(fā)部署：

yq e '.images[0].newTag="5.0.1"' -i ./apps/frontend/kustomization.yaml 
 
git add -A && \ 
git commit -m "frontend 5.0.1" && \ 
git push origin main 
 
flux reconcile source git flux-system 

Flager 檢測(cè)到部署修訂已更改并開(kāi)始 A/B 測(cè)試：

$ kubectl -n istio-system logs deploy/flagger -f | jq .msg 
 
New revision detected! Scaling up frontend.prod 
Waiting for frontend.prod rollout to finish: 0 of 1 updated replicas are available 
Pre-rollout check conformance-test passed 
Advance frontend.prod canary iteration 1/10 
... 
Advance frontend.prod canary iteration 10/10 
Copying frontend.prod template spec to frontend-primary.prod 
Waiting for frontend-primary.prod rollout to finish: 1 of 2 updated replicas are available 
Promotion completed! Scaling down frontend.prod 

您可以通過(guò)以下方式監(jiān)控所有金絲雀：

$ watch kubectl get canaries --all-namespaces 
 
NAMESPACE   NAME      STATUS        WEIGHT 
prod        frontend  Progressing   100 
prod        backend   Succeeded     0 

基于 Istio 指標(biāo)的回滾

Flagger 使用 Istio 遙測(cè)提供的指標(biāo)來(lái)驗(yàn)證金絲雀工作負(fù)載。前端應(yīng)用 analysis 定義了兩個(gè)指標(biāo)檢查：

metrics: 
   - name: error-rate 
     templateRef: 
       name: error-rate 
       namespace: istio-system 
     thresholdRange: 
       max: 1 
     interval: 30s 
   - name: latency 
     templateRef: 
       name: latency 
       namespace: istio-system 
     thresholdRange: 
       max: 500 
     interval: 30s 

用于檢查錯(cuò)誤率(error rate)和延遲的 Prometheus 查詢(xún)，位于 flagger-metrics.yaml。

在金絲雀分析期間，您可以生成 HTTP 500 errors 和高延遲(high latency)來(lái)測(cè)試 Flagger 的回滾。

生成 HTTP 500 errors：

watch curl -b 'type=insider' http://<INGRESS-IP>/status/500 

生成延遲：

watch curl -b 'type=insider' http://<INGRESS-IP>/delay/1 

當(dāng)失敗的檢查次數(shù)達(dá)到金絲雀分析閾值(threshold)時(shí)，流量將路由回主服務(wù)器，金絲雀縮放為零，并將推出(rollout)標(biāo)記為失敗。

$ kubectl -n istio-system logs deploy/flagger -f | jq .msg 
 
New revision detected! Scaling up frontend.prod 
Pre-rollout check conformance-test passed 
Advance frontend.prod canary iteration 1/10 
Halt frontend.prod advancement error-rate 31 > 1 
Halt frontend.prod advancement latency 2000 > 500 
... 
Rolling back frontend.prod failed checks threshold reached 10 
Canary failed! Scaling down frontend.prod 

您可以使用針對(duì) Prometheus、Datadog 和 Amazon CloudWatch 的自定義指標(biāo)檢查來(lái)擴(kuò)展分析。

有關(guān)為 Slack、MS Teams、Discord 或 Rocket 配置 canary 分析警報(bào)的信息，請(qǐng)參閱文檔。