Kubernetes 证书体系基础：API Server、kubelet、etcd 之间的 TLS 通信与证书作用

在 Kubernetes 集群中，API Server、kubelet 和 etcd 是三个核心组件，它们之间的通信必须经过双向 TLS（mTLS）加密，以确保集群的控制面安全。证书轮换一旦出错，轻则导致组件间认证失败，重则引发控制器无法同步副本数，最终表现为 Deployment 副本数异常。理解这三者之间的证书关系，是定位此类故障的前提。

3.1 核心组件与通信链路

Kubernetes 控制面由以下关键组件构成，它们之间的 TLS 链路可归纳为三条：

3.2 证书类型与作用

Kubernetes 使用 PKI（公钥基础设施）体系，每个组件持有不同的证书对。下表列出了与副本数异常排查最相关的证书：

3.3 TLS 握手与证书验证流程

以 API Server → etcd 链路为例，证书验证过程如下：

1. API Server 作为客户端，向 etcd 发起 TLS 连接请求。
2. etcd 出示其服务端证书 etcd-server.crt，并附带证书链。
3. API Server 使用本地 ca.crt 验证 etcd 服务端证书的签名、有效期、CN（Common Name）。
4. API Server 出示其客户端证书 etcd-client.crt，证明自己的身份。
5. etcd 使用本地 ca.crt 验证 API Server 客户端证书的有效性。
6. 双向验证通过后，建立加密通信通道。

3.4 证书体系架构图

下图展示了 API Server、kubelet、etcd 之间的证书分发与信任关系：

3.5 证书轮换对副本数的影响路径

当证书轮换出现问题时，故障传递路径如下：

• etcd 证书过期 → API Server 无法连接 etcd → 无法读取/写入 /registry/deployments 等关键路径 → Deployment Controller 无法同步期望副本数。
• kubelet 服务端证书过期 → API Server 无法访问 kubelet 的 /pods 端点 → 节点状态异常 → 控制器将 Pod 标记为 Unknown → 触发 unhealthyPodEvictionPolicy 导致副本数波动。
• API Server 服务端证书过期 → 所有客户端（kubectl、控制器、kubelet）无法连接 API Server → 整个控制面瘫痪，副本数无法更新。

3.6 证书轮换的典型操作流程

以手动轮换 API Server 证书为例，标准步骤包括：

1. 生成新的私钥和证书签名请求（CSR）。
2. 使用集群 CA 签发新证书。
3. 将新证书分发到所有控制面节点的 /etc/kubernetes/pki/ 目录。
4. 重启 API Server 静态 Pod（或 kubelet 服务）。
5. 验证 API Server 与 etcd、kubelet 的 TLS 握手是否正常。
6. 监控 Deployment 副本数是否恢复稳定。