2. K8s证书体系概述：K8s内部证书类型与生命周期管理

Kubernetes 集群的安全通信完全建立在 双向 TLS（mTLS） 之上。集群内每个组件（etcd、kube-apiserver、kubelet、kube-controller-manager、kube-scheduler）都持有由集群根 CA 签发的数字证书，用于身份验证和通信加密。理解这些证书的类型、用途及生命周期，是实现零停机证书轮换的理论基础。

2.1 核心证书类型与用途

K8s 集群主要包含以下三类核心证书，它们分别服务于不同的通信链路：

2.2 证书生命周期管理

K8s 证书的生命周期包含四个阶段：签发 → 分发 → 使用 → 轮换。每个阶段都可能成为零停机部署的瓶颈。

2.2.1 证书签发与有效期

• 自签发 vs CA 签发： 生产环境强烈建议使用独立的集群根 CA（Certificate Authority）统一签发所有组件证书，而非自签名证书。CA 签发的证书便于集中管理和吊销。
• 默认有效期： kubeadm 部署的集群默认证书有效期为 1 年（365 天）。etcd 证书通常为 5 年或 10 年，但建议统一缩短至 1 年以降低泄露风险。
• 证书续期触发条件： 当证书剩余有效期低于阈值（如 30 天）时，必须启动轮换流程。K8s 1.21+ 支持 kubelet --rotate-certificates 自动轮换 kubelet 证书，但 apiserver 和 etcd 证书仍需手动或借助工具（如 cert-manager）处理。

2.2.2 证书分发与挂载

证书文件通常以 Secret 或 ConfigMap 形式挂载到 Pod 中。对于静态 Pod（如 kube-apiserver、etcd），证书直接存放在宿主机文件系统路径下（如 /etc/kubernetes/pki/）。

# 典型证书文件结构（kubeadm 部署）
/etc/kubernetes/pki/
├── apiserver.crt
├── apiserver.key
├── apiserver-kubelet-client.crt
├── apiserver-kubelet-client.key
├── ca.crt                  # 集群根 CA 证书
├── etcd/
│   ├── ca.crt
│   ├── server.crt
│   ├── server.key
│   ├── peer.crt
│   └── peer.key
└── front-proxy-ca.crt

2.3 证书轮换的核心挑战

证书轮换并非简单的文件替换。以下三个挑战直接决定了是否需要引入亲和性调度策略：

1. 连接中断： 替换证书后，已建立的 TLS 连接不会自动使用新证书。如果组件不支持动态证书重载（如 etcd 3.4 以下版本），必须重启进程，导致所有客户端连接中断。
2. 新旧证书共存： 在轮换窗口期内，部分组件可能持有旧证书，部分持有新证书。如果新旧 CA 不同，会导致跨组件认证失败。
3. 静态 Pod 重启： kube-apiserver 和 etcd 通常以静态 Pod 运行，替换证书后需要 kubelet 重新拉取 Pod 清单，这会导致短暂的 API 不可用。

2.4 证书体系架构图

下图展示了 K8s 集群内部各组件之间的证书依赖关系与通信链路：

2.5 证书轮换策略对比

针对不同组件，证书轮换策略存在显著差异。下表对比了三种主流轮换方式：

2.6 证书生命周期时间线

一个完整的证书生命周期管理流程如下：

1. 签发阶段： 使用集群 CA 签发新证书，设置有效期（建议 365 天）。
2. 分发阶段： 将新证书通过 Secret 或直接文件挂载到目标组件。
3. 生效阶段： 组件加载新证书（通过重启或动态重载）。
4. 共存阶段： 新旧证书同时存在于集群中，客户端需能同时信任两者。
5. 清理阶段： 确认所有组件已使用新证书后，吊销或删除旧证书。