Kubernetes kubeadm中匿名认证关闭导致控制平面健康检查失败问题分析

在Kubernetes 1.33.0-beta.0版本中，当使用kubeadm初始化集群时，如果配置kube-apiserver关闭匿名认证（anonymous-auth=false），同时启用了WaitForAllControlPlaneComponents特性门控（默认开启），会导致控制平面健康检查失败。本文将深入分析该问题的技术背景、产生原因及解决方案。

问题现象

在默认配置下执行kubeadm init时，系统会对控制平面组件进行健康检查。当出现以下配置组合时：

• anonymous-auth=false
• WaitForAllControlPlaneComponents=true（1.33.0-beta.0默认开启）

健康检查会因kube-apiserver的/livez端点返回401未授权状态而失败。值得注意的是，其他控制平面组件的检查仍能正常通过。

技术背景

kubeadm的健康检查机制在1.33版本经历了重要变更。WaitForAllControlPlaneComponents特性门控进入Beta阶段并被默认启用后，健康检查的实现逻辑发生了变化：

1. 旧版实现（特性门控禁用时）： 使用完整的客户端集合（clientSet）进行请求，包含正确的认证信息

2. 新版实现（特性门控启用时）： 改用简单的http.Client直接发起请求，缺乏认证处理机制

根本原因

问题核心在于新版健康检查实现没有考虑认证场景：

• 当匿名认证关闭时，直接HTTP请求会因缺少认证信息被拒绝
• 旧版实现通过客户端集合自动处理了认证流程
• 这种不一致性导致了特定配置下的检查失败

解决方案

对于该问题，社区已提出修复方案，主要思路是：

1. 对kube-apiserver的健康检查特殊处理
2. 继续使用发现客户端（discovery client）而非简单HTTP请求
3. 保持向后兼容性

临时解决方案

在官方修复发布前，用户可以采取以下临时措施：

1. 调整探针配置： 将kube-apiserver的就绪探针改为TCP检查模式：

readinessProbe:
  failureThreshold: 3
  periodSeconds: 1
  tcpSocket:
    port: 6443
  timeoutSeconds: 3

2. 关闭特性门控： 在kubeadm配置中显式禁用WaitForAllControlPlaneComponents

最佳实践建议

1. 生产环境中如需关闭匿名认证，应全面评估对各个组件的影响
2. 关注Kubernetes官方更新，及时应用修复版本
3. 对关键组件（如kube-apiserver）的健康检查机制进行充分测试

该问题的出现提醒我们，在修改安全相关配置时，需要全面考虑其对集群管理工具链的影响，特别是在特性门控状态变化时更应谨慎验证。