1. 树叶云首页
  2. 技术资讯

Argo Rollouts 基于 Analysis 的渐进式发布

运维••技术资讯

Argo Rollouts 基于 Analysis 的渐进式发布

作者：佚名 2021-07-16 06:40:19

云计算 Rollout 是 Deployment 资源的直接替代品，它提供额外的 blueGreen 和 canary 更新策略，这些策略可以在更新期间创建 AnalysisRuns 和 Experiments，可以推进更新，或中止更新。

[[411608]]

前面我们介绍了使用手动的方式来控制 Argo Rollouts 进行应用交付，此外我们还可以利用 Argo Rollouts 提供的分析(Analysis)来执行自动交付。Argo Rollouts 提供了几种执行分析(Analysis)的方法来推动渐进式交付，首先需要了解几个 CRD 资源：

  • Rollout：Rollout 是 Deployment 资源的直接替代品，它提供额外的 blueGreen 和 canary 更新策略，这些策略可以在更新期间创建 AnalysisRuns 和 Experiments，可以推进更新，或中止更新。
  • AnalysisTemplate：AnalysisTemplate 是一个模板，它定义了如何执行金丝雀分析，例如它应该执行的指标、频率以及被视为成功或失败的值，AnalysisTemplate 可以用输入值进行参数化。
  • ClusterAnalysisTemplate：ClusterAnalysisTemplate 和 AnalysisTemplate 类似，但它是全局范围内的，它可以被整个集群的任何 Rollout 使用。
  • AnalysisRun：AnalysisRun 是 AnalysisTemplate 的实例化。AnalysisRun 就像 Job 一样，它们最终会完成，完成的运行被认为是成功的、失败的或不确定的，运行的结果分别影响 Rollout 的更新是否继续、中止或暂停。

后台分析

金丝雀正在执行其部署步骤时，分析可以在后台运行。

以下示例是每 10 分钟逐渐将 Canary 权重增加 20%，直到达到 100%。在后台，基于名为 success-rate 的 AnalysisTemplate 启动 AnalysisRun，success-rate 模板查询 Prometheus 服务器，以 5 分钟间隔/样本测量 HTTP 成功率，它没有结束时间，一直持续到停止或失败。如果测量到的指标小于 95%，并且有三个这样的测量值，则分析被视为失败。失败的分析会导致 Rollout 中止，将 Canary 权重设置回零，并且 Rollout 将被视为降级。否则，如果 rollout 完成其所有 Canary 步骤，则认为 rollout 是成功的，并且控制器将停止运行分析。

如下所示的 Rollout 资源对象：

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: Rollout 
  3. metadata: 
  4.   name: guestbook 
  5. spec: 
  6. ... 
  7.   strategy: 
  8.     canary: 
  9.       analysis: 
  10.         templates: 
  11.         - templateName: success-rate 
  12.         startingStep: 2 # 延迟开始分析，到第3步开始 
  13.         args: 
  14.         - name: service-name 
  15.           value: guestbook-svc.default.svc.cluster.local 
  16.       steps: 
  17.       - setWeight: 20 
  18.       - pause: {duration: 10m} 
  19.       - setWeight: 40 
  20.       - pause: {duration: 10m} 
  21.       - setWeight: 60 
  22.       - pause: {duration: 10m} 
  23.       - setWeight: 80 
  24.       - pause: {duration: 10m} 

上面我们引用了一个 success-rate 的模板：

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: AnalysisTemplate 
  3. metadata: 
  4.   name: success-rate 
  5. spec: 
  6.   args: 
  7.   - name: service-name 
  8.   metrics: 
  9.   - name: success-rate 
  10.     interval: 5m 
  11.     # NOTE: prometheus queries return results in the form of a vector. 
  12.     # So it is common to access the index 0 of the returned array to obtain the value 
  13.     successCondition: result[0] >= 0.95 
  14.     failureLimit: 3 
  15.     provider: 
  16.       prometheus: 
  17.         address: http://prometheus.example.com:9090 
  18.         query: | 
  19.           sum(irate( 
  20.             istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5m] 
  21.           )) / 
  22.           sum(irate( 
  23.             istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m] 
  24.           )) 

内联分析

分析也可以作为内嵌“分析”步骤来执行，当分析以 “内联 “方式进行时，在到达该步骤时启动 AnalysisRun，并在运行完成之前阻止其推进。分析运行的成功或失败决定了部署是继续进行下一步，还是完全中止部署。

