EKS Anywhere vSphere集群升级中的KubeletCredentialProviders特性门控问题解析

问题背景

在使用EKS Anywhere 0.20.8版本将vSphere集群从Kubernetes 1.27升级到1.28版本时，运维团队遇到了一个关键问题。在升级过程中，新增的控制平面节点无法正常加入集群，始终处于NotReady状态。

问题现象

通过检查kubelet日志，发现以下关键错误信息：

E1107 17:25:55.770885 280524 run.go:74] "command failed" err="failed to set feature gates from initial flags-based config: unrecognized feature gate: KubeletCredentialProviders"

这表明kubelet启动时尝试启用一个不被识别的特性门控"KubeletCredentialProviders"。

根本原因分析

1. 特性门控演变：KubeletCredentialProviders特性在Kubernetes 1.28中已被正式GA，不再作为可配置的特性门控存在。这意味着该特性已成为核心功能的一部分，不能再通过特性门控来启用或禁用。

2. 配置残留：EKS Anywhere在升级过程中可能保留了旧版本的kubelet配置，其中包含了对已废弃特性门控的引用。

3. 版本兼容性：这个问题特别出现在从1.27升级到1.28的过程中，因为这两个版本对特性门控的处理方式发生了变化。

解决方案

运维团队采取的临时解决方案是：

1. 编辑每个节点的/etc/sysconfig/kubelet文件
2. 移除--feature-gates=KubeletCredentialsProviders=true配置项
3. 重启kubelet服务

这个手动干预使得节点能够正常加入集群。

长期修复

EKS Anywhere团队已经通过代码修复解决了这个问题。修复的核心内容是：

1. 移除了对KubeletCredentialProviders特性门控的显式配置
2. 确保升级过程中生成的kubelet配置与目标Kubernetes版本兼容
3. 更新了相关的软件包控制器版本

最佳实践建议

对于使用EKS Anywhere的管理员，建议：

1. 升级前检查：在执行主要版本升级前，检查当前集群中所有节点的kubelet配置
2. 版本兼容性：了解目标Kubernetes版本中已变更的特性门控状态
3. 备份策略：如文中所述，在执行升级前确保有完整的ETCD集群备份
4. 分阶段验证：升级后验证所有核心组件(如包控制器)是否已同步更新到正确版本

总结

这个问题展示了Kubernetes生态系统中的一个常见挑战：随着功能的成熟和稳定，特性门控的生命周期管理。EKS Anywhere团队通过及时修复确保了升级路径的顺畅，同时也提醒管理员需要关注Kubernetes版本间的配置差异。对于企业用户而言，理解这些底层机制有助于更顺利地完成集群升级和维护工作。