📚 课程目录第3章 Kubernetes 集群升级策略

3、Kubernetes 集群升级策略：升级路径规划、版本兼容性矩阵、节点池滚动升级策略

Kubernetes 集群升级是运维中最关键也最易出错的操作之一。在租户隔离蓝图环境中，升级不仅影响控制面稳定性，还直接关系到多租户工作负载的可用性。本章围绕升级路径规划、版本兼容性矩阵和节点池滚动升级策略三个核心维度，提供可落地的操作指南。

3.1 升级路径规划：从 N-3 到 N 的安全跳跃

Kubernetes 社区官方支持从 N-3 版本升级到 N 版本（即跳过最多两个次要版本）。但在生产环境中，尤其是承载多租户工作负载的集群，建议遵循“逐次升级、每步验证”的原则。

  升级路径推荐原则：
  逐次升级：每次只升级一个次要版本（如 1.27 → 1.28 → 1.29），避免跨多个版本升级带来的 API 兼容性风险。
补丁版本对齐：在升级次要版本前，先将当前版本升级到该次要版本的最新补丁版本（如 1.27.10 → 1.28.5），确保包含所有安全修复。
租户隔离验证：每完成一次控制面升级，先验证租户隔离策略（NetworkPolicy、PodSecurity、ResourceQuota）是否正常生效，再升级节点池。

以下是一个典型的升级路径规划表示例：

当前版本	目标版本	跳跃步数	推荐路径	风险等级
1.25.x	1.28.x	3	1.25 → 1.26 → 1.27 → 1.28	高（需逐次升级）
1.26.x	1.28.x	2	1.26 → 1.27 → 1.28	中（建议逐次）
1.27.x	1.28.x	1	1.27 → 1.28	低（标准升级）
1.28.x	1.28.y	0	1.28.x → 1.28.y	极低（补丁升级）

实践建议：在租户隔离蓝图环境中，建议将控制面升级与节点池升级解耦。先升级控制面，等待至少 24 小时观察期，确认所有准入控制插件（如 OPA Gatekeeper、Kyverno）正常工作后，再启动节点池滚动升级。

3.2 版本兼容性矩阵：API 变更与准入控制影响

每次 Kubernetes 次要版本升级都可能引入 API 资源版本的废弃或移除。对于依赖准入控制 Webhook 的租户隔离环境，必须提前检查版本兼容性。

以下是与租户隔离相关的关键 API 版本兼容性矩阵（以 1.25 → 1.28 为例）：

API 资源	1.25 可用版本	1.26 变更	1.27 变更	1.28 可用版本	准入控制影响
PodSecurityPolicy	policy/v1beta1	已移除	—	不可用	需迁移至 Pod Security Admission
NetworkPolicy	networking.k8s.io/v1	稳定	稳定	networking.k8s.io/v1	无影响
Ingress	networking.k8s.io/v1	networking.k8s.io/v1beta1 移除	稳定	networking.k8s.io/v1	需更新 Ingress 资源清单
ValidatingWebhookConfiguration	admissionregistration.k8s.io/v1	稳定	稳定	admissionregistration.k8s.io/v1	无影响，但需检查 Webhook 证书
CustomResourceDefinition	apiextensions.k8s.io/v1	v1beta1 移除	稳定	apiextensions.k8s.io/v1	需确保 CRD 使用 v1 版本

关键风险提示：如果租户隔离依赖 PodSecurityPolicy（PSP），必须在升级到 1.25 之前完成向 Pod Security Admission（PSA）的迁移。PSP 在 1.25 中被彻底移除，升级后所有 PSP 规则将失效，导致租户隔离策略出现空白窗口。

版本兼容性检查流程：

使用 kubectl convert 命令检查现有资源清单的 API 版本。
运行 kube-apiserver --audit-log-path 审计日志，识别使用已废弃 API 的客户端。
使用 kubectl get --raw /openapi/v2 对比目标版本的 API 清单。
在测试集群中部署准入控制 Webhook，验证目标版本下的 Webhook 调用是否正常。

3.3 节点池滚动升级策略：零停机与租户隔离保障

节点池滚动升级是集群升级中最影响工作负载的阶段。在租户隔离蓝图环境中，需要确保升级过程中租户工作负载不中断，且隔离策略持续生效。

以下是一个标准的节点池滚动升级策略配置：

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: tenant-node-pool
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 允许额外创建 1 个节点
      maxUnavailable: 0    # 确保始终有 100% 节点可用
  template:
    spec:
      version: v1.28.5     # 目标 Kubelet 版本
      taints:
      - key: "tenant-isolation"
        value: "true"
        effect: "NoSchedule"

  滚动升级关键参数说明：
  maxSurge: 1 — 允许在升级过程中额外创建一个新节点，加速升级过程。
maxUnavailable: 0 — 保证任何时候都有全部节点可用，适用于生产环境。
节点排空（Drain）：在升级前自动执行 kubectl drain，驱逐租户 Pod 到其他节点。
PodDisruptionBudget（PDB）：租户应为其关键工作负载设置 PDB，确保驱逐时最少可用 Pod 数量。

下图展示了节点池滚动升级的完整流程：

3.4 升级前检查清单与回滚预案

在租户隔离蓝图环境中，升级前检查清单是保障升级安全的关键。以下是最小化检查项：

检查类别	检查项	验证方法	优先级
控制面	etcd 备份	确认 etcd 快照文件存在且可恢复	P0
控制面	API 版本兼容性	运行 `kubectl convert` 扫描所有资源	P0
准入控制	Webhook 证书有效性	检查证书过期时间，确认 CA 信任链	P0
准入控制	Webhook 规则兼容性	在测试集群中验证目标版本下的 Webhook 调用	P1
租户隔离	NetworkPolicy 生效状态	使用 `kubectl describe networkpolicy` 检查	P1
租户隔离	ResourceQuota 限制	确认配额未因 API 变更而丢失	P1
节点池	PDB 配置	检查所有命名空间的 PDB 是否覆盖关键工作负载	P0
节点池	节点健康状态	确认所有节点处于 Ready 状态	P0

回滚预案：如果升级过程中发现租户隔离策略失效或 Webhook 调用异常，立即停止滚动升级。回滚步骤：1) 使用 etcd 快照恢复控制面；2) 将节点池镜像回滚到上一个版本；3) 重新验证所有准入控制插件。建议在升级前录制 etcd 快照并保存至少 7 天。

3.5 升级后验证：租户隔离完整性检查

升级完成后，必须执行租户隔离完整性验证，确保升级未引入安全漏洞或策略绕过。以下是最小化验证步骤：

控制面验证：检查所有控制面组件版本，确认 kube-apiserver、kube-controller-manager、kube-scheduler 版本一致。
准入控制验证：模拟创建违反租户隔离策略的 Pod，确认 Webhook 正确拒绝。
网络隔离验证：在不同租户的 Pod 之间执行网络连通性测试，确认 NetworkPolicy 生效。
资源配额验证：尝试创建超过 ResourceQuota 限制的资源，确认配额限制生效。
审计日志验证：检查审计日志中是否有异常 API 调用或权限提升事件。

自动化验证建议：将上述验证步骤编写为 bash 或 Python 脚本，集成到 CI/CD 流水线中。每次升级后自动执行，生成验证报告。推荐使用 conftest 或 kube-bench 进行策略合规性检查。