Argo Rollouts BlueGreen 更新过程

1. 从稳定状态开始，activeService 和 PreviewService 都指向revision 1 的ReplicaSet。
2. 用户通过修改 Pod 模板（spec.template.spec）来发起更新。
3. 创建的ReplicaSet 的 revision 2 的大小为 0。
4. PreviewService被修改为指向revision 2的ReplicaSet 。 activeService 仍然指向 revision 1的ReplicaSet。
5. revision 2 的ReplicaSet将缩放为spec.replicas 或previewReplicaCount
6. 一旦revision 2的ReplicaSet  Pod 完全可用，prePromotionAnalysis就会开始执行
7. prePromotionAnalysis 成功后，如果 autoPromotionEnabled 为 false 或 autoPromotionSeconds 非零，蓝色/绿色会暂停。
8. rollout可以由用户手动恢复，也可以通过autoPromotionSeconds 自动恢复。
9. 如果使用了 PreviewReplicaCount 功能，则revision 2 的ReplicaSet将缩放为 spec.replicas。
10. 此次rollout通过更新 activeService 以指向它来“升级” revision 2 的ReplicaSet。此时，没有任何服务指向修订版 1
11. postPromotionAnalytics 分析开始执行
12. 一旦 postPromotionAnalysis 成功完成，更新就会成功，并且revision 2 的ReplicaSet将被标记为稳定。此次rollout被认为已得到fully-promoted。
13. 等待scaleDownDelaySeconds（默认30秒）后，revision 1的ReplicaSet被缩小。

Argo Rollouts BlueGreen 完整配置

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: example-rollout-canary
spec:
  # 运行的Pod实例数量，默认为1.
  # Defaults to 1.
  replicas: 5
  analysis:
    # 保留成功的数量
    # Defaults to 5.
    successfulRunHistoryLimit: 10
    # 保留失败的数量 
    # Stages for unsuccessful: "Error", "Failed", "Inconclusive"
    # Defaults to 5.
    unsuccessfulRunHistoryLimit: 10

  # 筛选Pod对象的标签选择器.
  selector:
    matchLabels:
      app: guestbook

  # WorkloadRef holds a references to a workload that provides Pod template 
  # (e.g. Deployment). If used, then do not use Rollout template property.
  workloadRef: 
    apiVersion: apps/v1
    kind: Deployment
    name: rollout-ref-deployment
    # 指定迁移到 Rollout 后是否缩减工作负载（Deployment）
    # "never": Deployment 不会减少
    # "onsuccess": 在 Rollout 变得健康后，Deployment会减少
    # "progressively": 随着 Rollout 的增加，Deployment 也随之减少 
    # If the Rollout fails the Deployment will be scaled back up.
    scaleDown: never|onsuccess|progressively

  # Template describes the pods that will be created. Same as deployment.
  # If used, then do not use Rollout workloadRef property. 
  template:
    spec:
      containers:
      - name: guestbook
        image: argoproj/rollouts-demo:blue

  # 无容器crash的情况下，新建的Pod被视为可用的最短时长，默认为0，即立即转为Ready
  minReadySeconds: 30

  # 更新历史中保留的ReplicaSet Revision数量.
  # Defaults to 10
  revisionHistoryLimit: 3

  # 是否置为暂停状态
  paused: true

  # 更新过程中，更新步骤的最大等待时长，默认为600秒；
  # Defaults to 600s
  progressDeadlineSeconds: 600

  # 未使用analysis或experiment而progressDeadlineSeconds超时的情况下，是否中止更新过程，默认为false；
  progressDeadlineAbort: false

  # 重启Pod的时刻，其值为UTC时间戳格式；
  restartAt: "2020-03-30T21:19:35Z"

  # 回滚窗口
  rollbackWindow:
    revisions: 3

  # 更新策略，支持canary和blueGreen两种；
  strategy:   

    # Blue-green update strategy
    blueGreen:

      # 当前活动状态的服务，也是即将更新的服务
      # Required.
      activeService: active-service

      # Promote操作之前要运行的Analysis，分析的结果决定了Rollout是进行流量切换，还是中止Rollout
      prePromotionAnalysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: guestbook-svc.default.svc.cluster.local

      # Promote操作之后要运行的Analysis ，若分析运行失败或出错，则Rollout进入中止状态并将流量切换回之前的稳定ReplicaSet
      postPromotionAnalysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: guestbook-svc.default.svc.cluster.local

      # 预览版的服务，也是要更新成的目标服务版本
      previewService: preview-service

      # preview版本RS应运行的Pod数，默认为100%
      previewReplicaCount: 1

      # 是否允许自动进行Promote，默认值为true.
      autoPromotionEnabled: false

      # 在指定的时长之后执行Promote
      autoPromotionSeconds: 30

      # 缩容前一个ReplicaSet规模的延迟时长，默认为30s；
      scaleDownDelaySeconds: 30

      # 在旧RS上启动缩容之前，可运行着的旧RS的数量；
      # down. Defaults to nil
      scaleDownDelayRevisionLimit: 2

      # 启用了trafficRouting时，因更新中止 而收缩Canary版本Pod数量之前的延迟时长，默认为30s；
      abortScaleDownDelaySeconds: 30

      # 期望的ReplicaSet和之前的ReplicaSet之间的反亲和关系
      antiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution: {}
        preferredDuringSchedulingIgnoredDuringExecution:
          weight: 1 # Between 1 - 100

      # 在当前活动的pod上添加元数据
      activeMetadata:
        labels:
          role: active

      # 更新期间添加到preview版本相关Pod上的元数据
      previewMetadata:
        labels:
          role: preview
      # 更新期间最多允许处于不可用状态的Pod数量或百分比,如果 MaxSurge 为 0，则该值不能为 0。
      maxUnavailable: 0

Argo Rollouts BlueGreen 示例

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-nginx-bluegreen-with-analysis
spec:
  replicas: 3
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: rollout-nginx-bluegreen
  template:
    metadata:
      labels:
        app: rollout-nginx-bluegreen
    spec:
      containers:
      - name: nginx
        image: nginx:1.24-alpine
        ports:
        - containerPort: 80
  strategy:
    blueGreen: 
      activeService: nginx
      previewService: nginx-preview
      prePromotionAnalysis: 
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: nginx-preview.argo-demo.svc.wgs.local
      postPromotionAnalysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: nginx.argo-demo.svc.wgs.local
      autoPromotionEnabled: true