Azure AKS中Calico控制器重复容忍标签问题解析

Azure AKS中Calico控制器重复容忍标签问题解析

AKS Azure Kubernetes Service 项目地址: https://gitcode.com/gh_mirrors/ak/AKS

问题背景

在Azure Kubernetes Service(AKS)集群中，当启用Calico网络插件时，系统会自动创建calico-system命名空间。该命名空间下的calico-kube-controllers部署存在一个配置问题：CriticalAddonsOnly容忍标签被重复定义。这一配置问题在Prometheus 2.52.0及以上版本中会引发告警，因为新版本引入了对重复样本的检查机制。

技术细节分析

在部署配置中，CriticalAddonsOnly容忍标签出现了两次：

tolerations:
- key: CriticalAddonsOnly
  operator: Exists
- effect: NoSchedule
  key: node-role.kubernetes.io/master
- effect: NoSchedule
  key: node-role.kubernetes.io/control-plane
- key: CriticalAddonsOnly
  operator: Exists

这种重复定义会导致kube-state-metrics生成重复的监控指标，进而触发Prometheus的重复样本告警。具体表现为Prometheus日志中出现"Duplicate sample for timestamp"警告信息。

问题根源

深入分析发现，该问题的根源在于AKS的安装资源配置与Tigera Operator的交互方式：

1. AKS通过operator.tigera.io/v1 Installation资源配置Calico安装参数，其中显式设置了controlPlaneTolerations参数
2. Tigera Operator在渲染控制器配置时，会将传入的容忍配置与默认配置进行合并
3. 默认配置中已经包含了CriticalAddonsOnly容忍标签
4. 这种合并操作导致了最终的重复定义

解决方案演进

Azure团队经过详细调查后确定了解决方案：

1. 确认CriticalAddonsOnly容忍标签的历史背景：该配置最初是为解决Calico迁移到Tigera Operator时的生产问题而添加
2. 评估移除该配置的影响：虽然直接移除是可行的，但会连带影响Typha部署的容忍配置
3. 制定分阶段实施计划：在保证稳定性的前提下，计划在Calico 3.28版本中移除重复配置

版本更新与影响

该修复已随AKS 1.31版本推出，用户升级到该版本后即可解决此问题。对于仍在使用早期版本的用户，可以考虑以下临时解决方案：

1. 降级Prometheus到2.51.2版本
2. 临时禁用相关告警规则
3. 手动编辑部署配置移除重复容忍标签（需注意后续可能被系统自动恢复）

最佳实践建议

对于Kubernetes运维人员，建议：

1. 定期检查集群中的容忍配置，避免重复定义
2. 升级监控组件前，充分测试兼容性
3. 关注AKS版本更新日志，及时获取修复信息
4. 对于关键组件配置变更，应在测试环境充分验证后再应用到生产环境

该案例也提醒我们，在Kubernetes生态系统中，组件间的交互可能产生意料之外的问题，保持各组件版本协调更新是维护集群稳定的重要因素。

AKS Azure Kubernetes Service 项目地址: https://gitcode.com/gh_mirrors/ak/AKS