集群升级
本节提供有关升级由 Cluster API 管理的 Kubernetes 集群的说明。
目录
升级概述Distribution Version 与 Kubernetes Version前提条件第 1 阶段：升级 Distribution Version（对齐扩展）使用 Web UI步骤 1：审查修改步骤 2：升级 Aligned Extensions升级后验证第 2 阶段：升级 Kubernetes Version跨版本升级准备步骤 1 — 将中间 Core 镜像预同步到 registry步骤 2 — 为预配机制准备中间 OS 镜像步骤 3 — 对每个中间版本应用平台特定操作步骤平台特定说明相关主题升级概述
Immutable Infrastructure 上的集群升级采用两个阶段的方法：
- 第 1 阶段：升级 Distribution Version（对齐扩展）
- 第 2 阶段：升级 Kubernetes Version
这种两阶段升级可确保在升级底层 Kubernetes 组件之前，所有集群扩展和插件都与新的平台版本兼容。
Distribution Version 与 Kubernetes Version
每个 Distribution Version 都对应一个特定的 Kubernetes 版本。升级 Distribution Version 会更新集群扩展，并可能启用新的 Kubernetes 版本。
前提条件
- 控制平面可达且运行正常
- 所有节点均处于 Ready 状态
- IP Pool 容量足以支持滚动更新
第 1 阶段：升级 Distribution Version（对齐扩展）
升级 Distribution Version 会更新集群的 Aligned Extensions（L3 和 L4 插件）。
使用 Web UI
导航：Clusters → Clusters → 选择集群 → Aligned Extensions 选项卡 → 单击 Upgrade
步骤 1：审查修改
⚠️ 所有修改都必须与技术支持一起审查，以确认应保留还是删除。未经确认的修改可能导致升级失败。
审查任何已检测到的、可能影响升级的修改。
操作：
- Acknowledge：确认审查并继续执行第 2 步
- Cancel：中止升级流程
步骤 2：升级 Aligned Extensions
版本信息：
- Current Version：集群当前的 Distribution Version
- Target Version：global 集群的 Distribution Version
插件影响评估：
对于影响为 Medium 和 High 的插件，请勾选 Acknowledge，以确认您已了解相关风险。
操作：
- Back：返回步骤 1 重新审查修改
- Start Upgrade：开始升级（仅在确认 Medium/High 影响后可用）
- Cancel：中止升级流程
升级后验证
Distribution Version 升级完成后：
- 集群的 Distribution Version 已更新
- 节点池的 Kubernetes 版本现在低于新 Distribution Version 所支持的版本
- 继续执行第 2 阶段以升级 Kubernetes
第 2 阶段：升级 Kubernetes Version
在升级 Distribution Version 之后，请升级每个 Node Pool 上的 Kubernetes。 各平台的第 2 阶段操作步骤请参阅对应的供应商指南。
请参阅平台特定指南：
跨版本升级准备
当目标 ACP Distribution Version 比集群当前版本高出一个以上的 Kubernetes minor 版本时，在开始第 2 阶段之前还需要额外准备。单 minor 升级可跳过本节。
在 Immutable Infrastructure 上，每个 Kubernetes minor 都固化到一个匹配的 OS 镜像中，并且每个 Kubernetes minor 都映射到 OS Support Matrix 中特定的 ACP 版本行。因此，Kubernetes 版本会一次前进一个 minor，逐步经过每个中间 ACP 行对应的 OS 镜像。ACP Core（Distribution Version）本身仍通过 Cluster Version Operator 直接升级到目标版本——只有 Kubernetes 版本会逐级经过中间 minor。
找出当前版本与目标版本之间的每一个 ACP minor，使用每一行中的最新 patch，并在开始第 2 阶段之前为每个中间版本完成以下预部署。
步骤 1 — 将中间 Core 镜像预同步到 registry
对于每个中间 ACP 版本，下载其 Core 包，并且只将其镜像同步到 registry。不要发起到中间版本的 Core 升级请求。
有关命令选项，请参见 同步升级制品。
这样会将中间版本的 CoreDNS、etcd 和 Kube-OVN chart 镜像放入 registry，以便分阶段的 Kubernetes 滚动升级在将 KubeadmControlPlane patch 到对应的 OS Support Matrix 行时能够拉取这些镜像。在离线环境中，如果缺少中间镜像，新控制平面组件将无法启动。
Aligned 插件不需要针对中间版本额外执行 violet push；它们会随着 Core 升级直接移动到目标版本，而每次中间 Kubernetes 跳转所使用的 Kube-OVN chart 已包含在上面的 Core 镜像同步中。
步骤 2 — 为预配机制准备中间 OS 镜像
对于每个中间 ACP 版本，使对应的 OS 镜像（即 OS Support Matrix 行中的 Alauda OS Image Version 值）可供节点预配机制使用，以便 Kubernetes 步骤可以依次用每个镜像替换节点：
- IaaS 提供商（Huawei DCS、VMware vSphere、Huawei Cloud Stack）：上传 OS 镜像，并按 OS Support Matrix 行中列出的精确名称将其注册为 VM template（或 VM image，具体取决于平台）。
- 裸金属：使 OS 镜像可供集群使用的节点重新预配流程访问。
随后，控制平面和工作节点的滚动升级会一次通过一个中间 OS 镜像，且与已预置的 Kubernetes minor 相匹配，直到集群达到目标 ACP 版本行。
步骤 3 — 对每个中间版本应用平台特定操作步骤
依次针对每个中间 ACP 版本重复执行平台特定的第 2 阶段操作步骤，并使用 OS Support Matrix 中该版本对应行的 KubeadmControlPlane 和 MachineDeployment 值。对于每一次跳转，在开始下一次跳转之前，先完成供应商的标准操作步骤——先控制平面，然后是工作节点，遵循 Kubernetes 版本偏差策略。所有中间跳转成功后，再对目标 ACP 版本执行一次相同的操作步骤。
平台特定说明
选择您的平台以查看详细的升级说明：