如下所示的示例中我们将 Canary 权重设置为 20%，暂停 5 分钟，然后运行分析。如果分析成功，则继续发布，否则中止。

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: Rollout 
  3. metadata: 
  4.   name: guestbook 
  5. spec: 
  6. ... 
  7.   strategy: 
  8.     canary: 
  9.       steps: 
  10.       - setWeight: 20 
  11.       - pause: {duration: 5m} 
  12.       - analysis: 
  13.           templates: 
  14.           - templateName: success-rate 
  15.           args: 
  16.           - name: service-name 
  17.             value: guestbook-svc.default.svc.cluster.local 

上面的对象中我们将 analysis 作为一个步骤内联到了 Rollout 步骤中，当20%流量暂停5分钟后，开始执行 success-rate 这个分析模板。

这里 AnalysisTemplate 与上面的后台分析例子相同，但由于没有指定间隔时间，分析将执行一次测量就完成了。

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: AnalysisTemplate 
  3. metadata: 
  4.   name: success-rate 
  5. spec: 
  6.   args: 
  7.   - name: service-name 
  8.   - name: prometheus-port 
  9.     value: 9090 
  10.   metrics: 
  11.   - name: success-rate 
  12.     successCondition: result[0] >= 0.95 
  13.     provider: 
  14.       prometheus: 
  15.         address: "http://prometheus.example.com:{{args.prometheus-port}}" 
  16.         query: | 
  17.           sum(irate( 
  18.             istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5m] 
  19.           )) / 
  20.           sum(irate( 
  21.             istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m] 
  22.           )) 

此外我们可以通过指定 count 和 interval 字段，可以在一个较长的时间段内进行多次测量。

  1. metrics: 
  2.   - name: success-rate 
  3.     successCondition: result[0] >= 0.95 
  4.     interval: 60s 
  5.     count: 5 
  6.     provider: 
  7.       prometheus: 
  8.         address: http://prometheus.example.com:9090 
  9.         query: ... 

多个模板的分析

Rollout 在构建 AnalysisRun 时可以引用多个 AnalysisTemplate。这样我们就可以从多个 AnalysisTemplate 中来组成分析，如果引用了多个模板，那么控制器将把这些模板合并在一起，控制器会结合所有模板的指标和 args 字段。如下所示：

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: Rollout 
  3. metadata: 
  4.   name: guestbook 
  5. spec: 
  6. ... 
  7.   strategy: 
  8.     canary: 
  9.       analysis: 
  10.         templates: 
  11.         - templateName: success-rate 
  12.         - templateName: error-rate 
  13.         args: 
  14.         - name: service-name 
  15.           value: guestbook-svc.default.svc.cluster.local 
  16.  
  17. --- 
  18.  
  19. apiVersion: argoproj.io/v1alpha1 
  20. kind: AnalysisTemplate 
  21. metadata: 
  22.   name: success-rate 
  23. spec: 
  24.   args: 
  25.   - name: service-name 
  26.   metrics: 
  27.   - name: success-rate 
  28.     interval: 5m 
  29.     successCondition: result[0] >= 0.95 
  30.     failureLimit: 3 
  31.     provider: 
  32.       prometheus: 
  33.         address: http://prometheus.example.com:9090 
  34.         query: | 
  35.           sum(irate( 
  36.             istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code!~"5.*"}[5m] 
  37.           )) / 
  38.           sum(irate( 
  39.             istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m] 
  40.           )) 
  41. --- 
  42. apiVersion: argoproj.io/v1alpha1 
  43. kind: AnalysisTemplate 
  44. metadata: 
  45.   name: error-rate 
  46. spec: 
  47.   args: 
  48.   - name: service-name 
  49.   metrics: 
  50.   - name: error-rate 
  51.     interval: 5m 
  52.     successCondition: result[0] <= 0.95 
  53.     failureLimit: 3 
  54.     provider: 
  55.       prometheus: 
  56.         address: http://prometheus.example.com:9090 
  57.         query: | 
  58.           sum(irate( 
  59.             istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code=~"5.*"}[5m] 
  60.           )) / 
  61.           sum(irate( 
  62.             istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}"}[5m] 
  63.           )) 

