解决calico-apiserver认证失败问题
作者：CN-FuWei
文章解决Calico APIServer状态异常和命名空间删除报错问题,指出需在三台Master节点修改kube-apiserver的--requestheader-allowed-names参数,允许aggregator CN,此参数控制聚合层代理连接的客户端证书CN白名单
一、问题现象
现象一：calico-apiserver状态为False
# kubectl get apiservices.apiregistration.k8s.io v3.projectcalico.org calico-apiserver/calico-api False (FailedDiscoveryCheck) 3d23h
# kubectl describe apiservices.apiregistration.k8s.io v3.projectcalico.org
...
Status:
Conditions:
Last Transition Time: 2025-08-21T08:35:54Z
Message: failing or missing response from https://172.19.226.198:5443/apis/projectcalico.org/v3: bad status from https://172.19.226.198:5443/apis/projectcalico.org/v3: 401
Reason: FailedDiscoveryCheck
Status: False
Type: Available
Events: <none>现象二：删除命名空间报错
# kubectl describe ns mysql-test Name: mysql-test Labels: kubernetes.io/metadata.name=mysql-test Annotations: <none> Status: Terminating Conditions: Type Status LastTransitionTime Reason Message ---- ------ ------------------ ------ ------- NamespaceDeletionDiscoveryFailure True Sat, 23 Aug 2025 20:26:51 +0800 DiscoveryFailed Discovery failed for some groups, 1 failing: unable to retrieve the complete list of server APIs: projectcalico.org/v3: stale GroupVersion discovery: projectcalico.org/v3 NamespaceDeletionGroupVersionParsingFailure False Sat, 23 Aug 2025 20:26:51 +0800 ParsedGroupVersions All legacy kube types successfully parsed NamespaceDeletionContentFailure False Sat, 23 Aug 2025 20:26:51 +0800 ContentDeleted All content successfully deleted, may be waiting on finalization NamespaceContentRemaining False Sat, 23 Aug 2025 20:26:52 +0800 ContentRemoved All content successfully removed NamespaceFinalizersRemaining False Sat, 23 Aug 2025 20:26:52 +0800 ContentHasNoFinalizers All content-preserving finalizers finished
二、排查过程
# kubectl logs -n calico-apiserver calico-apiserver-xxx --timestamps calico-apiserver Unable to authenticate the request" error="[x509: subject with cn=front-proxy-client is not in the allowed list, verifying certificate x509: certificate signed by unknown authority
三、解决方案
三台master节点修改kube-apiserver配置：
#二进制部署： vim /usr/lib/systemd/system/kube-apiserver.service #kubeadm部署： vim /etc/kubernetes/manifests/kube-apiserver.yaml --- #新增白名单 --requestheader-allowed-names=aggregator,front-proxy-client
检查配置是否生效：
kubectl -n kube-system get cm extension-apiserver-authentication -o yaml|grep "requestheader-allowed-names"
四、问题分析
工作流程：
简单来说：
修改 --requestheader-allowed-names 参数是为了允许 Kubernetes 聚合层（API Server Aggregator）安全地代理你的请求到后续部署的扩展 API Server，而 aggregator 这个 CN（Common Name）正是这些扩展 API Server 的客户端证书必须包含的标识。
- 例子：
metrics.k8s.io(由 metrics-server 提供)、custom.metrics.k8s.io(由 Prometheus Adapter 提供)、v3.projectcalico.org(由 Calico API Server 提供)。 - 好处：用户可以使用统一的
kubectl工具和相同的认证/授权机制来访问这些扩展功能。 - 作用：这是一个安全白名单。它指定了在代理请求的 TLS 连接中，客户端证书的 Common Name (CN) 字段必须是什么，主 API Server 才会接受并信任这个连接。
- 为什么是
aggregator：在二进制部署中，我们通常为聚合层功能专门创建一个客户端证书，这个证书的 CN（Common Name）字段通常就设置为aggregator。因此，我们需要在--requestheader-allowed-names参数中明确允许这个 CN。 - 如果不设置或设置错误：即使客户端证书由正确的 CA 签发，但如果 CN 不在这个白名单中，主 API Server 也会拒绝代理连接，你会看到
403 Forbidden错误。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。