Argo Rollouts中旧ReplicaSet未自动清理的问题分析与解决

问题背景

在Kubernetes的渐进式交付场景中，Argo Rollouts作为一款强大的部署控制器，负责管理应用版本间的平滑过渡。近期在v1.7.1版本中，用户反馈存在一个关键问题：当Rollout完成新版本切换后，旧的ReplicaSet及其Pod有时会异常保留在集群中，未能按预期被清理。

问题现象

典型表现为：

1. 新版ReplicaSet已完全就绪并承担流量
2. 控制器成功将旧版ReplicaSet标记为非活跃状态
3. 但旧ReplicaSet的Pod实例持续运行，占用集群资源
4. 通过检查发现，问题ReplicaSet的argo-rollouts.argoproj.io/scale-down-deadline注解值为空字符串，而非预期的ISO 8601时间戳

根本原因分析

通过日志追踪发现，问题源于控制器在更新ReplicaSet时的竞态条件处理：

1. 控制器首先正确设置了scale-down-deadline为未来时间点（如2024-09-19T09:35:41Z）
2. 但在后续的冲突处理中，通过patch操作意外将注解值重置为空字符串
3. 空字符串导致控制器无法识别应被清理的ReplicaSet
4. 最终导致旧版本资源持续滞留

关键日志片段显示，在冲突回退到patch操作时，scale-down-deadline被错误更新：

{
  "metadata": {
    "annotations": {
      "scale-down-deadline": ""
    }
  }
}

解决方案

项目维护团队在v1.7.2版本中修复了该问题，主要改进包括：

1. 优化了ReplicaSet更新逻辑，确保scale-down-deadline注解的原子性
2. 增强了冲突处理机制，避免注解值被意外清除
3. 完善了状态同步流程，保证元数据一致性

最佳实践建议

对于遇到类似问题的用户：

1. 及时升级到v1.7.2或更高版本
2. 对于已存在的"僵尸"ReplicaSet，可手动添加正确的scale-down-deadline注解或直接删除
3. 在生产环境部署前，建议在测试环境验证Rollout的完整生命周期
4. 监控ReplicaSet的注解变化，确保scale-down流程正常触发

技术启示

该案例揭示了Kubernetes控制器开发中的常见挑战：

• 注解作为重要状态载体时的并发控制
• 乐观锁冲突处理中的状态保持
• 分布式系统最终一致性的保证

Argo Rollouts通过版本迭代不断完善这些关键机制，为复杂部署场景提供了更可靠的保障。