2. Kubernetes 证书体系回顾：CA 证书、kubelet 证书、API Server 证书的作用
在排查证书轮换引发的 Pod 调度失败之前，必须理清 Kubernetes 控制面与工作节点之间的信任模型。Kubernetes 使用双向 TLS（mTLS）保证所有组件通信的机密性与完整性，而这一信任体系的根基就是 集群根 CA（Certificate Authority）。
2.1 证书体系总览
Kubernetes 集群的 PKI（公钥基础设施）由以下核心证书构成，它们共同支撑了控制面与节点之间的安全通信：
| 证书类型 | 签发对象 | 核心用途 | 轮换方式 |
|---|---|---|---|
| 集群 CA 证书 | 自签发（根证书） | 作为信任锚点，签发所有组件证书 | 手动更新，需重启全部组件 |
| API Server 证书 | kube-apiserver | 对外提供 HTTPS 服务，验证客户端身份 | kubelet 自动轮换或手动更新 |
| kubelet 证书 | 每个 Node 上的 kubelet | 向 API Server 注册身份，提供 kubelet API | kubelet 自动轮换（默认 1 年） |
| kube-controller-manager 证书 | controller-manager | 与 API Server 通信，签署 ServiceAccount 令牌 | 手动更新 |
| kube-scheduler 证书 | scheduler | 与 API Server 通信，执行调度决策 | 手动更新 |
关键认知： 在证书轮换故障场景中，kubelet 证书 是最容易引发 Pod 调度失败的环节。当 kubelet 证书过期或与 API Server 信任链断裂时，节点状态会变为
NotReady，调度器将自动跳过该节点。
2.2 集群 CA 证书：信任的根
集群 CA 是一对自签名的根证书和私钥，通常部署在控制面节点上。它的职责包括：
- 签发所有组件证书：API Server、kubelet、controller-manager、scheduler 的证书都由 CA 签署。
- 验证对端身份：当 kubelet 向 API Server 发起请求时，API Server 使用 CA 证书验证 kubelet 证书的合法性。
- 定义集群边界：只有持有由该 CA 签发的证书的组件，才被认为是集群的合法成员。
CA 证书文件通常位于 /etc/kubernetes/pki/ca.crt，私钥位于 /etc/kubernetes/pki/ca.key。CA 私钥是集群中最高敏感度的资产，一旦泄露，攻击者可以伪造任意组件身份。
2.3 API Server 证书：集群的入口
API Server 证书是集群对外暴露的 HTTPS 端点所使用的证书。它的核心作用包括：
- 加密客户端通信：kubectl、kubelet、scheduler、controller-manager 都通过 HTTPS 与 API Server 通信，证书保证传输加密。
- 服务端身份验证：客户端（如 kubelet）通过验证 API Server 证书的 CN（Common Name）和 SAN（Subject Alternative Name）来确认连接的是合法的 API Server。
- 客户端证书验证：API Server 在收到请求时，会使用 CA 证书验证客户端证书的有效性，实现双向 TLS。
API Server 证书的 SAN 字段必须包含所有可能的访问地址，包括：
# 典型的 API Server 证书 SAN 列表
- 127.0.0.1
- 10.96.0.1（Service ClusterIP）
- kubernetes
- kubernetes.default
- kubernetes.default.svc
- kubernetes.default.svc.cluster.local
- <master-node-ip>
- <load-balancer-ip>
常见故障点： 当 API Server 证书的 SAN 缺少某个节点 IP 时，kubelet 将无法通过证书验证，导致节点注册失败。这是证书轮换脚本中容易遗漏的配置项。
2.4 kubelet 证书：节点的身份凭证
每个 Kubernetes 节点上的 kubelet 都持有一张由集群 CA 签发的客户端证书。这张证书的作用至关重要：
- 节点注册与身份认证：kubelet 启动时使用该证书向 API Server 注册节点，API Server 通过验证证书中的 CN 字段（通常为
system:node:<node-name>）来确认节点身份。 - kubelet API 服务：kubelet 也对外提供 HTTPS API（默认端口 10250），用于 kubectl exec/logs/attach 等操作，该端点同样使用 kubelet 证书。
- 自动轮换机制：Kubernetes 1.8+ 支持 kubelet 证书自动轮换。kubelet 会在证书到期前向 API Server 发起 CSR（CertificateSigningRequest），由 controller-manager 自动签署新证书。
kubelet 证书的默认有效期通常为 1 年，自动轮换会在到期前 30 天开始尝试。轮换流程如下：
- kubelet 检测到当前证书即将过期。
- kubelet 生成新的私钥和 CSR。
- kubelet 使用当前有效证书向 API Server 提交 CSR 请求。
- controller-manager 中的
csrapproving控制器验证 CSR 合法性后自动批准。 - kubelet 下载新证书并替换旧证书。
2.5 证书信任链与通信流程
下图展示了 kubelet 与 API Server 之间的双向 TLS 握手过程，以及证书在其中的角色：
2.6 证书轮换的常见故障模式
在证书轮换过程中，以下故障模式会直接导致 Pod 调度失败：
| 故障场景 | 根因 | 典型现象 | 影响范围 |
|---|---|---|---|
| kubelet 证书过期 | 自动轮换失败（CSR 被拒绝、controller-manager 未启动） | 节点状态 NotReady，kubelet 日志报 x509 证书过期 | 单个节点 |
| CA 证书更换 | 集群 CA 被替换，但 kubelet 仍使用旧 CA 验证 | 所有节点同时 NotReady，kubelet 报未知 CA | 整个集群 |
| API Server 证书 SAN 缺失 | 证书轮换脚本未包含所有节点 IP | 部分节点无法注册，kubelet 报证书名称不匹配 | 部分节点 |
| kubelet 证书 CN 错误 | CSR 中的 CN 与节点名不一致 | 节点注册被拒绝，API Server 返回 401 | 单个节点 |
排查要点： 当遇到 Pod 调度失败时，首先检查节点状态：
kubectl get nodes。如果节点状态为 NotReady，立即查看 kubelet 日志：journalctl -u kubelet -n 100 --no-pager | grep -i cert。证书相关的错误通常包含 x509、certificate has expired 或 unknown authority 等关键词。
2.7 证书文件路径速查
在排查证书问题时，快速定位证书文件位置至关重要。以下是 kubeadm 部署集群的默认路径：
# 控制面节点
/etc/kubernetes/pki/
├── ca.crt # 集群 CA 证书（公钥）
├── ca.key # 集群 CA 私钥（⚠️ 最高机密）
├── apiserver.crt # API Server 证书
├── apiserver.key # API Server 私钥
├── apiserver-kubelet-client.crt # API Server 访问 kubelet 的客户端证书
├── apiserver-kubelet-client.key
├── front-proxy-ca.crt # 聚合层 CA 证书
├── front-proxy-client.crt # 聚合层客户端证书
└── etcd/
├── ca.crt # etcd CA 证书
├── server.crt # etcd 服务端证书
└── peer.crt # etcd 对等证书
# 工作节点
/var/lib/kubelet/pki/
├── kubelet.crt # kubelet 证书（自动轮换）
├── kubelet.key # kubelet 私钥
└── kubelet-client-current.pem # kubelet 客户端证书（用于访问 API Server）