1. 课程导入与证书治理全景

在容器与 Kubernetes 的世界里，证书不是“配一次就忘”的附属品，而是整个集群身份与信任体系的骨架。kube-apiserver 对外提供 HTTPS 服务，kubelet 向 apiserver 证明自己的身份，etcd 节点之间互相校验，控制器与调度器通过客户端证书访问 API，Webhook、Ingress、Service Mesh 又各自携带一层 TLS。可以说，Kubernetes 的每一次“可信通信”，背后都站着一张证书。一旦证书过期、签发链断裂或私钥泄露，集群可能瞬间从“可用”变成“不可管理”。本课程的目标，就是把这套分散在各处的证书资产，从“被动救火”变成“可观测、可轮换、可审计”的治理体系。

一、证书治理要解决什么问题

先看一个真实感很强的场景：某集群运行满一年后，管理员发现 kubectl 突然报 x509: certificate has expired or is not yet valid，同时 kubelet 全部 NotReady。排查后发现是 apiserver 的服务端证书到期，而 kubelet 的客户端证书也同期过期。更棘手的是，etcd 的 peer 证书由另一套 CA 签发，轮换窗口与 apiserver 不一致。这类故障的根因往往不是“不会签证书”，而是缺少一张全局的证书地图：谁签发了谁、有效期多长、到期前谁负责轮换、轮换时哪些组件需要重启。

因此，证书治理的核心目标可以归纳为四条：身份可信（每个组件都有明确的身份证书）、生命周期可控（签发、续期、吊销、轮换有流程）、状态可观测（剩余有效期、签发者、用途可查询）、变更可审计（谁在何时改了哪张证书）。范围上，它覆盖控制平面证书、kubelet 证书、etcd 证书、聚合层与 Webhook 证书、Ingress/网关证书，以及 ServiceAccount 的 token 签名密钥体系。

二、整体框架：从信任根到工作负载

Kubernetes 的证书体系本质上是一棵信任树。根 CA 是信任锚点，中间 CA 或直接由根 CA 签发各组件证书。下图展示了从信任根到工作负载的证书分布与关键关系，也是本课程后续章节反复引用的“全景地图”。

这张图里，根 CA 是唯一的信任锚，向下分出控制平面 CA、etcd CA、kubelet CA 三条主要分支。每条分支下挂载具体组件证书，底部则是贯穿所有分支的治理动作与关键指标。右侧三个风险点提示了治理中最容易出问题的环节：CA 私钥泄露、轮换不同步、过期无告警。后续章节会逐一展开这些分支的签发细节、轮换策略与监控方法。

三、核心挑战：为什么证书治理比想象中难

第一，证书分散且签发者不统一。用 kubeadm 部署的集群，控制平面证书默认由 /etc/kubernetes/pki/ca.crt 签发，etcd 证书却可能来自独立的 etcd CA；kubelet 证书又可能由 apiserver 的 CSR API 动态签发。三套 CA、三种轮换方式，很容易在变更时漏掉某一环。

第二，有效期与轮换窗口不一致。kubeadm 默认 CA 有效期 10 年，组件证书 1 年，kubelet 证书默认 1 年但可通过 rotateCertificates 自动轮换。如果只盯着 apiserver 证书，忽略 kubelet 的自动轮换是否真正生效，一年后仍会集体掉线。

第三，轮换操作具有破坏性。替换 apiserver 证书需要重启静态 Pod；替换 etcd peer 证书需要逐节点滚动；替换 kubelet 证书需要重启 kubelet。任何一步顺序错误，都可能造成控制平面短暂不可用。因此治理方案必须包含回滚路径和分批窗口。

第四，可观测性不足。证书剩余有效期不会自动出现在 Prometheus 指标里，除非显式采集。很多团队直到 kubectl 报错才发现问题，此时已经进入故障状态。

四、学习路径与课程结构

本课程按“认知—工具—实操—治理”四层推进。前几章先建立证书地图与 OpenSSL 基础，理解 X.509 字段、SAN、密钥用途；随后进入 kubeadm 证书体系、etcd 证书、kubelet 证书与 CSR API；再覆盖 Ingress、Webhook、ServiceAccount 签名密钥等外围证书；最后落到监控告警、自动化轮换、审计与故障演练。每一章都会给出可执行的命令、配置片段或检查清单，而不是停留在概念层面。