原生 Kubernetes Deployment 支持滚动更新（RollingUpdate） 策略，该策略在更新期间提供一组基本的安全保证（就绪探测）。但是，滚动更新策略面临许多限制：

• 对滚动更新速度的掌控不足
• 无法精确控制流量分发到新版本
• 就绪探针验证不够灵活和深入
• 无法查询外部指标以验证更新
• 无法自动中止和回滚更新

由于这些原因，在大规模大批量生产环境中，滚动更新通常存在较大风险，需要引入控制能力更强的渐进式交付能力。

渐进式交付

渐进性交付最早起源于大型、复杂的工业化项目，它试图将复杂的项目进行分阶段拆解，通过持续进行小型闭环迭代降低交付成本和时间。随着云原生架构不断发展，渐进性交付被广泛应用在互联网业务应用中，开发者通过GitOps、CI/CD方式集成渐进式交付框架，让新功能交付以流水线的方式分批执行，利用A/B 测试、金丝雀发布等技术精细化控制每一批次的流量策略，充分保障应用发布的稳定性。

渐进式交付是在受控和渐进中发布产品更新的过程方式，从而降低释放的风险，通常将自动化和检测分析相结合以实现自动升级或回滚。

渐进式交付通常被描述为持续交付的演变，通过限制将新版本暴露给一部分用户，观察和分析正确的行为，然后逐步增加对越来越广的受众的曝光率，同时持续不断验证正确性。

这里的核心理念可以总结为部署过程控制、验证分析、流量调度控制能力，通过增强这三种能力来实现可控的正确的交付。

在落地层面，渐进式交付通常体现为金丝雀发布（也称灰度发布）。

常见的部署策略

回顾常见的部署策略，有助于理解不同交付过程的区别和云原生渐进式交付的方案。

1. 重建（Recreate）：重新创建部署会在启动新版本之前删除应用程序的旧版本。因此，这可确保应用程序的两个版本永远不会同时运行，但在部署期间会出现停机。
2. 滚动更新（RollingUpdate）：慢慢地用新版本替换旧版本。随着新版本的出现，旧版本会按比例缩减，以保持应用程序的总数，这是 Deployment 对象的默认策略。但滚动更新有一个问题，在开始滚动更新后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动更新期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。
3. 蓝绿部署（Blue-Green）：蓝绿部署同时部署了应用程序的新版本和旧版本，新版本上线过程中，不会修改老版本的任何内容，在部署期间老版本状态不受影响，应用始终在线。这允许在将实时流量切换到新版本之前针对新版本运行测试，并且只要老版本的资源不被删除，可以在任何时间迅速切回到老版本。但蓝绿部署要求在升级过程中，同时运行两套程序，对基础资源的要求就是日常所需的二倍。
4. 金丝雀部署（Canary）：金丝雀部署将一部分用户公开给新版本的应用程序，同时将其余流量提供给旧版本。一旦验证新版本正确，新版本就可以逐渐替换旧版本。通常金丝雀发布也称为灰度发布。

Kubernetes原生已经支持重建和滚动更新，接下来我们介绍三种与Kubernetes适配的支持金丝雀部署策略的云原生渐进式发布方案，都支持Ingress、GatewayAPI等流量控制能力以及多样的验证分析能力，支持完整的容器应用的渐进式发布能力，但在实现原理和细节上还是有一定区分。

Kruise Rollouts

Kruise Rollouts是一个 Bypass(旁路) 组件，提供高级渐进式交付功能，帮助实现应用程序的平稳和受控的更新部署，支持金丝雀、多批次和A/B测试交付模式，同时兼容 Gateway API 和各种 Ingress 实现，容易集成到现有基础设施中。

支持Deployment、CloneSet、StatefulSet、Advanced StatefulSet、Advanced DaemonSet 的多批次更新策略，也支持 Deployment 的金丝雀(Canary)更新策略。

金丝雀发布策略

CRD配置

apiVersion: rollouts.kruise.io/v1beta1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: workload-demo
  strategy:
    canary:
      enableExtraWorkloadForCanary: true
      steps:
      - traffic: 20%
      trafficRoutings:
      - service: service-demo
        ingress:
          classType: nginx
          name: ingress-demo

