激情久久久_欧美视频区_成人av免费_不卡视频一二三区_欧美精品在欧美一区二区少妇_欧美一区二区三区的

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

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

服務器之家 - 電腦之家 - 網絡技術 - 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

延伸 · 閱讀

精彩推薦
主站蜘蛛池模板： 免费黄色小视频网站 | 欧美日本色 | 免费小毛片 | 日本成年免费网站 | 久久网站热最新地址4 | 欧美成人精品一级 | 色婷婷综合久久久久中文 | 亚洲男人的天堂在线视频 | 欧美精品亚洲人成在线观看 | 九九看片| 日日做夜夜操 | 精品国产乱码一区二区三区四区 | 内地av在线 | 国产精品啪一品二区三区粉嫩 | 成人免费精品视频 | 91精品国产一区二区在线观看 | 国产成人免费精品 | 欧美成人免费在线视频 | 国产精品久久久久久久亚洲按摩 | 久久久中文 | 中国美女一级黄色片 | 毛片a级毛片免费播放100 | 久久精品中文字幕一区二区三区 | 黄色片免费在线 | 欧美成人免费小视频 | 久精品久久 | 黄色电影免费网址 | 少妇一级淫片高潮流水电影 | 三级国产网站 | jizzjizz中国少妇中文 | 国产精品视频2021 | 亚洲白嫩在线观看 | 精品国产91久久久久 | 日韩大片在线永久观看视频网站免费 | 日本aaa一级片| 999久久久免费视频 久久精品国产精品亚洲 | 一区视频 | asian gaysex | 羞羞的视频在线 | 久久久久夜色精品国产老牛91 | 日韩在线视频免费 |