当执行的分析的时候，控制器会将上面的 success-rate 和 error-rate 两个模板合并到一个 AnalysisRun 对象中去。

需要注意的是如果出现以下情况，控制器在合并模板时将出错：

  • 模板中的多个指标具有相同的名称
  • 两个同名的参数都有值

分析模板参数

AnalysisTemplates 可以声明一组参数，这些参数可以由 Rollouts 传递。然后，这些参数可以像在 metrics 配置中一样使用，并在 AnalysisRun 创建时被实例化，参数占位符被定义为 {{ args. }}，如下所示： 

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: AnalysisTemplate 
  3. metadata: 
  4.   name: args-example 
  5. spec: 
  6.   args: 
  7.   # required 
  8.   - name: service-name 
  9.   - name: stable-hash 
  10.   - name: latest-hash 
  11.   # optional 
  12.   - name: api-url 
  13.     value: http://example/measure 
  14.   # from secret 
  15.   - name: api-token 
  16.     valueFrom: 
  17.       secretKeyRef: 
  18.         name: token-secret 
  19.         key: apiToken 
  20.   metrics: 
  21.   - name: webmetric 
  22.     successCondition: result == 'true' 
  23.     provider: 
  24.       web: 
  25.         # placeholders are resolved when an AnalysisRun is created 
  26.         url: "{{ args.api-url }}?service={{ args.service-name }}" 
  27.         headers: 
  28.           - key: Authorization 
  29.             value: "Bearer {{ args.api-token }}" 
  30.         jsonPath: "{$.results.ok}" 

在创建 AnalysisRun 时，Rollout 中定义的参数与 AnalysisTemplate 的参数会合并，如下所示：

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: Rollout 
  3. metadata: 
  4.   name: guestbook 
  5. spec: 
  6. ... 
  7.   strategy: 
  8.     canary: 
  9.       analysis: 
  10.         templates: 
  11.         - templateName: args-example 
  12.         args: 
  13.         # required value 
  14.         - name: service-name 
  15.           value: guestbook-svc.default.svc.cluster.local 
  16.         # override default value 
  17.         - name: api-url 
  18.           value: http://other-api 
  19.         # pod template hash from the stable ReplicaSet 
  20.         - name: stable-hash 
  21.           valueFrom: 
  22.             podTemplateHashValue: Stable 
  23.         # pod template hash from the latest ReplicaSet 
  24.         - name: latest-hash 
  25.           valueFrom: 
  26.             podTemplateHashValue: Latest 

此外分析参数也支持 valueFrom，用于读取 meta 数据并将其作为参数传递给 AnalysisTemplate，如下例子是引用元数据中的 env 和 region 标签，并将它们传递给 AnalysisTemplate。

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: Rollout 
  3. metadata: 
  4.   name: guestbook 
  5.   labels: 
  6.     appType: demo-app 
  7.     buildType: nginx-app 
  8.     ... 
  9.     env: dev 
  10.     region: us-west-2 
  11. spec: 
  12. ... 
  13.   strategy: 
  14.     canary: 
  15.       analysis: 
  16.         templates: 
  17.         - templateName: args-example 
  18.         args: 
  19.         ... 
  20.         - name: env 
  21.           valueFrom: 
  22.             fieldRef: 
  23.               fieldPath: metadata.labels['env'] 
  24.         # region where this app is deployed 
  25.         - name: region 
  26.           valueFrom: 
  27.             fieldRef: 
  28.               fieldPath: metadata.labels['region'] 

蓝绿预发布分析

使用 BlueGreen 策略的 Rollout 可以在使用预发布将流量切换到新版本之前启动一个 AnalysisRun。分析运行的成功或失败决定 Rollout 是否切换流量，或完全中止 Rollout，如下所示：

  1. kind: Rollout 
  2. metadata: 
  3.   name: guestbook 
  4. spec: 
  5. ... 
  6.   strategy: 
  7.     blueGreen: 
  8.       activeService: active-svc 
  9.       previewService: preview-svc 
  10.       prePromotionAnalysis: 
  11.         templates: 
  12.         - templateName: smoke-tests 
  13.         args: 
  14.         - name: service-name 
  15.           value: preview-svc.default.svc.cluster.local 

