一区二区三区在线-一区二区三区亚洲视频-一区二区三区亚洲-一区二区三区午夜-一区二区三区四区在线视频-一区二区三区四区在线免费观看

電腦之家 - 專業計算機基礎知識與電腦技術學習網站
分類導航

路由器|交換機|網絡協議|網絡知識|

服務器之家 - 電腦之家 - 網絡技術 - Linkerd 金絲雀部署與 A/B 測試

Linkerd 金絲雀部署與 A/B 測試

2021-07-29 22:49黑客下午茶為少 網絡技術

本指南向您展示如何使用 Linkerd 和 Flagger 來自動化金絲雀部署與 A/B 測試。希望能夠幫助到你！

Linkerd 金絲雀部署與 A/B 測試

本指南向您展示如何使用 Linkerd 和 Flagger 來自動化金絲雀部署與 A/B 測試。

Linkerd 金絲雀部署與 A/B 測試

Flagger Linkerd Traffic Split(流量拆分)

前提條件

Flagger 需要 Kubernetes 集群 v1.16 或更新版本和 Linkerd 2.10 或更新版本。

安裝 Linkerd the Prometheus(Linkerd Viz 的一部分)：

  1. linkerd install | kubectl apply -f - 
  2. linkerd viz install | kubectl apply -f - 

在 linkerd 命名空間中安裝 Flagger：

  1. kubectl apply -k github.com/fluxcd/flagger//kustomize/linkerd 

引導程序

Flagger 采用 Kubernetes deployment 和可選的水平 Pod 自動伸縮 (HPA)，然后創建一系列對象(Kubernetes 部署、ClusterIP 服務和 SMI 流量拆分)。這些對象將應用程序暴露在網格內部并驅動 Canary 分析和推廣。

創建一個 test 命名空間并啟用 Linkerd 代理注入：

  1. kubectl create ns test 
  2. kubectl annotate namespace test linkerd.io/inject=enabled 

安裝負載測試服務以在金絲雀分析期間生成流量：

  1. kubectl apply -k https://github.com/fluxcd/flagger//kustomize/tester?ref=main 

創建部署和水平 pod autoscaler：

  1. kubectl apply -k https://github.com/fluxcd/flagger//kustomize/podinfo?ref=main 

為 podinfo 部署創建一個 Canary 自定義資源：

  1. apiVersion: flagger.app/v1beta1 
  2. kind: Canary 
  3. metadata: 
  4.   name: podinfo 
  5.   namespace: test 
  6. spec: 
  7.   # deployment reference 
  8.   targetRef: 
  9.     apiVersion: apps/v1 
  10.     kind: Deployment 
  11.     name: podinfo 
  12.   # HPA reference (optional) 
  13.   autoscalerRef: 
  14.     apiVersion: autoscaling/v2beta2 
  15.     kind: HorizontalPodAutoscaler 
  16.     name: podinfo 
  17.   # the maximum time in seconds for the canary deployment 
  18.   # to make progress before it is rollback (default 600s) 
  19.   progressDeadlineSeconds: 60 
  20.   service: 
  21.     # ClusterIP port number 
  22.     port: 9898 
  23.     # container port number or name (optional) 
  24.     targetPort: 9898 
  25.   analysis: 
  26.     # schedule interval (default 60s) 
  27.     interval: 30s 
  28.     # max number of failed metric checks before rollback 
  29.     threshold: 5 
  30.     # max traffic percentage routed to canary 
  31.     # percentage (0-100) 
  32.     maxWeight: 50 
  33.     # canary increment step 
  34.     # percentage (0-100) 
  35.     stepWeight: 5 
  36.     # Linkerd Prometheus checks 
  37.     metrics: 
  38.     - name: request-success-rate 
  39.       # minimum req success rate (non 5xx responses) 
  40.       # percentage (0-100) 
  41.       thresholdRange: 
  42.         min: 99 
  43.       interval: 1m 
  44.     - name: request-duration 
  45.       # maximum req duration P99 
  46.       # milliseconds 
  47.       thresholdRange: 
  48.         max: 500 
  49.       interval: 30s 
  50.     # testing (optional) 
  51.     webhooks: 
  52.       - name: acceptance-test 
  53.         type: pre-rollout 
  54.         url: http://flagger-loadtester.test/ 
  55.         timeout: 30s 
  56.         metadata: 
  57.           type: bash 
  58.           cmd: "curl -sd 'test' http://podinfo-canary.test:9898/token | grep token" 
  59.       - name: load-test 
  60.         type: rollout 
  61.         url: http://flagger-loadtester.test/ 
  62.         metadata: 
  63.           cmd: "hey -z 2m -q 10 -c 2 http://podinfo-canary.test:9898/" 

