Argo Rollouts：金丝雀发布中止与回滚异常问题求助

我来帮你分析下这个Argo Rollouts回滚失败的问题，结合日常排查这类场景的经验，可能的原因和调试步骤如下：

可能的原因分析 #

• 初始修订版本（revision 0）丢失：Argo Rollouts依赖修订历史执行回滚，如果你的Rollout配置了revisionHistoryLimit值过小，可能会把初始的revision 0清理掉，导致回滚时找不到目标版本。另外，如果Rollout创建时的初始状态未被正确记录，也会出现这个问题。
• 中止发布后的状态不一致：中止金丝雀发布时，虽然Pod缩容成功，但部分关联资源（比如Ingress路由规则、Service标签选择器、HPA配置）可能未同步回退到初始状态，导致Rollout控制器判定整体状态为degraded，进而阻断回滚流程。
• 资源状态冲突或残留：金丝雀实例缩容后，可能存在PodDisruptionBudget（PDB）限制、HPA自动扩缩容干扰，或者旧Pod的残留状态（比如Terminating状态的Pod未彻底清理），导致控制器无法正确识别可回滚的健康状态。
• 控制器权限不足：Argo Rollouts控制器的ServiceAccount可能缺少恢复旧版本所需的权限，比如修改Deployment、更新Ingress、操作Pod的权限，导致回滚操作执行失败。
• Rollout配置逻辑错误：金丝雀发布策略中的步骤定义（比如canary.steps里的缩容、路由调整步骤）存在逻辑问题，中止时无法正确触发完整回退流程，留下异常状态。

调试排查建议 #

• 查看Rollout的详细状态与事件：执行kubectl argo rollouts describe rollout <你的Rollout名称>，重点关注Status字段下的Conditions和RevisionHistory，确认revision 0是否存在，以及degraded状态的具体触发原因；同时检查Events部分，看是否有控制器输出的错误提示。
• 检查修订历史列表：用kubectl argo rollouts history rollout <你的Rollout名称>查看所有可用的修订版本，如果revision 0不在列表中，说明修订历史被清理，需要调整Rollout配置中的revisionHistoryLimit参数（建议设置为至少5以上）。
• 验证关联资源状态：检查Rollout关联的Deployment、Service、Ingress等资源的状态，比如执行kubectl describe deployment <关联Deployment名称>，确认是否有异常事件；同时确认Ingress的路由规则是否已经回退到初始版本的Pod标签。
• 查看控制器日志：获取Argo Rollouts控制器的日志，执行kubectl logs -n argo-rollouts <控制器Pod名称>，搜索“failed restoring revision 0”或“degraded”关键词，找到具体的错误堆栈信息，这通常能定位到核心问题。
• 手动验证初始版本：尝试基于revision 0的配置手动创建Pod或Deployment，确认该版本本身是否能正常运行，排除镜像拉取、配置错误等自身问题。
• 检查控制器权限：验证Argo Rollouts控制器的ServiceAccount权限，比如执行kubectl auth can-i update deployment --as=system:serviceaccount:argo-rollouts:argo-rollouts，确认是否拥有必要的资源操作权限，如果缺少权限，需要调整对应的Role或ClusterRole绑定。

内容的提问来源于stack exchange，提问作者Daire