Argo Rollouts 1.7.1版本中副本集缩容异常问题分析

在Kubernetes渐进式交付工具Argo Rollouts从1.6.6升级到1.7.1版本后，用户报告了一个偶发性问题：在使用蓝绿部署策略时，旧的ReplicaSet有时无法按预期自动缩容，导致旧版本Pod持续运行。虽然流量正确地路由到了新版本，但资源浪费问题不容忽视。

问题现象

当用户执行蓝绿部署流程时，按照设计，新版本完成部署并经过验证后，旧版本的ReplicaSet应该在预设的时间后自动缩容。但在1.7.1版本中，这一机制出现了间歇性失效，表现为：

1. 控制器正确设置了scale-down-deadline注解（默认为30秒后）
2. 但在后续操作中，该注解被意外清空
3. 导致旧ReplicaSet永远不会触发缩容操作

根本原因分析

通过审查控制器日志和代码变更，发现问题源于1.7.1版本引入的一个逻辑错误。在函数updateReplicaSetFallbackToPatch中，处理scale-down-deadline注解时错误地从Labels而非Annotations中取值：

if _, found := rs.Annotations[v1alpha1.DefaultReplicaSetScaleDownDeadlineAnnotationKey]; found {
    patchRS.Annotations[v1alpha1.DefaultReplicaSetScaleDownDeadlineAnnotationKey] = rs.Labels[v1alpha1.DefaultReplicaSetScaleDownDeadlineAnnotationKey]
}

这段代码本意是保留原有的缩容截止时间，但由于错误地从Labels字典取值（实际上该值存储在Annotations中），导致最终写入了一个空字符串，从而取消了缩容计划。

问题影响

该缺陷会导致以下后果：

1. 资源浪费：旧版本Pod持续运行占用集群资源
2. 版本混乱：虽然流量路由正确，但运维人员可能被运行中的旧版本Pod误导
3. 部署历史堆积：随着多次部署，未缩容的ReplicaSet会不断累积

解决方案

该问题已在后续版本中修复，修复方案非常简单：将错误的rs.Labels引用改为正确的rs.Annotations。对于遇到此问题的用户，建议：

1. 升级到包含修复的版本
2. 临时解决方案：手动删除旧的ReplicaSet或将其副本数设为0
3. 检查所有蓝绿部署，确认旧版本是否已正确缩容

经验教训

这个案例展示了注解(Annotations)和标签(Labels)混淆可能带来的问题。在Kubernetes生态中：

• 标签(Labels)用于标识和选择资源
• 注解(Annotations)用于存储非标识性元数据

开发者在处理这两种元数据时需要格外小心，类似的类型混淆可能导致难以追踪的间歇性故障。这也说明了在变更涉及核心流程的代码时，需要增加充分的测试用例，特别是对于并发修改场景的测试。