將上述資源另存為 podinfo-canary.yaml 然后應用：

  1. kubectl apply -f ./podinfo-canary.yaml 

當 Canary 分析開始時，Flagger 將在將流量路由到 Canary 之前調用 pre-rollout webhooks。金絲雀分析將運行五分鐘，同時每半分鐘驗證一次 HTTP 指標和 rollout(推出) hooks。

幾秒鐘后，Flager 將創建 canary 對象：

  1. # applied 
  2. deployment.apps/podinfo 
  3. horizontalpodautoscaler.autoscaling/podinfo 
  4. ingresses.extensions/podinfo 
  5. canary.flagger.app/podinfo 
  6.  
  7. # generated 
  8. deployment.apps/podinfo-primary 
  9. horizontalpodautoscaler.autoscaling/podinfo-primary 
  10. service/podinfo 
  11. service/podinfo-canary 
  12. service/podinfo-primary 
  13. trafficsplits.split.smi-spec.io/podinfo 

在 boostrap 之后，podinfo 部署將被縮放到零， 并且到 podinfo.test 的流量將被路由到主 pod。在 Canary 分析過程中，可以使用 podinfo-canary.test 地址直接定位 Canary Pod。

自動金絲雀推進

Flagger 實施了一個控制循環，在測量 HTTP 請求成功率、請求平均持續時間和 Pod 健康狀況等關鍵性能指標的同時，逐漸將流量轉移到金絲雀。根據對 KPI 的分析，提升或中止 Canary，并將分析結果發布到 Slack。

Linkerd 金絲雀部署與 A/B 測試

Flagger 金絲雀階段

通過更新容器鏡像觸發金絲雀部署：

  1. kubectl -n test set image deployment/podinfo \ 
  2. podinfod=stefanprodan/podinfo:3.1.1 

Flagger 檢測到部署修訂已更改并開始新的部署：

  1. kubectl -n test describe canary/podinfo 
  2.  
  3. Status: 
  4.   Canary Weight:         0 
  5.   Failed Checks:         0 
  6.   Phase:                 Succeeded 
  7. Events: 
  8.  New revision detected! Scaling up podinfo.test 
  9.  Waiting for podinfo.test rollout to finish: 0 of 1 updated replicas are available 
  10.  Pre-rollout check acceptance-test passed 
  11.  Advance podinfo.test canary weight 5 
  12.  Advance podinfo.test canary weight 10 
  13.  Advance podinfo.test canary weight 15 
  14.  Advance podinfo.test canary weight 20 
  15.  Advance podinfo.test canary weight 25 
  16.  Waiting for podinfo.test rollout to finish: 1 of 2 updated replicas are available 
  17.  Advance podinfo.test canary weight 30 
  18.  Advance podinfo.test canary weight 35 
  19.  Advance podinfo.test canary weight 40 
  20.  Advance podinfo.test canary weight 45 
  21.  Advance podinfo.test canary weight 50 
  22.  Copying podinfo.test template spec to podinfo-primary.test 
  23.  Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available 
  24.  Promotion completed! Scaling down podinfo.test 

請注意，如果您在 Canary 分析期間對部署應用新更改，Flagger 將重新開始分析。

