1. 课程导论：K8s证书轮换的背景与挑战，为什么需要节点准入控制
1.1 证书轮换：Kubernetes 集群安全的生命线
在 Kubernetes 集群中，证书（TLS 证书）是组件间身份认证与通信加密的基石。kube-apiserver、kubelet、kube-controller-manager、kube-scheduler 以及 etcd 之间的所有安全通信，均依赖 X.509 证书进行双向 TLS 握手。Kubernetes 默认签发的证书有效期通常为 1 年，部分自建集群甚至更短。
证书一旦过期，将直接导致以下严重后果：
- API Server 拒绝连接：kubelet 无法向 apiserver 注册节点状态，Pod 调度失败。
- kubelet 与 apiserver 通信中断：kubectl logs、exec、attach 等操作失效。
- etcd 集群脑裂或不可用：etcd 成员证书过期导致集群分裂。
- 集群完全瘫痪：控制平面组件相互认证失败，集群进入“只读”或“不可用”状态。
行业数据：根据 CNCF 2024 年调查，证书过期是导致 Kubernetes 生产集群意外宕机的 Top 3 原因之一，占比超过 23%。
1.2 证书轮换的核心挑战
Kubernetes 社区提供了 kubeadm certs renew 等手动轮换工具，但在大规模生产环境中，证书轮换面临以下 四大挑战：
| 挑战维度 | 具体问题 | 典型后果 |
|---|---|---|
| 规模 | 集群节点数超过 1000，手动逐台轮换不可行 | 轮换周期过长，部分节点证书过期 |
| 一致性 | 证书签发时间、序列号、SAN 字段必须严格一致 | 节点间证书不匹配，导致 TLS 握手失败 |
| 安全性 | 轮换期间私钥泄露、中间人攻击风险 | 集群被未授权节点接入 |
| 自动化 | 缺乏可靠的自动化准入控制机制 | 轮换作业与业务 Pod 调度冲突 |
1.3 为什么需要节点准入控制？
传统的证书轮换方案（如 CronJob + 脚本）存在一个根本缺陷：轮换作业与节点调度之间缺乏协调机制。当证书轮换 Pod 被调度到某个节点时，该节点可能正在运行关键业务负载，轮换操作（如重启 kubelet、更新证书文件）会直接中断业务。
节点准入控制（Node Admission Control） 正是为了解决这一矛盾而设计。其核心思想是：在证书轮换作业被调度到节点之前，先通过污点（Taint）和容忍（Toleration）策略，判断该节点是否处于“可轮换”状态。
核心价值：节点准入控制将证书轮换从“被动修复”转变为“主动编排”，确保轮换作业只在 安全窗口 内执行，不影响业务 Pod 的可用性。
1.4 证书轮换与节点准入的关系图
1.5 本课程的核心目标
通过本课程，你将掌握以下能力：
- 理解 K8s 证书体系：掌握证书类型、签发机制、过期检测方法。
- 设计污点容忍策略：使用
node.kubernetes.io/cert-rotation等自定义污点，标记节点的轮换状态。 - 实现节点准入控制：通过 Admission Webhook 或调度器策略，控制证书轮换作业的调度时机。
- 构建自动化轮换流水线：结合 Operator 模式，实现零停机证书轮换。
前置要求：本课程假设你已具备 Kubernetes 集群管理基础，熟悉
kubectl taint、kubectl cordon、kubectl drain 等基本操作，并了解 TLS 证书的基本原理。
1.6 课程知识图谱
1.7 本章小结
证书轮换是 Kubernetes 集群运维中不可回避的刚性需求。传统的轮换方式在规模、一致性、安全性和自动化方面存在明显短板。节点准入控制通过污点容忍策略，为证书轮换作业提供了 安全调度屏障，确保轮换操作只在节点处于“可接受中断”状态时执行，从而保障业务 Pod 的持续可用性。