在 Alauda OS 上升级 global 集群的 Kubernetes
本文介绍如何升级运行 Alauda OS 的 global 集群。升级会使用 Cluster API provider 管理的新 Alauda OS 镜像替换节点;不会执行节点原地升级。
对于 Huawei DCS global 集群,请选择为目标 ACP 版本发布的 Alauda OS 镜像。如果集群的 VM 模板基于早于 ACP v4.3.2 版本发布的 Alauda OS 镜像创建,则该模板与 DCS Provider v1.0.21 或更高版本不匹配。请同时升级 provider 和 global 集群的 Distribution Version,因为平台会在该升级过程中升级已安装的 Aligned 插件;请参阅升级前准备。然后使用为目标 ACP 版本发布的 Alauda OS 镜像创建 VM 模板,并按照本文档替换节点。请参阅在 Huawei DCS 上升级 Kubernetes。
何时使用此路径
在以下情况下选择此升级路径:
global 集群安装在 Alauda OS 上。请参阅安装 global 集群。
- 您的基础设施属于有文档说明的 provider 之一:Huawei DCS、VMware vSphere、Huawei Cloud Stack 或 Bare Metal。
对于非 Alauda OS global 集群,Kubernetes 会作为升级 Distribution Version的一部分进行原地升级;本页面不适用。
在 DR 对中,请使用各自的 global kubeconfig,在两个 global 集群上分别执行此 Kubernetes 升级。有关该对集群的 Distribution Version 升级,请参阅在 DR 环境中升级。
两阶段升级概览
与业务集群一样,Alauda OS global 集群也遵循两阶段升级流程。
- 阶段 1 — ACP Core 和 Distribution Version:准备构件和插件包,然后使用 CVO 将 global 层移动到目标 Distribution Version。请参阅升级前准备和升级 Distribution Version。
- 阶段 2 — Kubernetes 和 OS 镜像:使用包含目标 Kubernetes 版本的新 Alauda OS 镜像替换节点。本文档重点介绍
global 集群的阶段 2。
Phase 1 Compatibility
开始阶段 2 之前,请确认每个业务集群都处于目标 Distribution Version 的兼容版本矩阵范围内。超出范围的业务集群必须先升级。
通用前提条件
global 集群已完成阶段 1(Distribution Version 升级)。
global 集群所运行的 IaaS 的基础设施 provider 和 Cluster Bootstrap Provider 已上传并安装到 global 集群。如果尚未安装,请先按照 Bare Metal、Huawei DCS、Huawei Cloud Stack 或 VMware vSphere 的 provider 安装页面进行安装。在 DR 对中,请在两个 global 集群上都安装这些 provider。
- 基础设施 provider 版本、Alauda OS 镜像版本和 ACP 版本相匹配。阶段 1 会随
global 集群的 Distribution Version 一起升级 provider。
- 已备份并验证
global 集群的 etcd。
- OS Support Matrix 中的目标行可用,并且其中的 Kubernetes 版本、CoreDNS 标签、etcd 标签和 Kube-OVN chart 已准备就绪,同时已发布该版本对应的 Alauda OS 镜像。
- 保留之前的 machine template 和 bootstrap template,直到阶段 2 验证完成。
- 制定包含控制平面滚动替换的维护窗口计划。
- 对于跨越多个 Kubernetes 次要版本的跨版本升级,请预先准备中间版本的 Core 镜像和 OS 镜像。请参阅跨版本升级准备。
操作步骤
用于管理 global 集群的 Cluster API 控制器运行在 global 集群本身上。在本操作步骤中,请对 kubectl 命令使用 global kubeconfig。
Required when the target is Kubernetes 1.35
在 Kubernetes 1.35 中,kubelet 凭证验证可能会应用于节点上已经存在的镜像。在升级到 Kubernetes 1.35 或更高版本时,请将 imagePullCredentialsVerificationPolicy: NeverVerify 添加到每个替换节点使用的 kubelet patch 中。在同一 KubeadmControlPlane 编辑中,同时更新控制平面文件和 spec.version。对于工作节点,请创建包含更新后 patch 的新 KubeadmConfigTemplate,并在与版本相同的编辑中切换 MachineDeployment.spec.template.spec.bootstrap.configRef.name。对于 Kubernetes 1.34 或更早版本,请勿添加此参数。请参阅 Kubernetes 1.35 所需的 kubelet patch。
步骤 1 — 升级 Kube-OVN
从目标 OS Support Matrix 行中读取 kube-ovn (chart) 值,然后按照共享的特定 provider 版本的 Kube-OVN 操作步骤进行操作,并将 <cluster-name> 设置为 global。
该操作步骤会先检查已安装的 provider 修订版本,然后选择受支持的新流程或旧流程,处理 v4.4 处的 Kube-OVN chart 名称边界,并验证 chart 名称、目标修订版本、已安装修订版本、阶段和条件。对于 provider 检查以及 cni-kube-ovn AppRelease 检查,请使用 global kubeconfig。只有在所有共享验证条件均通过后,才能开始替换控制平面。
步骤 2 — 更新控制平面资源
更新 global 集群的控制平面资源,使其引用新的 Alauda OS 镜像和 Kubernetes 版本。需要更新的字段因 provider 而异。在步骤 4 中更新工作节点资源。
开始之前,请参阅前提条件。
对于 DCS,请创建新的基础设施模板,而不要编辑正在运行的机器已引用的模板。
更新控制平面资源:
- 为目标镜像创建新的
DCSMachineTemplate,并将 spec.template.spec.vmTemplateName 设置为与目标 Kubernetes 版本匹配的 Alauda OS 模板。
- 将保留的节点本地数据(包括
/var/cpaas)保留在 DCSIpHostnamePool.spec.pool[].persistentDisk 中。不要将保留的磁盘移回 DCSMachineTemplate。
- 将
KubeadmControlPlane.spec.version 设置为目标 Kubernetes 版本。
- 根据同一 OS Support Matrix 行,在
KubeadmControlPlane.spec.kubeadmConfigSpec.clusterConfiguration 中设置 CoreDNS 和 etcd 镜像标签。
- 当目标为 Kubernetes 1.35 或更高版本时,在同一清单编辑中更新
KubeadmControlPlane.spec.kubeadmConfigSpec.files 中的控制平面 kubelet patch。
- 将
KubeadmControlPlane.spec.machineTemplate.infrastructureRef.name 指向新的 DCSMachineTemplate。
- 当集群使用池管理的持久磁盘时,保留
KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge: 0。
池管理的持久磁盘在 IP 池上声明,而不是在 machine template 上声明:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DCSIpHostnamePool
metadata:
name: <global-pool-name>
namespace: cpaas-system
spec:
pool:
- ip: <node-ip>
hostname: <node-hostname>
persistentDisk:
- slot: 0
quantityGB: 40
datastoreName: <datastore-name>
path: /var/cpaas
format: xfs
mountOptions:
- defaults
仅当 DCS 环境要求显式的精简配置值时,才使用 isThin。如果省略,provider 不会发送 isThin,DCS 将使用平台默认值。新持久卷将创建为独立的持久普通卷。
使用 IP 池状态确认在滚动替换期间,保留的磁盘已从旧 VM 分离并连接到替换 VM。
开始之前,请参阅根据准入规则检查清单。
对于 vSphere,请创建新的基础设施模板,而不要编辑正在运行的机器已引用的模板。
更新控制平面资源:
- 导出当前的
VSphereMachineTemplate,为副本指定新名称,移除服务器生成的元数据和 status,并将 spec.template.spec.template 设置为在 vSphere 中根据为目标 ACP 版本发布的 Alauda OS 镜像创建的 VM 模板。
- 保留现有的 vCenter、文件夹、数据存储、网络、克隆模式、CPU、内存和磁盘配置,除非版本操作步骤明确要求更改。保持
spec.template.spec.providerID 未设置。
- 将保留的节点本地数据(包括
/var/cpaas)保留在 VSphereMachineConfigPool.spec.configs[].persistentDisks[] 中;不要将其移入 machine template。
- 根据同一 OS Support Matrix 行设置
KubeadmControlPlane.spec.version、CoreDNS 和 etcd 标签。
- 当目标为 Kubernetes 1.35 或更高版本时,在同一清单编辑中更新
KubeadmControlPlane.spec.kubeadmConfigSpec.files 中的控制平面 kubelet patch。
- 将
KubeadmControlPlane.spec.machineTemplate.infrastructureRef.name 指向新的 VSphereMachineTemplate。
- 当控制平面池使用固定槽位或池管理的持久磁盘时,保留
KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge: 0。
开始之前,请参阅前提条件。
对于 HCS,请创建新的基础设施模板,而不要编辑正在运行的机器已引用的模板。
更新控制平面资源:
- 为目标镜像创建新的
HCSMachineTemplate,并将 spec.template.spec.imageName 设置为与目标 Kubernetes 版本匹配的 Alauda OS 镜像。
- 将保留的节点本地数据(包括
/var/cpaas)保留在 HCSMachineConfigPool.spec.configs[].persistentDisks[] 中。不要将保留的磁盘移回 HCSMachineTemplate.spec.template.spec.dataVolumes[]。
- 在新模板中保持运行时身份字段未设置,包括
spec.template.spec.providerID 和 spec.template.spec.serverId。
- 将
KubeadmControlPlane.spec.version 设置为目标 Kubernetes 版本。
- 根据同一 OS Support Matrix 行,在
KubeadmControlPlane.spec.kubeadmConfigSpec.clusterConfiguration 中设置 CoreDNS 和 etcd 镜像标签。
- 当目标为 Kubernetes 1.35 或更高版本时,在同一清单编辑中更新
KubeadmControlPlane.spec.kubeadmConfigSpec.files 中的控制平面 kubelet patch。
- 将
KubeadmControlPlane.spec.machineTemplate.infrastructureRef.name 指向新的 HCSMachineTemplate。
- 当控制平面池使用池管理的持久磁盘时,保留
KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge: 0。
池管理的持久磁盘在 machine configuration pool 上声明,而不是在 machine template 上声明:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSMachineConfigPool
metadata:
name: <global-pool-name>
namespace: cpaas-system
labels:
cluster.x-k8s.io/cluster-name: global
spec:
configs:
- hostname: <node-hostname>
networks:
- subnetName: <subnet-name>
ipAddress: <node-ip>
persistentDisks:
- slot: 0
size: 100
type: SSD
mountPath: /var/cpaas
format: xfs
mountOptions:
- defaults
- noatime
在节点替换期间,不要将 HCS dataVolumes[] 视为保留状态。此滚动升级工作流支持高可用控制平面,该控制平面可以替换 HCSMachineTemplate 和 KubeadmControlPlane 引用,同时 HCSMachineConfigPool 保留足够的固定身份和持久磁盘槽位以完成发布。单控制平面 HCS 集群(包括只有一个控制平面节点的 global 集群)无法升级。
开始之前,请参阅检查 COS_STATE 可用空间和更新镜像目录。
仅当 Bare Metal provider 已安装在 global 集群上,并且已安装版本中存在目标 OS Support Matrix 行时,才能使用此 YAML 工作流。在编辑 Cluster API 资源之前,请确认 provider 的 AppRelease 请求修订版本和已安装修订版本相匹配,并且其 chart 阶段为 Success。
将目标版本的 Bare Metal OS 镜像导入 global 集群的 registry,并按照已导入 OS 镜像并填充镜像目录中的说明,将目标 Kubernetes 版本添加到其 elemental-image-catalog。provider 插件和 Distribution Version 升级都不会为您添加该版本。在 DR 对中,请在两个 global 集群上执行此操作。然后验证目录:
kubectl --kubeconfig <global-kubeconfig> -n cpaas-system \
get configmap elemental-image-catalog -o yaml
目标版本必须作为键出现,并且具有可访问的基础镜像引用。在缺少该键时创建的替换 Machine 会使其 BaremetalMachine 保持在 Failed 中,并带有 Reason=ImageCatalogMiss;之后再添加该键也无法恢复它。Bare Metal provider 从 Machine.spec.version 解析替换镜像;除非控制平面或工作节点必须移动到其他 MachineInventoryPool,否则仅升级 Kubernetes 不需要新的 BaremetalMachineTemplate。
使用同一 OS Support Matrix 行中的值更新现有的 KubeadmControlPlane 清单。保留此处未显示的所有字段:
spec:
version: <target-kubernetes-version>
rolloutStrategy:
rollingUpdate:
maxSurge: 0
kubeadmConfigSpec:
clusterConfiguration:
dns:
imageTag: <target-coredns-tag>
etcd:
local:
imageTag: <target-etcd-tag>
保留现有的 spec.kubeadmConfigSpec.files 条目。对于 Kubernetes 1.35 或更高版本,按照上述说明更新该列表中现有的 kubeletconfiguration0+strategic.json 条目;不要将该列表替换为空值。
在步骤 3 中应用完整的保留控制平面清单。provider 会删除每台旧机器、清理其 inventory、从同一池中分配可用 inventory,并为目标镜像写入 reprovision 计划。
步骤 3 — 应用控制平面更改并等待
将更新后的控制平面清单应用到 global 集群。
kubectl --kubeconfig <global-kubeconfig> apply -f <updated-control-plane-manifest>
Cluster API provider 开始使用新镜像替换控制平面节点。当设置了 maxSurge: 0 时,每个旧节点都会先被驱逐并删除,然后其替换节点才能重新使用相同的固定身份、IP 地址或保留的磁盘。
等待所有控制平面节点完成替换。
kubectl --kubeconfig <global-kubeconfig> get machines -A -o wide
kubectl --kubeconfig <global-kubeconfig> get kubeadmcontrolplane -A
当每个控制平面 Machine 都报告新的 Kubernetes 版本和 Phase: Running,并且 KubeadmControlPlane 针对新版本报告 Ready: True 时,控制平面替换即完成。
步骤 4 — 更新工作节点资源
更新 global 集群的工作节点资源,使其引用新的 Alauda OS 镜像和 Kubernetes 版本。需要更新的字段因 provider 而异。
更新工作节点资源:
- 使用目标
vmTemplateName 创建新的工作节点 DCSMachineTemplate。
- 将每个
MachineDeployment.spec.template.spec.version 设置为目标 Kubernetes 版本。
- 当目标为 Kubernetes 1.35 或更高版本时,创建包含所需 kubelet patch 的新工作节点
KubeadmConfigTemplate,并将 MachineDeployment.spec.template.spec.bootstrap.configRef.name 指向它。
- 将每个
MachineDeployment.spec.template.spec.infrastructureRef.name 指向新的工作节点 DCSMachineTemplate。
- 当工作节点池使用池管理的持久磁盘时,保留每个
MachineDeployment.spec.strategy.rollingUpdate.maxSurge: 0。
更新工作节点资源:
- 使用目标 VM 模板和保留的 provider 配置创建新的工作节点
VSphereMachineTemplate。
- 将每个
MachineDeployment.spec.template.spec.version 设置为目标 Kubernetes 版本。
- 当目标为 Kubernetes 1.35 或更高版本时,创建包含所需 kubelet patch 的新工作节点
KubeadmConfigTemplate,并将 MachineDeployment.spec.template.spec.bootstrap.configRef.name 指向它。
- 将每个
MachineDeployment.spec.template.spec.infrastructureRef.name 指向新的工作节点 VSphereMachineTemplate。
- 当工作节点池使用固定槽位或池管理的持久磁盘时,保留每个
MachineDeployment.spec.strategy.rollingUpdate.maxSurge: 0。
不要编辑正在运行的机器引用的模板。保留之前的控制平面和工作节点模板,直到新的发布经过验证。
更新工作节点资源:
- 使用目标
imageName 创建新的工作节点 HCSMachineTemplate。
- 将每个
MachineDeployment.spec.template.spec.version 设置为目标 Kubernetes 版本。
- 当目标为 Kubernetes 1.35 或更高版本时,创建包含所需 kubelet patch 的新工作节点
KubeadmConfigTemplate,并将 MachineDeployment.spec.template.spec.bootstrap.configRef.name 指向它。
- 将每个
MachineDeployment.spec.template.spec.infrastructureRef.name 指向新的工作节点 HCSMachineTemplate。
- 当工作节点池使用池管理的持久磁盘时,保留每个
MachineDeployment.spec.strategy.rollingUpdate.maxSurge: 0。
对于每个工作节点 MachineDeployment,设置目标 Kubernetes 版本并保留 maxSurge: 0。当目标为 Kubernetes 1.35 或更高版本时,先创建包含所需 kubelet patch 的新 KubeadmConfigTemplate,然后在同一清单更改中引用它:
spec:
strategy:
rollingUpdate:
maxSurge: 0
template:
spec:
version: <target-kubernetes-version>
bootstrap:
configRef:
name: <target-kubeadm-config-template>
如果更早的目标版本不需要更改 bootstrap 设置,则省略 bootstrap.configRef 更改。在步骤 5 中应用完整的保留工作节点清单。
步骤 5 — 应用工作节点更改
将更新后的工作节点清单应用到 global 集群。
kubectl --kubeconfig <global-kubeconfig> apply -f <updated-worker-manifest>
Cluster API provider 开始使用新镜像替换工作节点。当设置了 maxSurge: 0 时,每个旧节点都会先被驱逐并删除,然后其替换节点才能重新使用相同的固定身份、IP 地址或保留的磁盘。
步骤 6 — 监控滚动替换
监控滚动替换,直到所有工作节点都完成替换。
kubectl --kubeconfig <global-kubeconfig> get machines -A -o wide
kubectl --kubeconfig <global-kubeconfig> get kubeadmcontrolplane -A
当每个 Machine 都报告新的 Kubernetes 版本和 Phase: Running,并且 KubeadmControlPlane 针对新版本报告 Ready: True 时,升级即完成。
验证
滚动替换完成后,验证已升级的 global 集群是否运行正常。
kubectl --kubeconfig <global-kubeconfig> get nodes -o wide
kubectl --kubeconfig <global-kubeconfig> get clusterversionshadow -o yaml
kubectl --kubeconfig <global-kubeconfig> get pods -n cpaas-system
所有节点都必须报告新的 Kubernetes 版本,ClusterVersionShadow 必须反映目标 Distribution Version,且核心平台 Pod 必须处于 Running 状态。
恢复注意事项
不要将 Kubernetes 次要版本降级视为普通回滚。请根据发布阶段选择恢复路径:
- 尚未创建目标版本控制平面的
Machine:恢复之前的 Kube-OVN 状态和之前的清单值。在引入新的控制平面数据格式之前,取消目标版本发布。
- 仅更改了机器模板或 OS 镜像,且 Kubernetes 次要版本未更改:将控制资源指回之前的模板,并让 Cluster API 执行另一次替换发布。保持 Kubernetes 次要版本不变。
- 目标 Kubernetes 次要版本的控制平面
Machine 已加入集群:不要将 Kubernetes、CoreDNS 或 etcd 修补回之前的次要版本。停止进一步发布,并在目标次要版本上向前修复;或者通过已验证的升级前 etcd 备份或 Global DR 操作恢复 global 集群。
如果已创建目标次要版本的控制平面 Machine,但它从未加入集群,请先恢复正常的 etcd quorum,并在更改清单之前确定是否可以安全移除失败的替换节点。
对于使用池管理持久磁盘的 DCS 集群,请在回滚前确认磁盘状态:
首先,在删除或重新创建机器之前检查 DCSIpHostnamePool.status.persistentDiskStatus。不要删除 DCSIpHostnamePool.spec.pool[].persistentDisk 中列出的保留 DCS 卷。
对于阶段 1,请使用在阶段 1 恢复期间恢复 Kube-OVN中的 DCS 规则;具体操作取决于已安装的 provider 版本。在同一次要版本的替换恢复过程中返回之前的机器模板时,保留 maxSurge: 0。如果目标次要版本的控制平面机器已加入集群,请保留目标基线,并使用向前恢复或备份恢复。
对于阶段 1,请使用在阶段 1 恢复期间恢复 Kube-OVN中的 vSphere 规则。对于同一次要版本的模板恢复,请保留 maxSurge: 0,将控制平面和工作节点资源指向保留的之前的 VSphereMachineTemplate 资源,并验证每个固定插槽都重新连接了其池管理持久磁盘。如果目标次要版本的控制平面机器已加入集群,请保留目标 Kubernetes、CoreDNS、etcd 和 Kube-OVN 基线,并使用向前恢复或备份恢复。
HCS dataVolumes[] 上的节点本地数据不是恢复源,因为节点替换可能会删除旧 VM 及其附加卷。在 HCSMachineConfigPool.spec.configs[].persistentDisks[] 中声明的数据会在替换期间重新连接。对于阶段 1,请使用在阶段 1 恢复期间恢复 Kube-OVN中的 HCS 规则;具体操作取决于已安装的 provider 版本。对于同一次要版本的模板恢复,请保留 maxSurge: 0,并将控制资源指向保留的之前的 HCSMachineTemplate 资源。如果目标次要版本的控制平面机器已加入集群,请保留目标基线,并使用向前恢复或备份恢复。
对于阶段 1,请使用在阶段 1 恢复期间恢复 Kube-OVN中的 Bare Metal 规则,然后仅当尚未创建目标次要版本控制平面的 Machine 时,才恢复之前的清单。
每个完成 reprovision 计划的主机都已替换其 OS 镜像并清除了 Kubernetes 管理的状态。如果目标次要版本的控制平面机器已加入集群,请不要将 Kubernetes、CoreDNS 或 etcd 修补回之前的次要版本。向前修复,或通过已验证的 etcd 备份或 Global DR 操作恢复 global 集群。
后续步骤