2. K8s PKI 基础：CA证书、服务端证书、客户端证书、kubeconfig文件中的证书结构
Kubernetes 集群的通信安全完全建立在 PKI（公钥基础设施）之上。理解 CA 证书、服务端证书、客户端证书以及 kubeconfig 文件中的证书结构，是进行证书轮换和节点通信兼容性排查的前提。本节将拆解这四类证书的职责、关系与存储形式。
2.1 四类证书的核心职责
K8s 使用双向 TLS（mTLS）进行组件间认证与加密。每一类证书在握手过程中扮演不同角色：
| 证书类型 | 签发对象 | 核心职责 | 典型文件 |
|---|---|---|---|
| CA 证书 | 集群根 CA | 签发所有其他证书，验证对端证书的合法性 | ca.crt |
| 服务端证书 | API Server、kubelet | 向客户端证明自身身份，加密通信 | apiserver.crt、kubelet.crt |
| 客户端证书 | kubelet、scheduler、controller-manager、kubectl | 向服务端证明自身身份，获取授权 | kubelet-client.crt、admin.crt |
| kubeconfig 证书 | 用户/组件 | 将客户端证书、CA 证书、私钥打包为可移植配置 | admin.conf、kubelet.conf |
关键认知： CA 证书是信任锚点。服务端证书和客户端证书都由同一个集群 CA 签发，但它们的
X.509 扩展属性（如 Extended Key Usage、Subject Alternative Name）不同，决定了各自的使用场景。
2.2 证书链与双向验证流程
下图展示了 K8s 组件间使用 mTLS 进行握手时，CA 证书、服务端证书和客户端证书的交互关系：
2.3 证书的 X.509 关键字段对比
服务端证书和客户端证书在 X.509 标准中的关键字段存在差异，这些差异决定了证书能否在特定场景下被接受：
| X.509 字段 | 服务端证书 | 客户端证书 | 说明 |
|---|---|---|---|
| Extended Key Usage (EKU) | serverAuth |
clientAuth |
必须匹配使用场景，否则 TLS 握手失败 |
| Subject Alternative Name (SAN) | 包含 DNS 名称、IP 地址 | 通常包含用户名或 UID | 服务端证书必须包含客户端访问的地址 |
| Common Name (CN) | 主机名或服务名 | 用户名或组件名 | K8s 1.20+ 中 CN 不再用于 RBAC 绑定 |
| Organization (O) | 通常为空或集群名 | 用户组（如 system:masters） |
用于 RBAC 授权判断 |
轮换兼容性陷阱： 如果新签发的服务端证书缺少旧客户端所期望的 SAN 条目（例如 kubelet 的 IP 地址），或者 EKU 字段被错误设置为
clientAuth，将导致节点间 TLS 握手失败。排查兼容性时，必须对比新旧证书的 SAN 和 EKU 字段。
2.4 kubeconfig 文件中的证书结构
kubeconfig 文件是 K8s 中分发证书和连接信息的标准格式。一个典型的 kubeconfig 文件包含三个核心段，其中两个直接涉及证书：
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority-data: <base64 编码的 CA 证书> # 信任锚点
server: https://192.168.1.100:6443
name: kubernetes
users:
- name: admin
user:
client-certificate-data: <base64 编码的客户端证书> # 身份凭证
client-key-data: <base64 编码的客户端私钥> # 私钥
contexts:
- context:
cluster: kubernetes
user: admin
name: default-context
current-context: default-context
kubeconfig 中的证书结构可以拆解为以下逻辑关系：
2.5 证书轮换时的兼容性检查清单
在进行证书轮换作业前，建议对照以下清单逐项检查新旧证书的兼容性：
- CA 一致性： 新证书是否由集群当前信任的 CA 签发？如果 CA 已轮换，kubeconfig 中是否包含新 CA？
- EKU 匹配： 服务端证书的 EKU 是否包含
serverAuth？客户端证书是否包含clientAuth？ - SAN 覆盖： 新服务端证书的 SAN 是否包含所有节点 IP、ClusterIP、DNS 名称？
- 密钥算法： 新旧证书是否使用相同的密钥算法（如 RSA 2048、ECDSA P256）？算法不匹配可能导致某些旧客户端无法加载。
- 有效期重叠： 轮换期间是否设置了新旧证书的有效期重叠窗口，避免因时间偏差导致验证失败？
实战建议： 在非生产环境先执行一次完整的证书轮换演练，使用
openssl x509 -text -noout 命令对比新旧证书的 EKU、SAN、Issuer 字段。确保所有 kubeconfig 文件中的 certificate-authority-data 与当前集群 CA 一致，这是节点通信兼容性的第一道防线。