Rancher Fleet项目中Agent不必要重新部署问题的分析与解决

问题背景

在Rancher Fleet项目中发现了一个关键问题：当fleet-controller Pod重启时，会导致fleet-agent被不必要地重新部署。这个问题在Harvester集群中尤为明显，因为Harvester内置了Rancher用于本地集群管理，fleet-controller和fleet-agent都会被自动部署。

问题现象

通过日志分析发现，每次fleet-controller Pod重启时，都会触发以下行为：

1. 检测到API服务器配置变更
2. 删除旧的fleet-agent
3. 部署新的fleet-agent

这种不必要的重新部署在管理ManagedCharts时尤其危险，因为fleet-agent可能在任意时间点部署或更新ManagedCharts，中间状态的ManagedCharts可能会被新部署的fleet-agent回滚，导致其他问题。

根本原因分析

深入分析后发现问题的根源在于配置变更检测逻辑存在缺陷：

1. 配置来源不一致：

   • fleet-controller从ConfigMap中获取配置，其中apiServerURL是Rancher服务IP（如https://10.53.47.173）
   • 集群使用的Secret中apiServerURL是默认的Kubernetes服务IP（如https://10.53.0.1:443）
   • 两者的apiServerCA也始终不同

2. 变更检测逻辑问题：

   • 当前实现简单地比较ConfigMap和Secret中的值
   • 没有考虑Secret中值为空时回退到ConfigMap的逻辑
   • 导致hasConfigChanged函数几乎总是返回true

解决方案

修复方案主要改进了配置变更检测逻辑：

1. 增强变更检测：

   • 在onChange处理中添加了对非回退情况的检查
   • 只有当实际配置发生变更时才触发重新部署

2. 版本适配：

   • 该修复针对Rancher v2.12.*和Fleet v0.13.*版本
   • 在Fleet v0.13.0-alpha.5版本中已验证有效

验证结果

在Harvester v1.6.0-master-head集群上进行了验证：

1. 修复前行为：

   • 每次fleet-controller Pod被杀死后，fleet-agent都会被替换

2. 修复后行为：

   • 应用包含修复的Fleet v0.13.0-alpha.5版本后
   • 杀死fleet-controller Pod不再影响fleet-agent Pod
   • 系统稳定性显著提高

技术影响

这个修复对于生产环境尤为重要，因为它：

1. 减少了不必要的Pod重新部署
2. 提高了ManagedCharts管理的稳定性
3. 降低了系统维护期间的意外中断风险
4. 优化了集群升级过程的可靠性

总结

Rancher Fleet项目中这个配置变更检测问题的修复，体现了在Kubernetes控制器设计中正确处理配置变更的重要性。通过精确识别真正的配置变更，而不是简单地比较不同来源的值，可以显著提高系统的稳定性和可靠性。这对于依赖Fleet进行大规模集群管理的用户来说是一个重要的改进。