2. Kubernetes 版本策略：版本号规则、版本偏差策略与组件升级顺序
Kubernetes 版本策略是集群升级的基石。理解版本号语义、组件间的兼容性偏差以及正确的升级顺序，是确保 Deployment 在升级过程中保持稳定可用的前提。本节将系统梳理这三个核心维度。
2.1 版本号规则：从 Alpha 到 GA 的演进路径
Kubernetes 遵循 语义化版本控制（SemVer），版本号格式为 vMAJOR.MINOR.PATCH。每个组件或 API 资源在发布前，会经历 Alpha → Beta → GA（Stable）三个阶段。
| 阶段 | 版本标识 | 默认启用 | 生产可用 | API 兼容性保证 |
|---|---|---|---|---|
| Alpha | v1alpha1 |
否 | 否 | 无；随时可能删除或变更 |
| Beta | v1beta1 |
是 | 谨慎使用 | 有限；可能向后兼容，但需关注弃用通知 |
| GA (Stable) | v1 |
是 | 是 | 完整；多个大版本内保持兼容 |
升级建议： 在集群升级前，务必检查 Deployment 使用的所有 API 资源版本。如果使用了
v1beta1 或 v1alpha1 版本的资源（如旧版 extensions/v1beta1 的 Deployment），必须提前迁移至对应的 apps/v1 GA 版本，否则升级后 API 将被移除，导致资源无法管理。
版本号中的 PATCH 版本（如 v1.28.3 → v1.28.4）仅包含安全修复和 bug 修复，不涉及 API 变更，是风险最低的升级类型。MINOR 版本（如 v1.27 → v1.28）引入新特性，可能包含 API 弃用或行为变更，是升级策略关注的重点。MAJOR 版本（目前 Kubernetes 无 MAJOR 版本变更）理论上允许不兼容的 API 变更。
关键指标： 每个 MINOR 版本发布后，Kubernetes 社区会提供约 12 个月的补丁支持。建议始终使用最新的 PATCH 版本，并确保在 MINOR 版本 EOL（End of Life）前完成升级。
2.2 版本偏差策略：组件间的兼容性约束
Kubernetes 集群由多个组件组成（kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy 等）。升级时，这些组件可以处于不同的版本，但必须遵循严格的偏差策略。
常见陷阱： 升级 kubelet 时，如果跳过两个 MINOR 版本（例如从 v1.25 直接升级到 v1.28），kubelet 将无法与 v1.28 的 kube-apiserver 通信，导致节点状态异常。必须遵循 n-2 偏差限制，分步升级。
2.3 组件升级顺序：控制平面优先，节点随后
正确的升级顺序是集群稳定性的保障。核心原则是：先升级控制平面，再升级节点组件。具体步骤如下：
- 升级 kube-apiserver：作为集群的入口和状态存储，必须最先升级。升级后，旧的 kubelet 和控制器仍可正常工作（在偏差策略范围内）。
- 升级其他控制平面组件：依次升级 kube-controller-manager、kube-scheduler、cloud-controller-manager（如果使用）。这些组件可以分批重启，不影响集群核心功能。
- 升级节点组件：逐节点或按节点池升级 kubelet 和 kube-proxy。建议采用 滚动升级 策略，确保 Deployment 的 Pod 在节点间平滑迁移。
- 升级集群附加组件：最后升级 CoreDNS、kube-dns、网络插件（CNI）、Ingress Controller 等。这些组件通常依赖新的 API 版本。
最佳实践： 在升级每个节点前，先执行
kubectl drain <node-name> --ignore-daemonsets 驱逐 Pod，确保 Deployment 的 Pod 在其他节点上重建。升级完成后，执行 kubectl uncordon <node-name> 恢复调度。对于 Deployment，建议设置 podAntiAffinity 和 PodDisruptionBudget，以控制同时中断的 Pod 数量。