Istio 結(jié)合 Flagger 進(jìn)行灰度發(fā)布
灰度發(fā)布也叫金絲雀部署 ，是指通過控制流量的比例，實(shí)現(xiàn)新老版本的逐步替換。比如對于服務(wù) A 有兩個(gè)版本（藍(lán)和綠兩個(gè)版本），當(dāng)前兩個(gè)版本同時(shí)部署，但是 version1 比例 90% ，version2 比例 10% ，然后我們可以觀察 version2 的實(shí)際運(yùn)行效果，如果符合預(yù)期，則可以逐步調(diào)整流量占比，比如調(diào)整為 80:20 -> 70:30 -> 10:90 -> 0:100 ，最終 version1 版本下線，全部替換成 version2 版本。如果驗(yàn)證失敗，切換 100%流量回 v1 版本（回滾）。灰度發(fā)布的特點(diǎn)是：
flagger
在 Istio 中要實(shí)現(xiàn)灰度發(fā)布有多種方案，比如 Flagger、Argo Rollouts 等。
Flagger
Flagger 是一個(gè)漸進(jìn)式交付的 Kubernetes Operator，它可以自動執(zhí)行 Kubernetes 上運(yùn)行的應(yīng)用程序的發(fā)布過程。它通過在測量指標(biāo)和運(yùn)行一致性測試的同時(shí)逐漸將流量轉(zhuǎn)移到新版本，降低了在生產(chǎn)中引入新軟件版本的風(fēng)險(xiǎn)。
Flagger 通過使用服務(wù)網(wǎng)格（App Mesh、Istio、Linkerd、Kuma、Open Service Mesh）或 Ingress 控制器（Contour、Gloo、NGINX、Skipper、 Traefik、APISIX）用于流量路由。對于發(fā)布分析，F(xiàn)lagger 可以查詢 Prometheus、InfluxDB、Datadog、New Relic、CloudWatch、Stackdriver 或 Graphite，并使用 Slack、MS Teams、Discord 和 Rocket 來發(fā)出警報(bào)。
Flagger
Flagger 可以使用 Kubernetes CRD 進(jìn)行配置，并且與任何為 Kubernetes 制作的 CI/CD 解決方案兼容。由于 Flagger 是聲明性的對 Kubernetes 事件做出反應(yīng)，因此它可以與諸如此類的工具一起在 GitOps 管道中使用。
安裝 Flagger
要使用 Flagger，需要先選擇一個(gè)受支持的路由提供商（比如我們這里使用 Istio），然后使用 Helm 或 Kustomize 安裝 Flagger。
Flagger 需要 Kubernetes 集群 v1.16 或更高版本以及 Istio v1.5 或更高版本。
首先當(dāng)然需要安裝 Istio，并開啟 Prometheus 插件：
# demo 或者 default 都可以
istioctl manifest install --set profile=demo -y
# istio 根目錄
kubectl apply -f samples/addons/prometheus.yaml然后在 istio-system 命名空間安裝 Flagger：
$ git clone https://github.com/fluxcd/flagger && cd flagger
$ kubectl apply -k kustomize/istio
$ kubectl get pods -n istio-system -l app=flagger
NAME READY STATUS RESTARTS AGE
flagger-ff76bfdff-kkcmz 1/1 Running 0 17m測試應(yīng)用
下面我們創(chuàng)建一個(gè)名為 test 的命名空間，并為其啟用 Istio sidecar 自動注入：
kubectl create ns test
kubectl label namespace test istio-injectinotallow=enabled接下來我們使用 flagger 官方提供的 podinfo 應(yīng)用來進(jìn)行測試：
kubectl apply -k kustomize/podinfo該命令會為 podinfo 應(yīng)用創(chuàng)建對應(yīng)的 Deployment 和一個(gè) HPA 對象。
$ kubectl get deployment -n test
NAME READY UP-TO-DATE AVAILABLE AGE
podinfo 2/2 2 0 96s
$ kubectl get hpa -n test
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
podinfo Deployment/podinfo <unknown>/99% 2 4 2 60s部署后，我們可以看到 podinfo 應(yīng)用的容器數(shù)量已經(jīng)變成了 2 個(gè)（自動注入了 istio sidecar），而且 HPA 也已經(jīng)生效。
```bash
$ kubectl get pods -n test
NAME READY STATUS RESTARTS AGE
podinfo-584c4546df-fzw4d 0/2 PodInitializing 0 5m26s
podinfo-584c4546df-n28cf 0/2 PodInitializing 0 5m11s接著我們再部署一個(gè)負(fù)載測試服務(wù)用于在金絲雀分析期間生成流量：
kubectl apply -k kustomize/tester創(chuàng)建金絲雀
接下來我們就可以創(chuàng)建一個(gè) Canary 自定義資源來實(shí)現(xiàn)我們的金絲雀發(fā)布了。Canary 對象是 Flagger 的核心，它描述了金絲雀發(fā)布的目標(biāo)。如下所示，我們?yōu)?nbsp;podinfo 應(yīng)用創(chuàng)建一個(gè) Canary 對象：
# podinfo-canary.yaml
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
name: podinfo
namespace: test
spec:
targetRef: # deployment 引用
apiVersion: apps/v1
kind: Deployment
name: podinfo
progressDeadlineSeconds: 60 # 金絲雀部署升級最大處理時(shí)間（以秒為單位）（默認(rèn)600秒）
autoscalerRef: # HPA 引用（可選）
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
name: podinfo
service:
port: 9898
targetPort: 9898
gateways: # Istio 網(wǎng)關(guān)（可選）
- istio-system/public-gateway
hosts: # VirtualService 主機(jī)名 (optional)
- podinfo.k8s.local
trafficPolicy: # Istio 流量策略（可選）
tls:
# use ISTIO_MUTUAL when mTLS is enabled
mode: DISABLE
retries: # Istio 重試策略（可選）
attempts: 3
perTryTimeout: 1s
retryOn: "gateway-error,connect-failure,refused-stream"
analysis: # 金絲雀分析
interval: 1m # 金絲雀分析間隔時(shí)間（默認(rèn) 60s）
threshold: 5 # 金絲雀分析失敗閾值（默認(rèn) 5）
maxWeight: 50 # 金絲雀最大流量權(quán)重（默認(rèn) 50）
stepWeight: 10 # 金絲雀流量權(quán)重步長（默認(rèn) 10）
metrics:
- name: request-success-rate
# minimum req success rate (non 5xx responses)
# percentage (0-100)
thresholdRange:
min: 99
interval: 1m
- name: request-duration
# maximum req duration P99
# milliseconds
thresholdRange:
max: 500
interval: 30s
# testing (optional)
webhooks:
- name: acceptance-test
type: pre-rollout
url: http://flagger-loadtester.test/
timeout: 30s
metadata:
type: bash
cmd: "curl -sd 'test' http://podinfo-canary:9898/token | grep token"
- name: load-test
url: http://flagger-loadtester.test/
timeout: 5s
metadata:
# 使用 hey 工具對 podinfo-canary 進(jìn)行為期1分鐘的負(fù)載測試，每秒發(fā)送10個(gè)請求，且測試過程中會維持2個(gè)并發(fā)連接。
cmd: "hey -z 1m -q 10 -c 2 http://podinfo-canary.test:9898/"上面的配置文件中，我們定義了 podinfo 應(yīng)用的金絲雀發(fā)布策略，其中 targetRef 指定了要進(jìn)行金絲雀發(fā)布的 Deployment 對象，service 指定了金絲雀發(fā)布的服務(wù)，analysis 指定了金絲雀分析策略，這里我們指定了兩個(gè)內(nèi)置的指標(biāo)檢查：request-success-rate 和 request-duration，其中 request-success-rate 指定了 HTTP 請求成功率，request-duration 指定了請求持續(xù)時(shí)間。對于每個(gè)指標(biāo)，你可以使用 thresholdRange 和窗口大小或時(shí)間序列指定可接受的值范圍和時(shí)間間隔。內(nèi)置檢查適用于每個(gè)服務(wù)網(wǎng)格/Ingress 控制器，并通過 Prometheus 查詢實(shí)現(xiàn)。
在 service 中我們指定了 Istio 的 Gateway（istio-system/public-gateway）以及 VirtualService 要使用的主機(jī)名，首先我們可以為該應(yīng)用創(chuàng)建一個(gè) Gateway 對象：
# public-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: public-gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"另外我們在上面的對象中通過 webhooks 字段指定了金絲雀分析期間要執(zhí)行的測試，其中 acceptance-test 用于在金絲雀分析開始之前執(zhí)行，load-test 用于在金絲雀分析期間執(zhí)行。
金絲雀部署
接下來我們可以直接創(chuàng)建 Canary 對象了：
kubectl apply -f podinfo-canary.yaml當(dāng)創(chuàng)建了 Canary 對象后，F(xiàn)lagger 會自動創(chuàng)建一個(gè)名為 pod-info-primary 的 Deployment 以及兩個(gè)版本的 Service 對象：
$ kubectl get deploy -n test
NAME READY UP-TO-DATE AVAILABLE AGE
flagger-loadtester 1/1 1 1 42m
podinfo 0/0 0 0 46m
podinfo-primary 2/2 2 2 7m3s
$ kubectl get svc -ntest
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
flagger-loadtester ClusterIP 10.106.172.190 <none> 80/TCP 35m
podinfo-canary ClusterIP 10.101.184.213 <none> 9898/TCP 39s
podinfo-primary ClusterIP 10.110.105.36 <none> 9898/TCP 39s可以看到我們原本的 podinfo 應(yīng)用已經(jīng)從 podinfo 這個(gè) Deployment 遷移到了 podinfo-primary 這個(gè) Deployment 之上。
此外還有 Istio 相關(guān)的對象：
$ kubectl get vs -ntest
NAME GATEWAYS HOSTS AGE
podinfo ["istio-system/public-gateway"] ["podinfo.k8s.local","podinfo"] 91s
$ kubectl get dr -ntest
NAME HOST AGE
podinfo-canary podinfo-canary 95s
podinfo-primary podinfo-primary 95s我們可以查看下自動生成的 VirtualService 對象：
$ kubectl get vs -ntest podinfo -oyaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: podinfo
namespace: test
spec:
gateways:
- istio-system/public-gateway
hosts:
- podinfo.k8s.local
- podinfo
http:
- retries:
attempts: 3
perTryTimeout: 1s
retryOn: gateway-error,connect-failure,refused-stream
route:
- destination:
host: podinfo-primary
weight: 100
- destination:
host: podinfo-canary
weight: 0從上面的配置中我們可以看到當(dāng)前 podinfo 應(yīng)用的流量全部被路由到了 podinfo-primary 對象上，而 podinfo-canary 對象的流量權(quán)重為 0，當(dāng)然同樣可以查看 DestinationRule 對象：
$ kubectl get dr podinfo-primary -ntest -oyaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: podinfo-primary
namespace: test
spec:
host: podinfo-primary
trafficPolicy:
tls:
mode: DISABLE
$ kubectl get dr podinfo-canary -ntest -oyaml
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: podinfo-canary
namespace: test
spec:
host: podinfo-canary
trafficPolicy:
tls:
mode: DISABLE所以默認(rèn)情況下現(xiàn)在我們訪問到的就是 podinfo-primary 這個(gè) Deployment 對象，也就是目前的默認(rèn)版本。我們可以在瀏覽器中訪問 podinfo 來查看當(dāng)前的版本：
podinfo
自動金絲雀發(fā)布
我們可以看到現(xiàn)在的版本是 podinfo v6.0.0，接下來我們來升級應(yīng)用觸發(fā)金絲雀發(fā)布。要觸發(fā)金絲雀發(fā)布，可以由以下任何對象的更改來觸發(fā)：
- Deployment PodSpec（容器鏡像、命令、端口、環(huán)境變量、資源等）
- 作為卷掛載或映射到環(huán)境變量的 ConfigMaps
- 作為卷掛載或映射到環(huán)境變量的 Secrets
比如我們可以直接修改 Deployment 對象的鏡像版本來觸發(fā)自動化的金絲雀發(fā)布：
kubectl -n test set image deployment/podinfo podinfod=ghcr.io/stefanprodan/podinfo:6.0.1Flagger 檢測到 Deployment 更改后就會開始新的部署：
$ kubectl describe canaries podinfo -ntest
# ......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Synced 15m flagger podinfo-primary.test not ready: waiting for rollout to finish: observed deployment generation less than desired generation
Normal Synced 14m (x2 over 15m) flagger all the metrics providers are available!
Normal Synced 14m flagger Initialization done! podinfo.test
Normal Synced 56s flagger New revision detected! Scaling up podinfo.test需要注意在金絲雀分析期間對 Deployment 應(yīng)用新的更改，F(xiàn)lagger 將重新啟動分析。第一步是先會去擴(kuò)容 podinfo 應(yīng)用：
$ kubectl get pods -ntest
NAME READY STATUS RESTARTS AGE
flagger-loadtester-78dd9787d4-dq5fc 2/2 Running 0 67m
podinfo-5d5dbc4d84-f2mp6 2/2 Running 0 31s
podinfo-5d5dbc4d84-gd8ln 2/2 Running 0 31s
podinfo-primary-64f865cf4-bhr79 2/2 Running 0 3m31s
podinfo-primary-64f865cf4-tgsdj 2/2 Running 0 3m31s然后就會根據(jù)我們在 Canary 對象中定義的金絲雀分析策略來進(jìn)行分析，并一步步將金絲雀版本的權(quán)重提高。
Warning Synced 4m4s flagger podinfo-primary.test not ready: waiting for rollout to finish: observed deployment generation less than desired generation
Normal Synced 3m4s (x2 over 4m4s) flagger all the metrics providers are available!
Normal Synced 3m4s flagger Initialization done! podinfo.test
Normal Synced 64s flagger New revision detected! Scaling up podinfo.test
Normal Synced 4s flagger Starting canary analysis for podinfo.test
Normal Synced 4s flagger Pre-rollout check acceptance-test passed
Normal Synced 4s flagger Advance podinfo.test canary weight 10最后會自動將流量全部切換到金絲雀版本上。
金絲雀版本
整個(gè)過程就是通過控制 VirtualService 的權(quán)重來實(shí)現(xiàn)的金絲雀發(fā)布。
自動回滾
在金絲雀分析期間，我們可以生成 HTTP 500 錯(cuò)誤和高延遲來測試 Flagger 是否暫停發(fā)布。
比如我們觸發(fā)另一個(gè)金絲雀發(fā)布：
kubectl -n test set image deployment/podinfo podinfod=ghcr.io/stefanprodan/podinfo:6.0.2然后進(jìn)入 loadtester 容器：
kubectl -n test exec -it flagger-loadtester-xx-xx sh使用下面的命令來生成 HTTP 500 錯(cuò)誤：
watch curl http://podinfo-canary:9898/status/500也可以添加延遲：
watch curl http://podinfo-canary:9898/delay/1當(dāng)失敗檢查的次數(shù)達(dá)到金絲雀分析配置的閾值時(shí)，流量將路由回主節(jié)點(diǎn)，金絲雀將縮放為零，并將部署標(biāo)記為失敗。
Normal Synced 8m10s (x3 over 45m) flagger New revision detected! Scaling up podinfo.test
Normal Synced 7m10s (x2 over 44m) flagger Pre-rollout check acceptance-test passed
Normal Synced 7m10s (x2 over 44m) flagger Advance podinfo.test canary weight 10
Normal Synced 7m10s (x2 over 44m) flagger Starting canary analysis for podinfo.test
Warning Synced 6m10s flagger Halt podinfo.test advancement success rate 55.86% < 99%
Warning Synced 5m10s flagger Halt podinfo.test advancement success rate 97.61% < 99%
Warning Synced 4m10s flagger Halt podinfo.test advancement success rate 8.00% < 99%
Warning Synced 3m10s flagger Halt podinfo.test advancement success rate 98.13% < 99%
Warning Synced 2m10s flagger Halt podinfo.test advancement success rate 7.69% < 99%
Warning Synced 70s (x2 over 14m) flagger Canary failed! Scaling down podinfo.test
Warning Synced 70s flagger Rolling back podinfo.test failed checks threshold reached 5關(guān)于 Flagger 的更多使用請關(guān)注后續(xù)文章。
