禁用kube-apiserver匿名认证后健康检查失败的解决方法（自签名TLS集群）

当你把kube-apiserver的anonymous-auth设为false后，所有匿名请求都会被拒绝——包括健康检查常用的/livez、/readyz、/healthz这些端点，这就是健康检查失败的核心原因。结合你用自签名TLS证书部署的集群，这里有几个实用的解决思路：

方案1：让健康检查路径跳过认证（最简单直接） #

你可以在kube-apiserver的启动参数里加上--skip-auth-for-paths，指定那些不需要认证的健康检查路径。这样既能保证其他API接口的匿名访问被禁用，又能让健康检查正常工作。

修改kube-apiserver.yaml的启动参数部分，添加：

- --skip-auth-for-paths=/livez,/readyz,/livez/*,/readyz/*,/healthz,/healthz/*

⚠️ 注意：这个参数会让指定路径完全跳过认证和授权，只适合用于健康检查这类无敏感数据的端点，别随便扩展到其他API路径。

方案2：给健康检查客户端配置合法认证凭证 #

如果不想跳过认证，你可以让发起健康检查的客户端（比如kubelet、监控工具）用有效的认证凭证访问API Server：

针对kubelet的健康检查 #

kubelet本身默认会用自身的TLS证书和API Server通信，你需要确保：

• kubelet配置里的client-certificate和client-key指向合法的证书文件
• ca-file指向集群的自签名CA证书，避免TLS验证失败

为外部监控创建专用ServiceAccount #

如果是外部监控工具发起健康检查，可以创建一个专门的ServiceAccount，并绑定仅允许访问健康检查端点的权限：

1. 先创建ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: healthcheck-sa
  namespace: kube-system

2. 创建ClusterRole，定义健康检查的访问权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: healthcheck-role
rules:
- apiGroups: [""]
  resources: ["healthz", "livez", "readyz"]
  verbs: ["get"]

3. 把ClusterRole绑定到ServiceAccount：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: healthcheck-binding
subjects:
- kind: ServiceAccount
  name: healthcheck-sa
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: healthcheck-role
  apiGroup: rbac.authorization.k8s.io

之后让监控工具用这个ServiceAccount的token（从kube-system namespace下对应secret里获取），加上集群自签名CA证书来发起请求就行。

方案3：保留匿名认证但严格限制权限（不推荐） #

如果你只是想限制匿名用户的操作权限，而非完全禁用，可以保持anonymous-auth=true，然后通过RBAC把匿名用户的权限锁死在健康检查上：

创建ClusterRoleBinding，把system:anonymous用户绑定到刚才的healthcheck-role：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: anonymous-healthcheck
subjects:
- kind: User
  name: system:anonymous
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: healthcheck-role
  apiGroup: rbac.authorization.k8s.io

不过这个方案不如前两种安全，因为匿名用户仍然能通过认证，只是权限受限，除非有特殊需求，否则不建议用。

自签名TLS场景额外注意点 #

不管用哪个方案，都得确保健康检查客户端信任API Server的自签名CA证书：

• 对于kubelet，检查kubelet.conf里的ca-file是否指向集群CA证书
• 对于外部工具，要么把自签名CA证书加到客户端的信任池，要么在请求时指定CA文件（比如用curl的话：curl --cacert /path/to/ca.crt https://<apiserver-ip>:6443/livez）

内容的提问来源于stack exchange，提问作者JMit