2. Kubernetes 集群升级概述：版本演进策略、升级原则与风险分析

Kubernetes 版本迭代速度极快，社区通常每 3 个月发布一个次要版本（如 v1.28 → v1.29），每个版本仅支持约 12 个月。在生产环境中，集群升级不是简单的“点一下按钮”，而是一项涉及兼容性评估、灰度策略、回滚预案和风险控制的系统工程。本章从版本演进策略、升级原则和风险分析三个维度，建立集群升级的全局认知。

2.1 K8s 版本演进策略

Kubernetes 采用 语义化版本（SemVer）规范：vMAJOR.MINOR.PATCH。其中 MAJOR 版本极少变更（目前仍为 v1），MINOR 版本每季度发布一次，PATCH 版本按需发布（通常每月 1-2 次）。

版本演进的核心策略是 “小步快跑，持续跟进”：

• PATCH 版本：自动化升级，无需人工审批。
• MINOR 版本：每 2-3 个版本升级一次，避免跨度超过 2 个 MINOR。
• 版本锁定：生产环境固定 MINOR 版本，仅升级 PATCH。
• 预发布验证：在 staging 环境先升级，运行 48 小时压测。

2.2 升级三大原则：兼容性、灰度、可回滚

生产集群升级必须遵循三条铁律，缺一不可：

2.2.1 兼容性原则

• API 兼容性：Kubernetes 保证同一 MAJOR 版本内 API 向后兼容，但会在 MINOR 版本中逐步弃用（deprecate）旧 API。升级前必须使用 kubectl convert 或 kube-no-trouble 扫描旧 API 使用情况。
• 组件兼容性：kube-apiserver、kube-controller-manager、kube-scheduler 等核心组件必须遵循 n-2 规则（kubelet 版本可以比 apiserver 低 2 个 MINOR 版本）。
• 第三方插件兼容性：CNI、CSI、Ingress Controller、监控、日志等插件需提前确认支持目标版本。

# 检查集群中使用的 API 版本
kubectl get apiservice
# 扫描弃用 API
kubectl convert --validate -f manifests/
# 检查 kubelet 版本分布
kubectl get nodes -o wide

2.2.2 灰度原则

升级必须分批次、分节点池逐步推进，避免全集群同时升级导致大规模故障。灰度策略通常分为三层：

2.2.3 可回滚原则

升级前必须确保具备回滚能力，且回滚路径清晰：

• etcd 快照：升级前对 etcd 做全量快照，回滚时直接恢复。
• 节点快照：使用云厂商快照或 kubeadm 的 upgrade plan 记录当前状态。
• 回滚时间窗口：灰度阶段回滚窗口为 1 小时，全量阶段为 30 分钟。
• 自动化回滚：流水线中集成回滚触发器，当监控指标异常时自动执行回滚。

2.3 升级风险分析

集群升级过程中可能遇到的风险可分为四类，每类风险都需要对应的缓解措施：

2.4 升级路径规划示例

以一个从 v1.26 升级到 v1.28 的典型路径为例，展示完整的升级步骤与风险控制点：

# 1. 前置检查
kubectl version --short
kubectl get nodes -o wide
kubectl get apiservice
kubectl convert --validate -f manifests/

# 2. 备份 etcd
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db

# 3. 升级控制平面（灰度）
# 先升级一个 master 节点
kubeadm upgrade plan v1.28.0
kubeadm upgrade apply v1.28.0 --etcd-upgrade=false

# 4. 验证控制平面
kubectl get componentstatuses
kubectl get pods -n kube-system

# 5. 升级 worker 节点（分批）
kubeadm upgrade node
kubectl drain node-1 --ignore-daemonsets
kubectl uncordon node-1

# 6. 全量验证
kubectl run test-pod --image=nginx
kubectl get pods --all-namespaces