企业灰度发布 11：Argo Rollouts、Flagger、Kruise Rollouts 应该怎样选

Argo Rollouts、Flagger 和 Kruise Rollouts 都能完成 Canary，却使用不同的所有权模型。真正影响企业平台的不是“能不能 10%→20%”，而是：谁创建新旧副本，谁修改 Service 与 Istio 资源，分析对象怎样持久化，原有 Deployment 是否要迁移，GitOps 如何处理运行时变化，以及控制器失效后怎样恢复。

截至本文撰写时，Argo Rollouts 稳定版为 v1.9.1；Flagger 最新变更记录为 v1.44.0。版本会继续变化，选型时应重新核验兼容矩阵和发布说明，而不是长期复制某张对比表。

Argo Rollouts：把工作负载本身变成发布状态机

Argo Rollouts 引入 kind: Rollout，在 ReplicaSet 管理方式上接近 Deployment，但原生表达 canary/blue-green steps、pause、analysis、experiment 和 traffic routing。控制器负责 stable/canary ReplicaSet 与 Service selector，并修改 Istio VirtualService 权重或 DestinationRule subset label。

这种模型的优点是状态集中：一个 Rollout 对象能清楚展示当前 step、stable revision、canary revision、AnalysisRun 和 abort/promotion 状态；CLI、Dashboard、Argo CD 生态也自然。缺点是现有 Deployment 要迁移为 Rollout，运维工具、HPA 引用和组织规范需要适配。

Argo 对 Istio 的权重 setWeight 是成熟路径，也支持 host-level 和 subset-level。需要注意，项目能力表目前仍把 Istio Header 与 Mirror 路由标为 alpha，不应与稳定权重切流按同一成熟度承诺生产 SLA。平台若依赖这些能力，要锁定版本、运行专门回归，并准备原生 Istio 路由兜底。

Flagger：围绕原生工作负载生成 primary/canary 拓扑

Flagger 监听带 Canary CRD 的 Deployment 等工作负载，创建或维护 primary 工作负载、canary 服务和流量资源，再按 analysis.interval、threshold、stepWeight 等配置执行指标驱动的协调循环。它还提供 load tester 和 webhook，适合在每轮流量增加时运行验收或合成负载。

Flagger 的哲学更自动化：检测到新 revision，验证 canary 就绪，逐步增加权重，指标失败次数超过阈值就回退，通过后把 canary 内容提升到 primary。与 FluxCD 组合时，GitOps 体验自然；如果企业已经把 Flux 作为标准控制面，Flagger 通常比再引入一套 Argo 生态更顺。

代价是它生成/管理的 primary 与服务拓扑需要团队理解。排障不能只看原始 Deployment；HPA、PDB、网络策略和监控也要覆盖生成资源。平台必须把这些派生对象映射回一个业务 Release，否则用户会看到多个相似工作负载却不知谁是源对象。

Kruise Rollouts：旁路增强已有工作负载

Kruise Rollouts 强调 Bypass 和低迁移成本，通过 workloadRef 绑定现有 Deployment、StatefulSet、CloneSet、DaemonSet 等，在发布期间暂停原工作负载更新，按策略创建额外 canary 或执行多批次更新，再管理流量路由。对于已有大量原生工作负载、包含有状态和 OpenKruise workload 的企业，这个边界很有吸引力。

它还把 End-to-End Canary 做成显式策略，通过共享 TrafficRouting、Pod metadata 和流量标记构建微服务泳道。流量协议除 Gateway API 外，还能用 Lua 扩展特定 CRD，包括 Istio DestinationRule 等；扩展性高，但自定义脚本也进入控制面供应链，需要版本、权限、测试和沙箱治理。

指标自动判定不是 Kruise 的最强核心。若企业要求复杂 Prometheus 分析与自动决策，需要评估配套控制器、webhook 或平台层分析，而不能仅凭“自动回滚”一项打勾。

三种协调循环的差异

新建平台为什么仍优先 Argo Rollouts

如果从零建设 Kubernetes + Istio 企业发布平台，我仍会把 Argo Rollouts 作为默认执行器。原因不是它每一项都胜出，而是其 Release 状态、AnalysisRun、Experiment、CLI/可视化和 Argo CD 生态更适合作为通用平台底座，底层对象也容易向用户解释。

但“默认”不应变成“唯一”。已有 Flux 团队可以用 Flagger；大量 StatefulSet/DaemonSet 或强低侵入需求可以接 Kruise。平台通过 adapter 抽象 Prepare → ShiftTraffic → Analyze → Promote/Abort → Observe，保留各控制器特有能力，而不是设计一份最小公倍数 CRD 抹平差异。

二开边界：不要 fork 控制器起步

最危险的路线是 fork Argo Rollouts，在控制器内部塞入企业审批、CMDB、工单、通知和多集群编排。这样会把上游升级、安全修复和生态兼容变成长期负担。更稳妥的做法是上层平台编排标准 CRD，通过 admission policy、事件订阅、Analysis provider、webhook 或插件扩展企业能力。

只有当核心协调语义无法通过扩展点实现，并且团队愿意承担长期控制器维护时，才考虑 fork。即使如此，也应把补丁保持小而可重放，持续跟踪上游发布。

选型 POC 必须验证的失败场景

不要只演示一次成功发布。至少要测试：控制器在每个 step 重启；Istio 配置 NACK；Prometheus 不可用；canary ready 但无流量；promotion 写 primary 失败；用户手工修改 route；GitOps 同步冲突；abort 后长连接仍在 canary；HPA 在发布中扩缩；旧版本与新 schema 不兼容。

选择控制器的标准不是 happy path YAML 最短，而是失败后哪个系统更容易解释、恢复和审计。下一篇专门设计自动判定：如何用 Prometheus、SLO 与业务指标避免“错误自动化”。

参考资料

• Argo Rollouts GitHub
• Argo Rollouts：Istio Traffic Management
• Flagger：Istio Progressive Delivery
• Flagger Changelog
• OpenKruise Rollouts：Introduction