Argo Rollouts更新镜像后Pod异常：旧Pod重建新Pod就绪异常求助

核心问题拆解 #

1. Argo Rollouts 更新流程卡住：新 Pod 始终无法进入就绪状态（0/1），导致 Rollout 无法推进替换旧 Pod
2. 旧 Pod 被重复重建：管理旧 Pod 的控制器（Argo Rollout 或其他资源）仍在维持旧版本副本数，删除旧 Pod 后会触发重建

排查步骤 #

1. 查看 Argo Rollout 资源状态 #

执行命令获取 Rollout 详细状态，确认更新是否卡在某个阶段：

kubectl argo rollouts get rollout detector -n ddash5

重点关注：

• Rollout 的 STATUS 字段，是否显示 Progressing 或 Paused
• 新旧版本的副本数分布，以及更新进度百分比

2. 检查新 Pod 的详细状态与事件 #

查看新 Pod 的启动日志和事件，定位就绪失败原因：

# 查看 Pod 事件和状态详情
kubectl describe pod detector-68f89d8b45-j465j -n ddash5

# 查看容器日志，确认应用启动是否正常
kubectl logs detector-68f89d8b45-j465j -n ddash5

重点排查：

• Events 部分是否有就绪探针失败（Readiness probe failed）的记录
• 容器日志中是否有报错、端口未监听、依赖缺失等问题

3. 验证 Argo Rollout 配置 #

检查 Rollout 的更新策略和探针配置是否合理：

kubectl get rollout detector -n ddash5 -o yaml

重点确认：

• spec.strategy 配置是否为滚动更新（RollingUpdate），maxSurge 和 maxUnavailable 参数是否符合预期
• spec.template.spec.containers[*].readinessProbe 配置是否正确，比如探针路径、端口、延迟时间是否适配应用启动速度

4. 排查控制器冲突 #

确认是否存在多个控制器（如 Deployment + Argo Rollout）同时管理该服务：

# 查看所有 Deployment
kubectl get deployments -n ddash5

# 查看所有 Argo Rollout
kubectl get rollouts -n ddash5

如果同时存在 Deployment 和 Rollout，会导致资源管理冲突，旧 Pod 会被 Deployment 重复重建。

解决思路 #

1. 修复新 Pod 就绪问题 #

• 如果是就绪探针配置不合理：调整 readinessProbe 的 initialDelaySeconds（延长启动等待时间）、timeoutSeconds（延长探针超时时间），确保应用启动完成后能通过探针
• 如果是应用本身问题：根据容器日志修复代码或依赖，确保服务能正常启动并监听指定端口

2. 推进或恢复 Rollout 更新 #

如果 Rollout 被暂停或卡住，执行以下命令手动推进：

# 恢复暂停的 Rollout
kubectl argo rollouts resume detector -n ddash5

# 手动推进更新（适用于蓝绿/金丝雀策略）
kubectl argo rollouts promote detector -n ddash5

3. 解决控制器冲突 #

如果存在 Deployment 和 Rollout 共存的情况，删除多余的 Deployment：

kubectl delete deployment <deployment-name> -n ddash5

确保只有 Argo Rollout 管理该服务的 Pod 生命周期。

4. 强制更新 Rollout #

如果上述步骤无效，可尝试强制触发 Rollout 更新：

kubectl argo rollouts restart detector -n ddash5

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