上面我们的示例中一旦新的 ReplicaSet 完全可用，Rollout 会创建一个预发布的 AnalysisRun，Rollout 不会将流量切换到新版本，而是会等到分析运行成功完成。

注意：如果指定了 autoPromotionSeconds 字段，并且 Rollout 已经等待了 auto promotion seconds 的时间，Rollout 会标记 AnalysisRun 成功，并自动将流量切换到新版本。如果 AnalysisRun 在此之前完成，Rollout 将不会创建另一个 AnalysisRun，并等待 autoPromotionSeconds 的剩余时间。

蓝绿发布后分析

使用 BlueGreen 策略的 Rollout 还可以在流量切换到新版本后使用发布后分析。如果发布后分析失败或出错，Rollout 则进入中止状态，并将流量切换回之前的稳定 Replicaset，当后分析成功时，Rollout 被认为是完全发布状态，新的 ReplicaSet 将被标记为稳定，然后旧的 ReplicaSet 将根据 scaleDownDelaySeconds(默认为30秒)进行缩减。

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: Rollout 
  3. metadata: 
  4.   name: guestbook 
  5. spec: 
  6. ... 
  7.   strategy: 
  8.     blueGreen: 
  9.       activeService: active-svc 
  10.       previewService: preview-svc 
  11.       scaleDownDelaySeconds: 600 # 10 minutes 
  12.       postPromotionAnalysis: 
  13.         templates: 
  14.         - templateName: smoke-tests 
  15.         args: 
  16.         - name: service-name 
  17.           value: preview-svc.default.svc.cluster.local 

失败条件

failureCondition 可以用来配置分析运行失败，下面的例子是每隔5分钟持续轮询 Prometheus 服务器来获得错误总数，如果遇到10个或更多的错误，则认为分析运行失败。

  1. metrics: 
  2. - name: total-errors 
  3.   interval: 5m 
  4.   failureCondition: result[0] >= 10 
  5.   failureLimit: 3 
  6.   provider: 
  7.     prometheus: 
  8.       address: http://prometheus.example.com:9090 
  9.       query: | 
  10.         sum(irate( 
  11.           istio_requests_total{reporter="source",destination_service=~"{{args.service-name}}",response_code~"5.*"}[5m] 
  12.         )) 

无结果的运行

分析运行j结果也可以被认为是不确定的，这表明运行既不成功，也不失败。无结果的运行会导致发布在当前步骤上暂停。这时需要人工干预，以恢复运行，或中止运行。当一个指标没有定义成功或失败的条件时，分析运行可能成为无结果的一个例子。

  1. metrics: 
  2.  - name: my-query 
  3.    provider: 
  4.      prometheus: 
  5.        address: http://prometheus.example.com:9090 
  6.        query: ... 

此外当同时指定了成功和失败的条件，但测量值没有满足任何一个条件时，也可能发生不确定的分析运行。

  1. metrics: 
  2. - name: success-rate 
  3.   successCondition: result[0] >= 0.90 
  4.   failureCondition: result[0] < 0.50 
  5.   provider: 
  6.     prometheus: 
  7.       address: http://prometheus.example.com:9090 
  8.       query: ... 

不确定的分析运行的一个场景是使 Argo Rollouts 能够自动执行分析运行，并收集测量结果，但仍然允许我们来判断决定测量值是否可以接受，并决定继续或中止。

延迟分析运行

如果分析运行不需要立即开始(即给指标提供者时间来收集金丝雀版本的指标)，分析运行可以延迟特定的指标分析。每个指标可以被配置为有不同的延迟，除了特定指标的延迟之外，具有后台分析的发布可以延迟创建分析运行，直到达到某个步骤为止

如下所示延迟一个指定的分析指标:

  1. metrics: 
  2. - name: success-rate 
  3.   # Do not start this analysis until 5 minutes after the analysis run starts 
  4.   initialDelay: 5m 
  5.   successCondition: result[0] >= 0.90 
  6.   provider: 
  7.     prometheus: 
  8.       address: http://prometheus.example.com:9090 
  9.       query: ... 

延迟开始后台分析运行，直到步骤3(设定重量40%)。

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: Rollout 
  3. metadata: 
  4.   name: guestbook 
  5. spec: 
  6.   strategy: 
  7.     canary: 
  8.       analysis: 
  9.         templates: 
  10.         - templateName: success-rate 
  11.         startingStep: 2 
  12.       steps: 
  13.       - setWeight: 20 
  14.       - pause: {duration: 10m} 
  15.       - setWeight: 40 
  16.       - pause: {duration: 10m} 