金絲雀部署由以下任何對象的更改觸發：

  • Deployment PodSpec(容器鏡像container image、命令command、端口ports、環境env、資源resources等)
  • ConfigMaps 作為卷掛載或映射到環境變量
  • Secrets 作為卷掛載或映射到環境變量

您可以通過以下方式監控所有金絲雀：

  1. watch kubectl get canaries --all-namespaces 
  2.  
  3. NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME 
  4. test        podinfo   Progressing   15       2019-06-30T14:05:07Z 
  5. prod        frontend  Succeeded     0        2019-06-30T16:15:07Z 
  6. prod        backend   Failed        0        2019-06-30T17:05:07Z 

自動回滾

在金絲雀分析期間，您可以生成 HTTP 500 錯誤和高延遲來測試 Flagger 是否暫停并回滾有故障的版本。

觸發另一個金絲雀部署：

  1. kubectl -n test set image deployment/podinfo \ 
  2. podinfod=stefanprodan/podinfo:3.1.2 

使用以下命令執行負載測試器 pod：

  1. kubectl -n test exec -it flagger-loadtester-xx-xx sh 

生成 HTTP 500 錯誤：

  1. watch -n 1 curl http://podinfo-canary.test:9898/status/500 

生成延遲：

  1. watch -n 1 curl http://podinfo-canary.test:9898/delay/1 

當失敗的檢查次數達到金絲雀分析閾值時，流量將路由回主服務器，金絲雀縮放為零，并將推出標記為失敗。

  1. kubectl -n test describe canary/podinfo 
  2.  
  3. Status: 
  4.   Canary Weight:         0 
  5.   Failed Checks:         10 
  6.   Phase:                 Failed 
  7. Events: 
  8.  Starting canary analysis for podinfo.test 
  9.  Pre-rollout check acceptance-test passed 
  10.  Advance podinfo.test canary weight 5 
  11.  Advance podinfo.test canary weight 10 
  12.  Advance podinfo.test canary weight 15 
  13.  Halt podinfo.test advancement success rate 69.17% < 99% 
  14.  Halt podinfo.test advancement success rate 61.39% < 99% 
  15.  Halt podinfo.test advancement success rate 55.06% < 99% 
  16.  Halt podinfo.test advancement request duration 1.20s > 0.5s 
  17.  Halt podinfo.test advancement request duration 1.45s > 0.5s 
  18.  Rolling back podinfo.test failed checks threshold reached 5 
  19.  Canary failed! Scaling down podinfo.test 

自定義指標

Canary analysis 可以通過 Prometheus 查詢進行擴展。

讓我們定義一個未找到錯誤的檢查。編輯 canary analysis 并添加以下指標：

  1. analysis: 
  2.   metrics: 
  3.   - name: "404s percentage" 
  4.     threshold: 3 
  5.     query: | 
  6.       100 - sum( 
  7.           rate( 
  8.               response_total{ 
  9.                   namespace="test", 
  10.                   deployment="podinfo", 
  11.                   status_code!="404", 
  12.                   direction="inbound" 
  13.               }[1m] 
  14.           ) 
  15.       ) 
  16.       / 
  17.       sum( 
  18.           rate( 
  19.               response_total{ 
  20.                   namespace="test", 
  21.                   deployment="podinfo", 
  22.                   direction="inbound" 
  23.               }[1m] 
  24.           ) 
  25.       ) 
  26.       * 100 

上述配置通過檢查 HTTP 404 req/sec 百分比是否低于總流量的 3% 來驗證金絲雀版本。如果 404s 率達到 3% 閾值，則分析將中止，金絲雀被標記為失敗。

通過更新容器鏡像觸發金絲雀部署：

  1. kubectl -n test set image deployment/podinfo \ 
  2. podinfod=stefanprodan/podinfo:3.1.3 

生成 404：

  1. watch -n 1 curl http://podinfo-canary:9898/status/404 

