译者：谭恒亮，Github ID: Gallardot。开放源码工程项目发烧友，CNCF Chaos Mesh 工程项目 Maintainer，CNCF KubeVela、Apache APISIX、CNCF Flagger、CNCF Argo Rollouts 等工程项目 Contributor。现阶段在N61WI72Jq汽车供职虚拟化研发专家。
在日常生活的工程项目开发操作过程中时，他们经常会面临服务项目变更的挑战，为的是不负面影响使用者新体验，他们往往尽量需要避免出现服务项目不可用的信用风险。因此，稳步交货便不断涌现，其被接受为一类企业应用软件实践，因此是完善的稳步应用软件系统原则的自然演进。
然而，稳步布署仍然非常少见，这可能是由于管理的复杂程度以及担心布署失败会负面影响控制系统易用性。在整个稳步交货体系中，银腹正式发布或许是最为经典之作的两个情景。基于此，他们能很快辨认出“不健康”和“有难题”的服务项目，因此可以轻而易举地回滚到上两个版。
银腹正式发布也称“位图正式发布”。通常来说，在原有版可用的情况下，与此同时正式发布布署两个新版应用做为“银腹”，其目的是为的是试验新版的性能和表现，在保障整体控制系统稳定的前提下，尽快辨认出和及时调整。
银腹正式发布并非黑即白的正式发布方式，它能缓慢地将特定百分比的网络流量引导至少部分使用者。若校正没有难题，再推展到全部使用者，并逐步出局旧版，以减少生产环境导入新功能带来的信用风险。
责任编辑将如是说如何透过 Apache APISIX Ingress 和 Flagger 与此同时实现柔滑的银腹正式发布，从而提高正式发布工作效率，减少正式发布信用风险。
工程项目如是说
Apache APISIX Ingress
Apache APISIX Ingress 使用 Apache APISIX 做为数据面全权的 Kubernetes Ingress controller 与此同时实现，提供了阻抗平衡、动态上游、银腹正式发布、系统化路由器、开闭速度限制、服务项目降班、服务项目TNUMBERAP、身份认证、可探测性等余篇功能。现阶段已被包括 Zoom、百度云、驾考秘籍、夜空、欧洲开普勒参照控制系统等国内外公司和组织采用。
Flagger
Flagger 是两个 CNCF 云原生植物排序促进会工程项目，是 GitOps 辅助工具 Flux 系列的一部分。最近 CNCF 云原生植物排序促进会也宣布了 Flux 正式毕业，较好地表明了云原生植物技术当前的成功与荣光前景。做为一类渐进交货辅助工具，Flagger 可自动执行在 Kubernetes 上运转的插件的正式发布操作过程。它透过在来衡量分析指标和运转连续性试验的与此同时逐渐将网络流量转移到新版来减少在生产中导入新应用软件版的信用风险。
经过 Apache APISIX 和 Flux 两个社区的合作与努力，Flagger 在近期也正式发布了 v1.27.0 版，支持使用 Apache APISIX Ingress 和 Flagger 进行自动化的银腹正式发布。
下文将透过实践，一步步为大家展示下这个柔滑的银腹正式发布操作过程。
银腹正式发布准备环节
环境与组件准备
首先需要两个 v1.19 或更新版的 Kubernetes 集群，你可以透过 kind 进行安装。
然后使用 Helm V3 来安装 Apache APISIX 和 Apache APISIX Ingress Controller，具体操作如下所示：
helm repo add apisix https://charts.apiseven.comkubectl create ns apisixhelm upgrade -i apisix apisix/apisix –version=0.11.3 \–namespace apisix \–set apisix.podAnnotations.”prometheus\.io/scrape”=true \–set apisix.podAnnotations.”prometheus\.io/port”=9091 \–set apisix.podAnnotations.”prometheus\.io/path”=/apisix/prometheus/metrics \–set pluginAttrs.prometheus.export_addr.ip=0.0.0.0 \–set pluginAttrs.prometheus.export_addr.port=9091 \–set pluginAttrs.prometheus.export_uri=/apisix/prometheus/metrics \–set pluginAttrs.prometheus.metric_prefix=apisix_ \–set ingress-controller.enabled=true \–set ingress-controller.config.apisix.serviceNamespace=apisix完成后，在 apisix namespace 中安装 Flagger 和 Prometheus 附加组件。
helm repo add flagger https://flagger.apphelm upgrade -i flagger flagger/flagger \–namespace apisix \–set prometheus.install=true \–set meshProvider=apisix注意，如需使用自建 prometheus 或者 prometheus operator，可以自行搜索相关文章进行修改。
初始化应用
Flagger 可以作用于 Kubernetes 的 deployment 以及其他的 workload，也可以和 HPA 结合在一起工作。它将会创建一系列的对象（比如 Kubernetes deployments、ClusterIP services 和 ApisixRoute）。这些对象可以将应用暴露到集群外提供服务项目，并用于银腹正式发布操作过程的分析和正式发布。
首先使用 kubectl create ns test 命令来新建两个 namespace，这里我们将其命名为 test。然后透过 kubectl apply -k https://github.com/fluxcd/flagger//kustomize/podinfo?ref=main 命令，新建两个 deployment 和 HPA，这里使用 Flagger 官方示例程序。
接下来可透过 helm upgrade -i flagger-loadtester flagger/loadtester \
–namespace=test 指令来布署 Flagger 的阻抗试验服务项目，用于在银腹正式发布期间产生网络流量时，方便对其进行分析。
此时，创建 Apache APISIX 的ApisixRoute，Flagger 将会引用该资源，因此生成银腹版的 Apache APISIX Ingress 的ApisixRoute，具体可参照下方示例（示例中的app.example.com可以替换成你的实际域名）。
apiVersion: apisix.apache.org/v2kind: ApisixRoutemetadata:name: podinfonamespace: testspec:http:- backends:- serviceName: podinfoservicePort: 80match:hosts:- app.example.commethods:- GETpaths:name: methodplugins:- name: prometheusenable: trueconfig:disable: falseprefer_name: true将上方代码保存为 podinfo-apisixroute.yaml 文件因此提交到集群中。
kubectl apply -f ./podinfo-apisixroute.yaml
接下来可以创建 Flagger 的自定义资源 Canary，如下所示（示例中的 app.example.com可以替换成你的实际域名）。
apiVersion: flagger.app/v1beta1kind: Canarymetadata:name: podinfonamespace: testspec:provider: apisixtargetRef:apiVersion: apps/v1kind: Deploymentname: podinfo# 引用 apisix routerouteRef:apiVersion: apisix.apache.org/v2kind: ApisixRoutename: podinfoprogressDeadlineSeconds: 60service:port: 80targetPort: 9898analysis:# 调度间隔 (默认 60s)interval: 10s# 最大的metric检测失败次数，超过将会自动回滚threshold: 10# 网络流量路由器到canary应用的最大比率# (0-100)maxWeight: 50# 银腹分析渐进的步长# (0-100)stepWeight: 10# 透过Prometheus检查APISIX上的网络流量状况metrics:- name: request-success-rate# 最小的请求成功率 (非 5xx 响应)# (0-100)thresholdRange:min: 99interval: 1m- name: request-duration# P99 最大的请求延迟# 单位是毫秒thresholdRange:max: 500interval: 30swebhooks:# 自动产生网络流量以便进行银腹分析，根据实际业务情景修改- name: load-testurl: http://flagger-loadtester.test/timeout: 5stype: rolloutmetadata:cmd: |-hey -z 1m -q 10 -c 2 -h2 -host app.example.com http://apisix-gateway.apisix/api/info将上述代码保存为 podinfo-canary.yaml 文件，并提交到集群中。
kubectl apply -f ./podinfo-canary.yaml
稍等一下 Flagger 就会自动生成相关的资源。
# 主动提交的deployment.apps/podinfohorizontalpodautoscaler.autoscaling/podinfoapisixroute/podinfocanary.flagger.app/podinfo# 自动生成的deployment.apps/podinfo-primaryhorizontalpodautoscaler.autoscaling/podinfo-primaryservice/podinfoservice/podinfo-canaryservice/podinfo-primaryapisixroute/podinfo-podinfo-canary此时你透过域名 app.example.com 访问应用（示例中的app.example.com可以替换成你的实际域名），你将会看到当前版的应用细节。
具体功能实践
自动银腹正式发布
Flagger 与此同时实现了两个控制循环，在稳步测量 HTTP 请求成功率、请求平均稳步时间和 Pod 健康状况等关键性能指标的与此同时，逐渐将网络流量转移至银腹节点。根据对相关指标的分析，正式发布或中止银腹布署，并将分析结果正式发布到相关平台例如 Slack、MS Teams 或者 Prometheus Alert Manager 等。
具体可透过更新容器镜像版，来触发银腹正式发布。
kubectl -n test set image deployment/podinfo \podinfod=stefanprodan/podinfo:6.0.1当 Flagger 检测到 deployment 有新版变更时，就会开始试运转银腹分析正式发布。
kubectl -n test describe canary/podinfoStatus:Canary Weight: 0Conditions:Message: Canary analysis completed successfully, promotion finished.Reason: SucceededStatus: TrueType: PromotedFailed Checks: 1Iterations: 0Phase: SucceededEvents:Type Reason Age From MessageWarning Synced 2m59s flagger podinfo-primary.test not ready: waiting for rollout to finish: observed deployment generation less than desired generationWarning Synced 2m50s flagger podinfo-primary.test not ready: waiting for rollout to finish: 0 of 1 (readyThreshold 100%) updated replicas are availableNormal Synced 2m40s (x3 over 2m59s) flagger all the metrics providers are available!Normal Synced 2m39s flagger Initialization done! podinfo.testNormal Synced 2m20s flagger New revision detected! Scaling up podinfo.testWarning Synced 2m (x2 over 2m10s) flagger canary deployment podinfo.test not ready: waiting for rollout to finish: 0 of 1 (readyThreshold 100%) updated replicas are availableNormal Synced 110s flagger Starting canary analysis for podinfo.testNormal Synced 109s flagger Advance podinfo.test canary weight 10Warning Synced 100s flagger Halt advancement no values found for apisix metric request-success-rate probably podinfo.test is not receiving traffic: running query failed: no values foundNormal Synced 90s flagger Advance podinfo.test canary weight 20Normal Synced 80s flagger Advance podinfo.test canary weight 30Normal Synced 69s flagger Advance podinfo.test canary weight 40Normal Synced 59s flagger Advance podinfo.test canary weight 50Warning Synced 30s (x2 over 40s) flagger podinfo-primary.test not ready: waiting for rollout to finish: 1 old replicas are pending terminationNormal Synced 9s (x3 over 50s) flagger (combined from similar events): Promotion completed! Scaling down podinfo.test在新版银腹正式发布的操作过程中，你可以透过域名 app.example.com 访问应用（示例中的app.example.com可以替换成你的实际域名），这里将会出现不同版的响应切换。
透过查看由 Flagger 自动创建出来的 Apache APISIX 的ApisixRoute 资源 podinfo-podinfo-canary，会辨认出 service podinfo-primary 和 service podinfo-canary 的权重跟随着正式发布操作过程一起变化。
spec:http:- backends:- serviceName: podinfo-primaryservicePort: 80# Flagger自动调整weight: 80- serviceName: podinfo-canaryservicePort: 80# Flagger自动调整weight: 20当最终正式发布完成后，将会看到稳定的最新版。
注意：如若在银腹正式发布期间再次变更了 deployment，Flagger 将会重新进行银腹分析。你可以透过以下命令来观察到所有的银腹正式发布细节。
watch kubectl get canaries –all-namespacesNAMESPACE NAME STATUS WEIGHT LASTTRANSITIONTIMEtest podinfo-2 Progressing 10 2022-11-23T05:00:54Ztest podinfo Succeeded 0 2022-11-23T06:00:54Z自动回滚
在银腹正式发布分析期间，你可以透过生成 HTTP 500 错误请求，试验 Flagger 暂停银腹正式发布并回滚到旧版。
首先需要触发另两个银腹正式发布。
kubectl -n test set image deployment/podinfo \podinfod=stefanprodan/podinfo:6.0.2然后进入到 load tester 容器中。
kubectl -n test exec -it deploy/flagger-loadtester bash
接着去生成 HTTP 500 错误，并模拟服务项目延迟。
hey -z 1m -c 5 -q 5 -host app.example.com http://apisix-gateway.apisix/status/500watch -n 1 curl -H \”host: app.example.com\” http://apisix-gateway.apisix/delay/1当失败指标的检测次数达到银腹分析的阈值时，网络流量将被自动路由器到主节点。银腹节点被缩小到零，该银腹正式发布操作过程被标记为失败。
kubectl -n apisix logs deploy/flagger -f | jq .msg”New revision detected! Scaling up podinfo.test””canary deployment podinfo.test not ready: waiting for rollout to finish: 0 of 1 (readyThreshold 100%) updated replicas are available””Starting canary analysis for podinfo.test””Advance podinfo.test canary weight 10″”Halt podinfo.test advancement success rate 0.00% < 99%””Halt podinfo.test advancement success rate 26.76% < 99%””Halt podinfo.test advancement success rate 34.19% < 99%””Halt podinfo.test advancement success rate 37.32% < 99%””Halt podinfo.test advancement success rate 39.04% < 99%””Halt podinfo.test advancement success rate 40.13% < 99%””Halt podinfo.test advancement success rate 48.28% < 99%””Halt podinfo.test advancement success rate 50.35% < 99%””Halt podinfo.test advancement success rate 56.92% < 99%””Halt podinfo.test advancement success rate 67.70% < 99%””Rolling back podinfo.test failed checks threshold reached 10″”Canary failed! Scaling down podinfo.test”自定义指标银腹分析
银腹分析可以透过查询 Prometheus 的指标进行扩展，具体可根据实际业务情景进行调整。主要操作是需要创建两个指标模板，并提交到集群。
apiVersion: flagger.app/v1beta1kind: MetricTemplatemetadata:name: not-found-percentagenamespace: testspec:provider:type: prometheusaddress: http://flagger-prometheus.apisix:9090query: |sum(rate(apisix_http_status{route=~”{{ namespace }}_{{ route }}-{{ target }}-canary_.+”,code!~”4..”}[{{ interval }}]sum(rate(apisix_http_status{route=~”{{ namespace }}_{{ route }}-{{ target }}-canary_.+”}[{{ interval }}]) * 100修改银腹正式发布中的analysis，添加上面创建的指标模版。
analysis:metrics:- name: “404s percentage”templateRef:name: not-found-percentagethresholdRange:max: 5interval: 1m上述配置内容主要是透过检查 HTTP 404 请求的 QPS 是否高于总网络流量的 5% 来校正银腹。如果 HTTP 404 请求超过 5% 的阈值，那么银腹正式发布就失败了。
总结
当然，以上操作过程还可以透过更多的自定义指标检查、Webhook、手动审批和 Slack 或 MS Teams 通知等进行扩展。
透过 Apache APISIX 和 Flagger 的整合，与此同时实现了非常柔滑的银腹正式发布。在业务实践的操作过程中，提高了发布工作效率，减少了正式发布信用风险。后续两个社区也会透过更紧密的合作，去与此同时实现 Blue/Green Mirroring 和 A/B Testing 等更多的正式发布能力特性。
