日常运维与故障排查
排查 Rollout 时先判断问题发生在哪一层：Rollout Controller、Pod/ReplicaSet、流量路由、AnalysisRun、监控系统还是业务本身。不要在没有保存状态和事件前反复 abort、retry 或删除资源，否则会丢失最有价值的现场证据。
1. 发布窗口巡检
# Rollout 当前步骤、暂停原因、稳定/金丝雀版本
kubectl argo rollouts get rollout <rollout-name> -n <namespace>
# Pod、ReplicaSet 和节点分布
kubectl get pods,replicasets -n <namespace> -l app=<app-name> -o wide
# 事件按时间排序
kubectl get events -n <namespace> --sort-by=.lastTimestamp | tail -80
# Controller 状态和最近日志
kubectl get pods -n argo-rollouts
kubectl logs -n argo-rollouts deploy/argo-rollouts --tail=300
发布开始前记录 Rollout 的 Git revision、镜像 digest、目标集群、流量入口、当前告警和回滚责任人。发布结束后记录实际开始时间、完成时间、停留时长和业务验证结果。
2. 常用控制命令
# 暂停后保留现场，适合等待业务负责人确认
kubectl argo rollouts pause <rollout-name> -n <namespace>
# 继续当前步骤或跳过剩余人工暂停
kubectl argo rollouts promote <rollout-name> -n <namespace>
# 发现错误时终止当前发布并恢复稳定版本流量
kubectl argo rollouts abort <rollout-name> -n <namespace>
# 修复明显的临时问题后重试中止的 Rollout
kubectl argo rollouts retry <rollout-name> -n <namespace>
# 查看发布历史与 ReplicaSet
kubectl argo rollouts history rollout <rollout-name> -n <namespace>
kubectl argo rollouts list replicasets <rollout-name> -n <namespace>
promote 和 abort 都是有实际影响的操作，脚本化执行时应增加环境确认、审批号和操作者记录。生产环境不建议把 --full 或跳过等待作为默认参数。
3. 发布卡在暂停状态
现象
Rollout 长时间显示 Paused，没有继续增加权重。
排查
kubectl argo rollouts get rollout <rollout-name> -n <namespace>
kubectl describe rollout <rollout-name> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp
确认是预期的 pause: {}、AnalysisRun 尚未完成，还是 Controller 无法更新流量路由。若是人工暂停，先确认发布窗口和责任人，再执行 promote；不要看到 Paused 就直接重试。
4. AnalysisRun 失败或没有数据
重点检查：
- AnalysisTemplate 的 Prometheus 地址是否可达；
- 查询标签是否能匹配金丝雀 Pod；
- 时间窗口内是否有足够真实请求；
- 查询返回空结果时，AnalysisRun 的处理策略是什么；
- Prometheus 是否限流、重启或发生远端存储延迟。
kubectl get analysisrun -n <namespace>
kubectl describe analysisrun <analysisrun-name> -n <namespace>
kubectl logs -n argo-rollouts deploy/argo-rollouts --tail=300 | rg -i 'analysis|prometheus|metric|error'
指标失败时不要直接修改阈值让发布变绿。先保存查询、原始结果和发布版本，再判断是应用问题、监控问题还是查询设计问题。
5. 流量权重没有变化
如果 Rollout 的 setWeight 已更新，但真实流量仍全部进入稳定版本，通常是以下原因之一：
trafficRouting引用的 VirtualService、Ingress 或 HTTPRoute 名称错误；- 入口流量没有经过配置的流量提供者；
- Service selector、Pod hash 标签或 DestinationRule subset 不匹配；
- Gateway/Ingress Controller 不支持当前 Rollouts 版本需要的权重更新方式；
- 缓存、重试或长连接让短时间统计看起来没有变化。
# 查看 Rollout 状态与流量路由对象
kubectl argo rollouts get rollout <rollout-name> -n <namespace>
kubectl get virtualservice,httproute,ingress -n <namespace> -o yaml
kubectl get service -n <namespace> <stable-service> <canary-service> -o yaml
应结合入口访问日志、服务指标和压测结果验证真实流量，不要只看 Rollout YAML 中的权重字段。
6. Pod 不健康或新 ReplicaSet 无法扩容
# 查看 Pod 状态、事件和探针失败原因
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --all-containers --tail=300
# 查看调度和资源容量
kubectl describe rs <replicaset-name> -n <namespace>
kubectl get nodes
kubectl get resourcequota,limitrange -n <namespace>
常见原因包括镜像拉取失败、Secret 不存在、ReadinessProbe 路径错误、端口不匹配、资源请求过高、PDB 或节点容量不足。先修复工作负载本身，再决定是否继续发布。
7. 证据采集与恢复顺序
故障现场至少保存：
- Rollout、ReplicaSet、Service、Ingress/VirtualService/HTTPRoute YAML；
- Rollout、AnalysisRun 的 describe 输出；
- Pod 事件、容器日志、Controller 日志；
- 发布 Git commit、镜像 digest、指标查询和实际路由权重；
- 执行过的
pause、promote、abort、retry命令及操作者。
推荐恢复顺序：
- 停止继续放量，必要时执行
pause； - 若新版本明显异常，执行
abort，确认流量回到稳定版本； - 记录证据并隔离有问题的镜像或配置；
- 通过 Git 回退或修复后再执行新的发布；
- Analysis、路由和业务验证都通过后再恢复自动晋级。