監視 Flagger 日志：

  1. kubectl -n linkerd logs deployment/flagger -f | jq .msg 
  2.  
  3. Starting canary deployment for podinfo.test 
  4. Pre-rollout check acceptance-test passed 
  5. Advance podinfo.test canary weight 5 
  6. Halt podinfo.test advancement 404s percentage 6.20 > 3 
  7. Halt podinfo.test advancement 404s percentage 6.45 > 3 
  8. Halt podinfo.test advancement 404s percentage 7.22 > 3 
  9. Halt podinfo.test advancement 404s percentage 6.50 > 3 
  10. Halt podinfo.test advancement 404s percentage 6.34 > 3 
  11. Rolling back podinfo.test failed checks threshold reached 5 
  12. Canary failed! Scaling down podinfo.test 

如果您配置了 Slack，Flager 將發送一條通知，說明金絲雀失敗的原因。

Linkerd Ingress

有兩個入口控制器與 Flagger 和 Linkerd 兼容：NGINX 和 Gloo。

安裝 NGINX：

  1. helm upgrade -i nginx-ingress stable/nginx-ingress \ 
  2. --namespace ingress-nginx 

為 podinfo 創建一個 ingress 定義，將傳入標頭重寫為內部服務名稱(Linkerd 需要)：

  1. apiVersion: extensions/v1beta1 
  2. kind: Ingress 
  3. metadata: 
  4.   name: podinfo 
  5.   namespace: test 
  6.   labels: 
  7.     app: podinfo 
  8.   annotations: 
  9.     kubernetes.io/ingress.class: "nginx" 
  10.     nginx.ingress.kubernetes.io/configuration-snippet: | 
  11.       proxy_set_header l5d-dst-override $service_name.$namespace.svc.cluster.local:9898; 
  12.       proxy_hide_header l5d-remote-ip; 
  13.       proxy_hide_header l5d-server-id; 
  14. spec: 
  15.   rules: 
  16.     - host: app.example.com 
  17.       http: 
  18.         paths: 
  19.           - backend: 
  20.               serviceName: podinfo 
  21.               servicePort: 9898 

使用 ingress controller 時，Linkerd 流量拆分不適用于傳入流量，因為 NGINX 在網格之外運行。為了對前端應用程序運行金絲雀分析，Flagger 創建了一個 shadow ingress 并設置了 NGINX 特定的注釋(annotations)。

A/B 測試

除了加權路由，Flagger 還可以配置為根據 HTTP 匹配條件將流量路由到金絲雀。在 A/B 測試場景中，您將使用 HTTP headers 或 cookies 來定位您的特定用戶群。這對于需要會話關聯的前端應用程序特別有用。

Linkerd 金絲雀部署與 A/B 測試

Flagger Linkerd Ingress

編輯 podinfo 金絲雀分析，將提供者設置為 nginx，添加 ingress 引用，移除 max/step 權重并添加匹配條件和 iterations：

  1. apiVersion: flagger.app/v1beta1 
  2. kind: Canary 
  3. metadata: 
  4.   name: podinfo 
  5.   namespace: test 
  6. spec: 
  7.   # ingress reference 
  8.   provider: nginx 
  9.   ingressRef: 
  10.     apiVersion: extensions/v1beta1 
  11.     kind: Ingress 
  12.     name: podinfo 
  13.   targetRef: 
  14.     apiVersion: apps/v1 
  15.     kind: Deployment 
  16.     name: podinfo 
  17.   autoscalerRef: 
  18.     apiVersion: autoscaling/v2beta2 
  19.     kind: HorizontalPodAutoscaler 
  20.     name: podinfo 
  21.   service: 
  22.     # container port 
  23.     port: 9898 
  24.   analysis: 
  25.     interval: 1m 
  26.     threshold: 10 
  27.     iterations: 10 
  28.     match: 
  29.       # curl -H 'X-Canary: always' http://app.example.com 
  30.       - headers: 
  31.           x-canary: 
  32.             exact: "always" 
  33.       # curl -b 'canary=always' http://app.example.com 
  34.       - headers: 
  35.           cookie: 
  36.             exact: "canary" 
  37.     # Linkerd Prometheus checks 
  38.     metrics: 
  39.     - name: request-success-rate 
  40.       thresholdRange: 
  41.         min: 99 
  42.       interval: 1m 
  43.     - name: request-duration 
  44.       thresholdRange: 
  45.         max: 500 
  46.       interval: 30s 
  47.     webhooks: 
  48.       - name: acceptance-test 
  49.         type: pre-rollout 
  50.         url: http://flagger-loadtester.test/ 
  51.         timeout: 30s 
  52.         metadata: 
  53.           type: bash 
  54.           cmd: "curl -sd 'test' http://podinfo-canary:9898/token | grep token" 
  55.       - name: load-test 
  56.         type: rollout 
  57.         url: http://flagger-loadtester.test/ 
  58.         metadata: 
  59.           cmd: "hey -z 2m -q 10 -c 2 -H 'Cookie: canary=always' http://app.example.com" 

