Argo Rollouts 灰度发布

概述Argo 是 CNCF 旗下的一组以 Kubernetes 为中心的声明式自动化工具主要用于持续交付CD工作流编排和运维。Argo 生态的核心组件包括Argo CDKubernetes 的 GitOps 持续交付的工具。Argo Workflows容器化工作流引擎。Argo Events事件驱动自动化。Argo Rollouts高级发布控制器替代 kubernetes 原生的 Deployment。Argo CD 以 Git 仓库作为集群期望状态的唯一事实源持续对比并自动收敛集群实际状态与声明式配置之间的差异。原生支持 Helm、Kustomize 和 Jsonnet。Argo Workflows 是运行在 Kubernetes 之上的容器化工作流引擎用 CRD 描述 DAG 或步骤式流程每个步骤以独立 Pod 执行。本文主要介绍 Argo Rollouts。Argo RolloutsArgo Rollouts 是 Argo 家族中的一个 Kubernetes Controller用于替代或增强原生的 Deployment提供高级发布策略包括Canary灰度发布Blue-Green蓝绿发布与流量控制系统Ingress、Service Mesh、LB集成与监控系统Prometheus、Datadog集成支持自动化分析与回滚为什么需要 Argo Rollouts相较于 Argo RolloutsKubernetes 原生的 Deployment 的 RollingUpdate 有明显局促能力DeploymentArgo Rollouts百分比流量灰度❌只能按 pod 比例✅暂停 / 人工确认❌✅自动指标分析❌✅蓝绿发布❌✅自动回滚有限强要使用 Argo Rollouts必须先在安装其控制器。可以通过原生 YAML 安装也可以通过 OpenShift GitOps Operator 安装。通过 yaml 安装的命令如下kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml灰度发布Argo Rollouts 中的Rollout是一个 CRD(Custom Resource)用于取代 K8S 的Deployment。其配置文件与Deployment差不多主要差别如下# apiVersion 和 kind 是不同的 apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: ... # spec.strategy 不再配置 RollingUpdate spec: strategy: canary: dynamicStableScale: true stableService: test canaryService: test-canary steps: - setWeight: 20 - pause: {duration: 10m} - setWeight: 50 - pause: {} - setWeights: 100 trafficRouting: nginx: # 指定用户管理的 Ingress 名称 stableIngress: test-ingress ...Rollouts 并不直接控制流量而是通过集成第三方组件Nginx Ingress 等来实现如上面的trafficRouting配置。在流量切换时流量控制组件如 Nginx 的配置会发生改变如自动加上nginx.ingress.kubernetes.io/canary-weight: 20该Rollout采用的是 Canary 发布策略上一个版本的服务作为稳定服务stableService新版本的服务作为灰度服务canaryService。Rollout会创建一个新的 ReplicaSet 用于控制灰度 pod。由于灰度流量的步长设置为20/50/100因此第一步会切换 20% 的流量到灰度服务然后开始执行指标分析判断是否可以继续切换流量。如果一切正常在暂停时间结束后流量就会按照 20%-50%-100% 的比例逐步的切换到灰度服务上。需要注意的是暂停时间可以不指定而是设置- pause: {}。这意味着第二步切换 50% 的流量后下一步切换将无限暂停直至人工介入操作。此时通过命令kubectl argo rollouts get rollout my-app查看 rollout 的状态会显示如下结果Status: Paused Message: Rollout is paused at step X如果想继续切换执行晋升命令即可:kuubectl argo rollouts promote my-app指标分析的配置示例如下apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: success-rate spec: metrics: - name: error-rate interval: 1m successCondition: result 0.01 provider: prometheus: address: http://prometheus:9090 query: | sum(rate(http_requests_total{status~5..}[1m])) /sum(rate(http_requests_total[1m]))在Rollout中指定指标分析配置:steps: - setWeight: 20 - analysis: templates: - templateName: success-rate ...如果不指定AnalysisTemplate灰度发布仍然会执行但是否继续推进只取决于时间和人工操作不会基于任何业务或系统指标作为判断。当流量全部切换完成后会发生以下变化新版本的服务变成 stableService原来的 stable ReplicaSet 被缩容到 0canaryService 不再承载流量Ingress / Mesh 移除灰度规则仅保留稳定路由也就是说流量切换完成后新版本的服务即是稳定服务。而 canaryService 虽然还能看到但其实是不具备任何意义的只有在下次发布时才会作为下一次的灰度服务而产生意义。常用命令要通过命令行查看 Argo Rollouts 需要安装 argo-rollouts CLI:# macOS (Intel) curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-darwin-amd64 chmod x kubectl-argo-rollouts-darwin-amd64 sudo mv kubectl-argo-rollouts-darwin-amd64 /usr/local/bin/kubectl-argo-rollouts # macOS (Apple Silicon) curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-darwin-arm64 chmod x kubectl-argo-rollouts-darwin-arm64 sudo mv kubectl-argo-rollouts-darwin-arm64 /usr/local/bin/kubectl-argo-rollouts使用 argo rollouts 的基本格式为kubectl argo rollouts resource action [flags]常见资源rolloutexperimentanalysisrunanalysisTemplate常用命令如下# 查看 kubectl argo rollouts list kubectl argo rollouts get rollout my-rollout # 观察发布状态 kubectl argo rollouts get rollout my-rollout --watch # 手动推进到下一步 kubectl argo rollouts promote my-rollout # 跳过所有步骤 kubectl argo rollouts promote my-rollout --full # 发布终止 kubectl argo rollouts abort my-rollout # 回滚到上一个稳定版本 kubectl argo rollouts undo my-rollout # 查看历史版本 kubectl argo rollouts history my-rollout # 回滚到指定 revision kubectl argo rollouts undo my-rollout --to-revision3在查看 Rollout 时会显示 Rollout 的版本和对应的 ReplicaSet 和 Pod。正常会有 Canary 和 Stable 两个版本。如果是首次创建 Rollout那就只有一个 Stable 版本而没有 Canary 版本。下次发布时才会有 Canary 版本。流量路由Argo Rollouts 本身不做流量路由控制其流量控制功能是通过流量网关组件来实现的。按比例进行流量路由基本上是所有流量网关都支持的。如果想进一步按照特定的请求参数比如根据 header 头来进行路由Istio 和 Nginx Ingress 都是支持的。下面以 Ingress 为例来说明。假设现在所有请求头参数uid为test123的流量都需要打到灰度服务则需配置如下steps: - setWeight: 50 - pause: { } trafficRouting: nginx: stableIngress: test-ingress additionalIngressAnnotations: canary-by-header: uid canary-by-header-value: test123Argo Rollouts 会自动创建一个 Canary Ingress其注解内容为metadata: annotations: nginx.ingress.kubernetes.io/canary: true nginx.ingress.kubernetes.io/canary-by-header: uid nginx.ingress.kubernetes.io/canary-by-header-value: test123 nginx.ingress.kubernetes.io/canary-weight: 50这是可以直接在集群中看到的。注意这个 Ingress 无需手动创建而是由 Argo Rollouts 自动维护的。有了以上的 Canary Ingress 后流量路由效果是:所有带符合条件 Header 的请求100% - 灰度服务不符合条件的请求: 50% - 灰度服务Header 路由的优先级高于权重路由。注意header 参数名在 NGINX 中是大小写不敏感的但值是精确匹配的。Nginx Ingress 原生限制只能匹配一个 Header。灰度 HPA在灰度发布时为了让 HPA 和 Rollout 协同工作HPA 必须指向 Rollout 资源如下所示apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: xxx-hpa spec: scaleTargetRef: apiVersion: argoproj.io/v1alpha1 kind: Rollout name: my-rollout上文介绍过在灰度发布时 Argo Rollouts 会管理两个 ReplicaSet一个是稳定版一个是金丝雀版。Argo Rollouts 会根据 steps 中定义的权重设置为这两个 RS 计算 Pod 数量HPA 根据当前负载计算出总共需要的 Pod 数量假定为 10。如果金丝雀步骤处于setWeights: 20那么金丝雀版本的 RS 期望的 Pod 数量为 2。稳定版 Pod 数量为 8。如果想更细粒度的控制灰度 pod 数量可以在 Rollout 中设置每个步骤的 Canary 规模。如下所示spec: strategy: canary: ... steps: # 步骤1: 设置流量权重为10%到金丝雀服务 - setWeight: 10 # 步骤2: 设置金丝雀Pod数量比例为25% - setCanaryScale: weight: 25 - pause: {}第一步控制流量第二步控制 Canary 版本的 Pod 的规模总 Pod 数量的 25%。最佳实践是不要设置 CanaryScale让 HPA 自动根据流量权重来计算。如果流量路由不根据权重而是完全基于 Header 参数同时也不设置 CanaryScale则 Canary Pod 的计算就没有了依据会导致没有 Canary Pod。Deployment 到 Argo Rollouts 切换如果当前在工作环境中已经部署了 Deployment现在想要切换到 Argo Rollouts一定要注意流量的路由机制。因为从 Deployment 切换到 Rollouts 属于是第一次部署此时不存在灰度的概念Rollout 一旦部署就会生成稳定服务通过get rollout查看只有 stable 服务。Rollouts 部署后其管理的 pod 的标签会与原来 Deployment 管理的 pod 的标签不一样: 原 pod 标签为pod-template-hash: xxxxx, Rollouts 管理的 pod 标签为rollouts-pod-template-hash: xxxxx。Rollouts 管理的 service 的选择器中也包含该标签可以选中对应的 pod。如果 Rollouts 的stableService配置跟原 Deployment 管理的 service 一致就会导致流量经 Ingress 进来 service 后路由到 Rollouts 管理的 pod 中选择器选中。而由于 Rollouts 刚部署启动的 pod 数可能还很少此时线上巨大的流量瞬间涌入可能会导致服务崩溃。为了实现流量平稳切换需要让流量还可以继续进入原来的 pod 中。因此可以在 Rollouts 中配置一个新的服务比如canary: stableService: test-stable canaryService: test-canary这样部署后集群中就有三个服务了:test,test-stable,test-canary。其中 Rollouts 管理的服务即test-stable和test-canary可以选择新的 pod, 而test服务可以选中全部的 pod (新的 pod 只是增加了一个标签原标签还可以被匹配到)。在 rollout 中配置test-stable和test-canary之后如果test-stable没有配置在 ingress 中rollout 部署会失败提示 stable 服务未指定路由规则。因此可以在 ingress 中再加上与原 test 服务一样的路由规则以规避此问题。但是需要知道的是ingress 的规则最终落到 nginx 中是不支持相同host path的只有先创建的才生效。这里只是单纯为了避免 rollout 部署失败。当流量进入nginx 后被路由到test服务再平均分配到所有的 pod 中。然后逐渐扩容新的 pod 并缩减旧的 pod就可以平滑地将流量切换到新的 pod 中了。最后将 ingress 中的后端服务改成test-stable删掉原路由规则流量就会全部路由到新的 pod 中了。原来的test服务就没用了可以删除。以后第二次发布时就是灰度发布了遵循灰度发布的所有规范。