2. Kubernetes 集群升级基础：回顾K8s版本升级流程、控制平面与节点升级策略、kube-apiserver证书轮换触发条件
2.1 版本升级核心流程
Kubernetes 集群升级遵循严格的版本跳跃规则与组件顺序。升级路径必须满足 小版本号 ≤ 3 的跳跃限制，且控制平面组件必须优先于工作节点完成升级。
| 阶段 | 操作对象 | 关键动作 | 验证点 |
|---|---|---|---|
| 1. 前置检查 | 集群整体 | kubeadm version / kubectl version / etcdctl endpoint health | 所有组件版本一致，etcd 集群健康 |
| 2. 控制平面升级 | kube-apiserver / kube-controller-manager / kube-scheduler | kubeadm upgrade plan → kubeadm upgrade apply vX.Y.Z | apiserver 健康端点返回 200 |
| 3. 证书轮换 | kube-apiserver 证书 | 检查证书到期时间，触发自动轮换或手动更新 | openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text |
| 4. 节点升级 | kubelet / kube-proxy | kubeadm upgrade node → systemctl restart kubelet | 节点状态 Ready，Pod 重新调度完成 |
| 5. 后置验证 | 集群整体 | kubectl get nodes / kubectl get pods --all-namespaces | 所有组件版本符合预期，无异常 Pod |
升级路径检查： 使用
kubeadm upgrade plan 命令时，kubeadm 会自动校验当前版本与目标版本之间的跳跃数。如果跳跃超过 3 个小版本，必须分多次升级，例如 1.24 → 1.25 → 1.26 → 1.27。
2.2 控制平面与节点升级策略
控制平面升级采用 滚动升级 策略，多主节点集群需逐个节点升级，确保集群始终有可用的 apiserver 实例。工作节点升级则采用 节点池分批 策略，每批节点先执行 kubectl drain 驱逐 Pod，再升级 kubelet 和 kube-proxy，最后 kubectl uncordon 恢复调度。
升级顺序硬性要求：
- 先升级所有控制平面节点（主节点）。
- 再升级工作节点。
- 控制平面升级期间，工作节点上的 Pod 继续运行，但调度功能可能暂时受限。
- 工作节点升级时，必须逐台执行
drain → upgrade → uncordon三步操作。
2.3 kube-apiserver 证书轮换触发条件
kube-apiserver 证书轮换是集群升级过程中的关键环节。证书轮换的触发条件分为 自动触发 和 手动触发 两类。
| 触发类型 | 触发条件 | 轮换机制 | 适用场景 |
|---|---|---|---|
| 自动轮换 | 证书剩余有效期 < 30 天 | kube-controller-manager 中的 csr-approving controller 自动签发新证书 | kubelet 客户端证书、kube-proxy 客户端证书 |
| 自动轮换 | kubeadm upgrade apply 执行 | kubeadm 自动检查并更新所有控制平面证书 | 集群版本升级时 |
| 手动轮换 | 证书已过期或即将过期（< 7 天） | kubeadm certs renew all 或手动更新证书文件 | 证书过期紧急修复、证书被误删除 |
| 手动轮换 | 集群 CA 证书变更 | 重新签发所有组件证书，重启 kube-apiserver | CA 证书泄露、合规性要求 |
证书轮换风险提示： kube-apiserver 证书轮换后，所有依赖该证书的客户端（kubelet、kube-proxy、kubectl、聚合 API 扩展）必须重新加载新证书。如果 kube-proxy 未及时更新证书，将导致 Service 规则同步失败，引发网络连通性问题。这是本课程后续章节重点解决的场景。
2.4 证书轮换与 kube-proxy 规则迁移的关联
kube-apiserver 证书轮换直接影响 kube-proxy 的行为：
- 证书验证失败： kube-proxy 使用客户端证书连接 apiserver 监听 Service 和 Endpoint 变化。证书轮换后，旧证书被 apiserver 拒绝，kube-proxy 无法建立 watch 连接。
- 规则同步中断： 当 kube-proxy 与 apiserver 的连接断开后，iptables 或 IPVS 规则停留在轮换前的状态，新增 Service 无法访问，已删除 Service 的规则残留。
- 迁移测试必要性： 在证书轮换窗口内，必须验证 kube-proxy 能否自动加载新证书并重建 watch 连接，同时保证已有规则不丢失。
关键结论： 证书轮换不是简单的文件替换，它直接触发 kube-proxy 与 apiserver 之间的连接重建。如果 kube-proxy 的证书自动轮换机制未正确配置，或者证书文件路径错误，将导致 Service 规则迁移失败。本课程后续章节将详细演示如何通过
kubeadm certs renew 和 kubectl rollout restart 组合操作，实现零中断的规则迁移。