上述配置將運行 10 分鐘的分析，目標用戶是：canary cookie 設置為 always 或使用 X-Canary: always header 調用服務。

請注意，負載測試現在針對外部地址并使用 canary cookie。

通過更新容器鏡像觸發金絲雀部署：

  1. kubectl -n test set image deployment/podinfo \ 
  2. podinfod=stefanprodan/podinfo:3.1.4 

Flagger 檢測到部署修訂已更改并開始 A/B 測試：

  1. kubectl -n test describe canary/podinfo 
  2.  
  3. Events: 
  4.  Starting canary deployment for podinfo.test 
  5.  Pre-rollout check acceptance-test passed 
  6.  Advance podinfo.test canary iteration 1/10 
  7.  Advance podinfo.test canary iteration 2/10 
  8.  Advance podinfo.test canary iteration 3/10 
  9.  Advance podinfo.test canary iteration 4/10 
  10.  Advance podinfo.test canary iteration 5/10 
  11.  Advance podinfo.test canary iteration 6/10 
  12.  Advance podinfo.test canary iteration 7/10 
  13.  Advance podinfo.test canary iteration 8/10 
  14.  Advance podinfo.test canary iteration 9/10 
  15.  Advance podinfo.test canary iteration 10/10 
  16.  Copying podinfo.test template spec to podinfo-primary.test 
  17.  Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available 
  18.  Promotion completed! Scaling down podinfo.test 

原文鏈接：https://mp.weixin.qq.com/s/8ThwH9DvFAnc-trOSf_nNQ

延伸 · 閱讀

精彩推薦
主站蜘蛛池模板： 国产精品国产国产aⅴ | 四虎tv在线观看884aa | re99热 | 陈峰姚瑶全集小说无删节 | 国产视频福利 | 婷婷婷色 | 国产肥老上视频 | 深夜在线网站 | α片免费| 全色黄大色黄大片爽一次 | 青青热久麻豆精品视频在线观看 | 日本一区二区视频免费播放 | 国产综合久久久久 | 亚洲人成影院午夜网站 | 视频一区在线观看 | 嫩草精品 | 放荡护士玩3p口述 | 欧亚尺码专线欧洲s码wmy | 美女翘臀内疯狂进出 | 欧美成人aa久久狼窝动画 | 亚洲区精品 | 姐姐不～不可以动漫在线观看 | 免费91麻豆精品国产自产在线观看 | 成人操 | 日本色女 | 久久精品观看影院2828 | 男女激情视频1000辣妞范 | 欧美第一视频 | 兽操人 | 日本高清在线看 | 国产精品中文 | 欧美╳bbbb | 三级理论在线观看 | 小妇人电影免费完整观看2021 | 波多野结衣作品在线观看 | 糖心hd在线观看 | 波多野结衣之双方调教在线观看 | 性美国人xxxxx18 | 国产成人91高清精品免费 | 欧美色图亚洲天堂 | 欧美专区亚洲 |