progressive-delivery

渐进式交付

两种互补的工具，可在 Kubernetes 环境中安全地推进版本：

• Argo Rollouts — 用支持金丝雀、蓝绿部署和指标门控自动分析的 Rollout CRD 替代 Deployment。在集群／服务网格层处理流量整形。
• Kargo — 为 GitOps 扩展晋级逻辑。跟踪 Freight（带版本的制品包），并通过 Warehouses（来源）和验证步骤，使其依次晋级到各个 Stages（开发 → 预发布 → 生产）。

ArgoCD 继续执行它原本的职责（将期望状态同步到集群）。Rollouts 决定单次部署期间的流量分流。Kargo 决定何时将新版本推进到下一个阶段。

范围路由

如果你需要……	阅读
对单个工作负载进行金丝雀／蓝绿／指标门控部署	References/argo-rollouts.md + References/argo-rollouts/
通过人工或自动门禁，将版本从开发 → 预发布 → 生产逐级晋级	References/kargo.md + References/kargo/
两者兼用（将 Rollouts 作为 Kargo 管理的晋级流程中的部署策略）	两者都读；Kargo 会调用 ArgoCD 来部署 Rollout

心智模型

Kargo:    Freight v1.2.3 -> [dev stage] -> verify -> [stg stage] -> verify -> [prod stage]
                                                                              |
                                                                              v
ArgoCD:                                                                   syncs Rollout manifest
                                                                              |
                                                                              v
Rollouts:                                                          canary @ 10% -> analysis -> 50% -> 100%

何时不应使用

• 不需要流量整形或分析门禁的简单 Deployment 滚动更新——原生 Kubernetes Deployment 就足够了。
• 通过编辑目标修订版本的 PR 手动晋级——这是核心 argocd 技能的范畴，不属于此处。
• 在应用内部使用功能标志和运行时百分比发布——这是应用层面的职责（LaunchDarkly、Unleash 等），而非部署层面的职责。

注意事项

• Rollouts 会替代 Deployment，而不是附加于它。 迁移现有应用意味着要更改资源类型。如果不使用 kubectl-argo-rollouts 转换，请为一个修订版本的停机做好计划。
• AnalysisTemplate 指标查询受 Rollouts 控制器权限的限制。 如果你的 Prometheus 位于其他命名空间，控制器需要 RBAC 权限或服务账号令牌。
• Kargo Freight 是不可变的。 创建后不能编辑——应创建新的 Freight。试图“修补”Stage 当前的 Freight 是一种反模式。
• Kargo 与 ArgoCD 集成需要 Kargo 控制器有权更新 ArgoCD Application CR。 默认安装不会授予此权限——请查看 argocd.permissions 的 Helm 配置值。
• 验证步骤在阶段之间运行，而非阶段内部。 验证失败不会回滚上一阶段，只会阻止继续晋级。如果需要回滚，那属于单独的 Rollouts 级分析。