从上面的配置可以看到，CRD将原生Deployment包在了内部，符合Kubernetes控制器模式，用新的Rollout控制器增强Deployment的能力，内部还是调度Deployment控制实现对ReplicaSet的控制，然后通过ReplicaSet控制Pod，即：

Rollout->Deployment->ReplicaSet->Pod

相当于起了多个Deployment来实现版本控制和更新，因此，也称为Bypass（旁路）模式。

具体执行过程如下：

当workload-demo应用更新时：

• workload-demo工作负载将被暂停，不会更新任何Pod；
• 将创建一个新的金丝雀Deployment，其副本数为workload-demo的“20%”（总计将有120%的Pods）；
• 20%的流量将被引导到新的金丝雀Deployment的Pods。

当认为金丝雀验证已经通过并确认进行下一步时：

• workload-demo工作负载将使用本机滚动更新策略进行升级；
• 流量将恢复到原始的负载均衡策略；
• 金丝雀Deployment和Pods将被删除。

多批次发布策略（金丝雀变体）

apiVersion: rollouts.kruise.io/v1beta1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: workload-demo
  strategy:
    canary:
      enableExtraWorkloadForCanary: false
      steps:
      - replicas: 1
      - replicas: 50%
      - replicas: 100%

当workload-demo应用更新时：

• 在第一批中，将更新1个Pod，而replicas-1个Pod仍然保持在稳定版本，需要手动确认到下一批。
• 在第二批中，将更新50%的Pod，而50%的Pod仍然保持在稳定版本，需要手动确认到下一批。
• 在第三批中，将更新100%的Pod，而0个Pod仍然保持在稳定版本。

多批次发布策略与金丝雀发布策略不同，在发布过程中不会创建额外的Deployment。

Flux Flagger

Flux Flagger支持Kubernetes Deployment 和 DaemonSet的金丝雀、蓝绿发布。当部署应用程序的新版本时，Flagger会逐渐将流量转移到canary，同时监测请求成功率以及平均响应持续时间。支持通过自定义指标、验收测试和负载测试来扩展canary分析，以加强验证应用发布的过程。

金丝雀发布策略

CRD配置

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  service:
    port: 9898
  analysis:
    interval: 1m
    threshold: 10
    maxWeight: 50
    stepWeight: 5
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500
        interval: 1m
    webhooks:
      - name: load-test
        url: http://flagger-loadtester.test/
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://podinfo-canary.test:9898/"

方案也是Bypass（旁路），但提供了更多的验证分析能力，包括metric、webhook等，对于在发布过程中持续检测服务正常非常有用。

Flux的母公司Weaveworks很不幸在2024年年初倒闭了，曾在 2017 年提出了 GitOps 理念，并开源了Flux项目，非常可惜，Flux后续的路很难预料。

ArgoCD Rollouts

ArgoCD Rollouts与之前两个不同，它相当于Deployment的增强替代版，Argo Rollouts 控制器直接管理 ReplicaSet 的创建、扩展和删除，而不是管理Deployment。这些 ReplicaSet 由Rollouts资源中的字段定义，字段使用与Deployment相同的容器模板。

当 spec.template 更新后，会触发 Argo Rollouts 控制器执行更新流程，将创建新的 ReplicaSet。控制器将使用字段中的策略（spec.strategy）来确定从旧 ReplicaSet 到新 ReplicaSet 的更新，一旦新的 ReplicaSet 创建并扩展完成（并可选择通过 Analysis），控制器会将其标记为“stable”。

如果从 stable 的 ReplicaSet 过渡到新的 ReplicaSet 期间发生其他更改（即在更新过程中再次更新应用程序版本），则以前新的 ReplicaSet 将按比例缩小，并且控制器将尝试继续推进更新字段的 ReplicasSet，这和Deployment的逻辑是一样的。

金丝雀发布策略

CRD

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: example-rollout
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80
  minReadySeconds: 30
  revisionHistoryLimit: 3
  strategy:
    canary: #Indicates that the rollout should use the Canary strategy
      maxSurge: "25%"
      maxUnavailable: 0
      steps:
      - setWeight: 10
      - pause:
          duration: 1h # 1 hour
      - setWeight: 20
      - pause: {} # pause indefinitely

上面的图片显示了一个金丝雀，有两个阶段（10%和33%的流量流向新版本），但这只是一个例子。使用 Argo Rollouts，您可以根据您的用例定义确切的阶段数量和流量百分比。

总结