升级 global 集群
本文档介绍如何升级运行在不可变基础设施上的 global 集群。升级会使用由 Cluster API provider 管理的新 Alauda OS 镜像替换节点;不会使用原地节点升级。
目录
何时使用此路径两阶段升级概述通用前提条件操作步骤步骤 1 — 更新 global 集群 Manifest步骤 2 — 应用更新后的 Manifest步骤 3 — 监控滚动替换验证回滚注意事项后续步骤何时使用此路径
在以下情况下选择此升级路径:
global集群最初安装在不可变基础设施上。请参见 安装 global 集群。- 你的基础设施属于本文档所列出的 provider:Huawei DCS 或 Huawei Cloud Stack。VMware vSphere 和裸金属对
global集群的支持正在规划中。
对于传统 OS 的 global 集群,请改用 标准升级路径。
两阶段升级概述
与业务集群类似,运行在不可变基础设施上的 global 集群采用两阶段升级。
- 阶段 1 — Distribution Version:对齐和平台无关扩展会升级到目标 Distribution Version。该操作步骤与业务集群共享;有关阶段 1 的机制,请参见 升级集群。
- 阶段 2 — Kubernetes 和 OS 镜像:节点会被替换为包含目标 Kubernetes 版本的新 Alauda OS 镜像。本文档重点介绍
global集群的阶段 2。
在开始阶段 2 之前,请验证每个业务集群都位于目标 Distribution Version 的 Compatible Versions 矩阵范围内。超出范围的业务集群必须先升级。
通用前提条件
global集群已完成阶段 1(Distribution Version 升级)。- 已完成并验证
global集群的 etcd 备份。 - 新的 Alauda OS 镜像以及匹配的
KubeadmControlPlane和MachineDeployment版本已在平台的 registry 中可用。 - 已制定考虑到滚动替换控制平面的维护窗口计划。
- 对于跨越多个 Kubernetes 次版本的跨版本升级,已预先准备中间版本的 Core 镜像和 OS 镜像。请参见 跨版本升级准备。
操作步骤
安装完成后,管理 global 集群的 Cluster API controllers 会运行在 global 集群自身上。在本操作步骤中,请使用 global kubeconfig 执行 kubectl 命令。
步骤 1 — 更新 global 集群 Manifest
更新 global 集群的 Cluster API manifest,使其引用新的 Alauda OS 镜像和 Kubernetes 版本。需要更新的 manifest 字段因 provider 而异。
对于 DCS,不要编辑已被正在运行的机器引用的模板,而应创建新的不可变基础设施模板。
更新控制平面资源:
- 为目标镜像创建新的
DCSMachineTemplate,并将spec.template.spec.vmTemplateName设置为与目标 Kubernetes 版本匹配的 Alauda OS template。 - 将保留的节点本地数据(包括
/var/cpaas)保留在DCSIpHostnamePool.spec.pool[].persistentDisk中。不要将保留磁盘移回DCSMachineTemplate。 - 将
KubeadmControlPlane.spec.version设置为目标 Kubernetes 版本。 - 将
KubeadmControlPlane.spec.machineTemplate.infrastructureRef.name指向新的DCSMachineTemplate。 - 当集群使用由池管理的持久磁盘时,保持
KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge: 0。
更新 worker 节点资源:
- 使用目标
vmTemplateName创建新的 workerDCSMachineTemplate。 - 将每个
MachineDeployment.spec.template.spec.version设置为目标 Kubernetes 版本。 - 将每个
MachineDeployment.spec.template.spec.infrastructureRef.name指向新的 workerDCSMachineTemplate。 - 当 worker 池使用由池管理的持久磁盘时,保持每个
MachineDeployment.spec.strategy.rollingUpdate.maxSurge: 0。
由池管理的持久磁盘在 IP 池中声明,而不是在 machine template 中:
仅当 DCS 环境要求显式指定 thin-provisioning 值时,才使用 isThin。如果省略该字段,provider 不会发送 isThin,而 DCS 会使用平台默认值。新的持久卷会创建为独立的持久普通卷。
使用 IP 池状态确认,在滚动替换期间,保留磁盘已从旧 VM 分离并附加到替换 VM。
步骤 2 — 应用更新后的 Manifest
将更新后的 manifest 应用到 global 集群。
Cluster API provider 会开始使用新镜像替换控制平面和 worker 节点。当设置 maxSurge: 0 时,每个旧节点会先被排空并删除,然后其替换节点才能复用相同的固定标识、IP 地址或保留磁盘。
步骤 3 — 监控滚动替换
持续观察滚动替换,直到所有控制平面和 worker 节点都已被替换。
当每个 Machine 都报告新的 Kubernetes 版本和 Phase: Running,并且 KubeadmControlPlane 针对新版本报告 Ready: True 时,升级即完成。
验证
滚动替换完成后,验证升级后的 global 集群是否健康。
所有节点必须报告新的 Kubernetes 版本,ClusterVersionShadow 必须反映目标 Distribution Version,并且核心平台 pod 必须处于 Running 状态。
回滚注意事项
在部分完成阶段 2 升级后执行回滚取决于 provider。通常情况下:
如果升级尚未替换任何控制平面节点,则将 manifest 回退到之前的镜像并重新应用。如果控制平面节点已经被替换,则先从升级开始前创建的 etcd 备份中恢复,然后再回退 manifest。
对于使用由池管理的持久磁盘的 DCS 集群,在回滚前请确认磁盘状态:
首先,在删除或重新创建机器之前检查 DCSIpHostnamePool.status.persistentDiskStatus。不要删除 DCSIpHostnamePool.spec.pool[].persistentDisk 中列出的保留 DCS 卷。
回退到之前的 machine template 时保持 maxSurge: 0,以便一次只替换一个节点。如果控制平面已经被替换且集群状态不一致,请先从已验证的 etcd 备份中恢复,然后再重新应用之前的 manifest。