引用 Secret

AnalysisTemplate 和 AnalysisRun 可以在 .spec.args 中引用 Secret 对象，这允许用户安全地将认证信息传递给指标提供方，如登录凭证或 API 令牌。

需要注意一个 AnalysisRun 只能引用它所运行的同一命名空间的 Secret。

如下所示的例子中，一个 AnalysisTemplate 引用了一个 API 令牌，并把它传递给一个Web 指标提供者。

  1. apiVersion: argoproj.io/v1alpha1 
  2. kind: AnalysisTemplate 
  3. spec: 
  4.   args: 
  5.   - name: api-token 
  6.     valueFrom: 
  7.       secretKeyRef: 
  8.         name: token-secret 
  9.         key: apiToken 
  10.   metrics: 
  11.   - name: webmetric 
  12.     provider: 
  13.       web: 
  14.         headers: 
  15.         - key: Authorization 
  16.           value: "Bearer {{ args.api-token }}" 

 【编辑推荐】

  1. 手把手教你使用Python轻松打造淘宝主图视频生成神器
  2. 为什么 NanoID 会取代 UUID
  3. 加密货币世界中的黑客预防与缓解
  4. 最近腾讯35岁员工薪资曝光，你这辈子还能追得上吗？

 

文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/305277.html<

赞 (0)
运维的头像运维
00
上一篇2025-05-26 03:02
下一篇 2025-05-26 03:03

相关推荐

  • 如何制作个人主题技术资讯

    个人主题怎么制作？

    制作个人主题是一个将个人风格、兴趣或专业领域转化为视觉化或结构化内容的过程，无论是用于个人博客、作品集、社交媒体账号还是品牌形象，核心都是围绕“个人特色”展开，以下从定位、内容规划、视觉设计、技术实现四个维度,详细拆解制作个人主题的完整流程，明确主题定位：找到个人特色的核心主题定位是所有工作的起点，需要先回答……

    运维的头像运维
    2025-11-20
    0
  • 如何管理社群营销技术资讯

    社群营销管理关键是什么？

    社群营销的核心在于通过建立有温度、有价值、有归属感的社群，实现用户留存、转化和品牌传播，其管理需贯穿“目标定位-内容运营-用户互动-数据驱动-风险控制”全流程,以下从五个维度展开详细说明：明确社群定位与目标社群管理的首要任务是精准定位，需明确社群的核心价值（如行业交流、产品使用指导、兴趣分享等）、目标用户画像……

    运维的头像运维
    2025-11-20
    0
  • 香港公司如何网站备案技术资讯

    香港公司网站备案需要什么材料？

    香港公司进行网站备案是一个涉及多部门协调、流程相对严谨的过程，尤其需兼顾中国内地与香港两地的监管要求，由于香港公司注册地与中国内地不同，其网站若主要服务内地用户或使用内地服务器，需根据服务器位置、网站内容性质等，选择对应的备案路径（如工信部ICP备案或公安备案），以下从备案主体资格、流程步骤、材料准备、注意事项……

    运维的头像运维
    2025-11-20
    0
  • 如何企业上云推广技术资讯

    如何企业上云推广

    企业上云已成为数字化转型的核心战略,但推广过程中需结合行业特性、企业痛点与市场需求，构建系统性、多维度的推广体系，以下从市场定位、策略设计、执行落地及效果优化四个维度，详细拆解企业上云推广的实践路径，精准定位：明确目标企业与核心价值企业上云并非“一刀切”的方案，需先锁定目标客户群体，提炼差异化价值主张，客户分层……

    运维的头像运维
    2025-11-20
    0
  • PS如何设计搜索框技术资讯

    PS设计搜索框的实用技巧有哪些？

    在PS中设计一个美观且功能性的搜索框需要结合创意构思、视觉设计和用户体验考量，以下从设计思路、制作步骤、细节优化及交互预览等方面详细说明，帮助打造符合需求的搜索框，设计前的规划明确使用场景：根据网站或APP的整体风格确定搜索框的调性，例如极简风适合细线条和纯色，科技感适合渐变和发光效果，电商类则可能需要突出搜索……

    运维的头像运维
    2025-11-20
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注