Linkerd 金丝雀部署与 A/B 测试

网络 通信技术
本指南向您展示如何使用 Linkerd 和 Flagger 来自动化金丝雀部署与 A/B 测试。希望能够帮助到你!

[[413903]]

本指南向您展示如何使用 Linkerd 和 Flagger 来自动化金丝雀部署与 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.       - nameload-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。

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 来定位您的特定用户群。这对于需要会话关联的前端应用程序特别有用。

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.       - nameload-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 

 

责任编辑:姜华 来源: 黑客下午茶
相关推荐

2022-02-17 13:09:55

金丝雀部署服务集群测试

2022-11-30 08:00:00

金丝雀部署IT测试

2021-06-15 05:52:33

Linkerd canary网络技术

2021-07-13 06:35:11

Argo Rollou GitOpsKubernetes

2023-10-08 07:34:04

2024-04-01 13:04:01

停机部署滚动部署蓝绿部署

2021-10-08 20:12:22

微服务架构Service

2022-08-22 10:40:40

Kubernete部署分析运行

2021-02-28 07:52:24

蠕虫数据金丝雀

2021-06-03 05:48:58

GitOps 云原生Kubernetes

2024-01-18 08:24:08

2022-08-15 20:48:28

Chrome安卓网页

2013-11-01 11:00:10

2023-11-09 07:23:57

Istio路由分析

2023-02-20 10:13:00

灰度发布实现

2015-08-20 10:49:39

Windows 10版本

2021-10-14 18:21:52

架构IstioService

2023-09-05 07:24:33

Traefik加权轮询

2023-06-29 08:00:40

蓝绿部署策略Docker

2022-05-07 08:27:42

缓冲区溢出堆栈
点赞
收藏

51CTO技术栈公众号