4. 集群生命周期管理：节点上线、节点下线、版本升级、版本回滚的核心流程
集群生命周期管理是运维治理的核心环节，涵盖节点与集群版本两个维度的变更。节点上线/下线解决容量伸缩与故障隔离，版本升级/回滚解决功能迭代与风险兜底。以下从四个核心流程展开，并给出基于 CRI 校验的治理要点。
4.1 节点上线流程
节点上线指将一台新计算节点（或修复后的节点）安全加入集群，使其承载 Pod。流程分为前置校验、加入集群、后置验证三个阶段。
| 阶段 | 操作步骤 | CRI 校验要点 |
|---|---|---|
| 前置校验 |
|
运行时版本 ≥ 集群最低要求；crictl ps 无异常 |
| 加入集群 |
|
kubelet 与 CRI 握手成功；Pod Sandbox 创建正常 |
| 后置验证 |
|
CRI 日志无 ErrImagePull 或 RunPodSandbox 失败 |
治理建议：节点上线应纳入变更审批流程，前置校验脚本需包含 CRI 运行时完整性校验（如
crictl images 检查基础镜像是否存在），避免因运行时缺失导致调度失败。
4.2 节点下线流程
节点下线用于缩容、硬件维护或节点退役。核心原则是先排空、再下线，确保工作负载平滑迁移。
- 节点封锁（kubectl cordon）：标记节点为不可调度，阻止新 Pod 调度上来。
- Pod 驱逐（kubectl drain）：逐出节点上所有 Pod（DaemonSet 除外），触发重新调度。
- CRI 运行时清理：停止容器、清理挂载卷、删除残留镜像。
- 节点移除（kubectl delete node）：从集群 API Server 中删除节点对象。
- 物理/虚机关机：确认无残留进程后关闭实例。
风险提示：驱逐前必须确认 PodDisruptionBudget（PDB）允许驱逐，否则可能导致服务中断。CRI 层面需检查是否有
PodSandbox 残留，避免泄漏。
4.3 版本升级流程
集群版本升级遵循控制面优先、节点逐批的原则。以 Kubernetes 1.28 → 1.29 为例，核心流程如下：
| 步骤 | 操作对象 | 关键命令 / 校验 |
|---|---|---|
| 1. 前置检查 | 集群全局 | kubectl version --short；检查 API 弃用清单；CRI 运行时兼容性矩阵 |
| 2. 升级控制面 | Master 节点 | kubeadm upgrade plan → kubeadm upgrade apply v1.29.0 |
| 3. 升级节点 kubelet | Worker 节点 | kubeadm upgrade node；重启 kubelet；crictl version 确认运行时版本 |
| 4. 升级 CRI 运行时 | 所有节点 | containerd / CRI-O 二进制替换；systemctl restart containerd |
| 5. 后置验证 | 集群全局 | 节点状态 Ready；核心组件健康；crictl pods 无异常 |
CRI 校验关键点：升级前必须确认新版本 CRI 运行时与 kubelet 的 API 版本兼容。例如 containerd 1.7+ 支持 CRI v1alpha2 和 v1，而 Kubernetes 1.29 已移除 v1alpha2，需提前切换。
4.4 版本回滚流程
回滚是升级失败或引入严重缺陷时的兜底手段。回滚策略分为原地回滚和快照重建两种。
| 回滚方式 | 适用场景 | 操作步骤 | CRI 校验 |
|---|---|---|---|
| 原地回滚 | 仅 kubelet / 运行时版本回退 |
|
crictl version 与回滚目标一致；Pod Sandbox 重建成功 |
| 快照重建 | 控制面组件升级失败 / etcd 数据损坏 |
|
CRI 运行时版本与 etcd 快照创建时一致；镜像缓存可用 |
回滚红线：回滚前必须确认 CRI 运行时版本与回滚目标集群版本兼容。例如从 containerd 2.0 回退到 1.6 时，需检查
cri-api 版本差异，否则 kubelet 无法连接。
4.5 核心流程总览（SVG）
下图将节点上线、节点下线、版本升级、版本回滚四个流程整合为一张生命周期状态机，突出 CRI 校验在每一步的嵌入位置。
4.6 流程对比与治理要点
| 维度 | 节点上线 | 节点下线 | 版本升级 | 版本回滚 |
|---|---|---|---|---|
| 触发条件 | 扩容 / 故障恢复 | 缩容 / 维护 / 退役 | 功能迭代 / 安全补丁 | 升级失败 / 兼容性问题 |
| 影响范围 | 单节点 | 单节点（需排空） | 全集群 | 全集群 |
| CRI 校验频率 | 高（每次上线） | 中（清理阶段） | 高（每节点升级前后） | 高（回滚前后） |
| 回退能力 | 节点下线即可回退 | 重新上线 | 版本回滚 | 再次升级 |
| 发布包完整性要求 | 节点初始化包校验 | 清理脚本完整性 | 升级包 SHA256 校验 | 回滚包版本一致性 |
治理最佳实践：将四个流程封装为自动化 Pipeline（如 Ansible / Terraform + CRI 校验脚本），每次变更前自动执行
crictl info 与 crictl version 快照，变更后对比快照差异，确保运行时状态可审计、可回放。