#在 VMware vSphere 上升级集群

#在控制平面之前升级 Kube-OVN

请按照 在控制平面之前升级 Kube-OVN 中的说明，选择与已安装 provider 版本匹配的 VMware vSphere 操作步骤。共享操作步骤包括 vSphere 特定的网络注解检查、Kube-OVN v4.4 处的 chart 名称迁移、旧 provider 边界，以及所需的 AppRelease 健康检查。

对于目标为 Kube-OVN v4.4+ 的情况，请先将 vSphere provider 升级到 v1.0.16 或更高版本。不要使用更早的 provider 手动 patch chart source，因为其 controller 可能会将旧的 chart 名称回写覆盖更改。

#创建目标机器模板

在开始滚动升级之前，请先为控制平面和 worker 创建新的 VSphereMachineTemplate 资源。

1. 导出现有的控制平面模板

   kubectl get vspheremachinetemplate <cluster_name>-control-plane -n <namespace> -o yaml > new-cp-template.yaml

2. 修改控制平面模板

   编辑 new-cp-template.yaml：

   • 将 metadata.name 设置为一个新的唯一名称（例如，<cluster_name>-control-plane-v2）
   • 将 spec.template.spec.template 更新为目标 VM 模板名称
   • 如有需要，更新 CPU、内存或磁盘设置
   • 删除服务器生成的字段：metadata.resourceVersion、metadata.uid、metadata.generation、metadata.creationTimestamp、metadata.managedFields、metadata.annotations["kubectl.kubernetes.io/last-applied-configuration"] 和 status
   • 保持 spec.template.spec.providerID 未设置。vSphere provider 会在 VM 创建后将 providerID 设置为该 VM 的 BIOS UUID；在模板中预先填充该值会破坏 controller 的身份绑定。

3. 导出并修改 worker 模板

   kubectl get vspheremachinetemplate <cluster_name>-worker -n <namespace> -o yaml > new-worker-template.yaml

   编辑 new-worker-template.yaml：

   • 将 metadata.name 设置为一个新的唯一名称（例如，<cluster_name>-worker-v2）
   • 将 spec.template.spec.template 更新为目标 VM 模板名称
   • 如有需要，更新 CPU、内存或磁盘设置
   • 删除上面列出的相同服务器生成字段

4. 应用这两个新模板

   kubectl apply -f new-cp-template.yaml
   kubectl apply -f new-worker-template.yaml

#升级控制平面

开始之前，请先完成共享的 在控制平面之前升级 Kube-OVN 操作步骤，并确认 cni-kube-ovn AppRelease 的版本已达到目标 revision 且 phase=Success。然后按照 来自 OS Support Matrix 的必需值 中的说明，从目标 ACP 行中收集所有必需的控制平面值。

1. 使用目标 Kubernetes 值 patch KubeadmControlPlane

   一次性编辑 KubeadmControlPlane 资源，以保持 spec.version、CoreDNS image tag、etcd image tag 和基础设施模板引用与同一个 VM 模板保持一致：

   • spec.version ← OS Support Matrix 行中的 Kubernetes Version

   • spec.kubeadmConfigSpec.clusterConfiguration.dns.imageTag ← 同一行中的 coredns 列

   • spec.kubeadmConfigSpec.clusterConfiguration.etcd.local.imageTag ← 同一行中的 etcd 列

   • spec.machineTemplate.infrastructureRef.name ← 上面创建的新 VSphereMachineTemplate 名称

   • 当目标版本为 Kubernetes 1.35 或更高版本时，请在同一次编辑中更新 spec.kubeadmConfigSpec.files 中的 /etc/kubernetes/patches/kubeletconfiguration0+strategic.json，具体请参见 Kubernetes 1.35 所需的 kubelet patch

     kubectl edit kubeadmcontrolplane <cluster_name> -n <namespace>

   仅更新 spec.version 并不够。CoreDNS 和 etcd 的 image tag 必须与 Kubernetes 版本一起迁移，因为它们是基于同一 release 构建的；如果保留为之前的值，可能会导致 CoreDNS 和 etcd pod 与新的 Kubernetes minor 版本不匹配。

2. 监控控制平面滚动更新

   kubectl -n <namespace> get kubeadmcontrolplane <cluster_name> -w
   kubectl -n <namespace> get machine -l cluster.x-k8s.io/control-plane

#升级 worker 节点

控制平面升级完成后，更新 MachineDeployment，使其引用新的 worker 模板和目标 Kubernetes 版本。

常见更改包括：

• spec.template.spec.version — 目标 Kubernetes 版本
• spec.template.spec.infrastructureRef.name — 新的 VSphereMachineTemplate 名称
• spec.template.spec.bootstrap.configRef.name — 新的 KubeadmConfigTemplate 名称。这在 Kubernetes 1.35 或更高版本中是必需的，这样 worker 才能接收 所需的 kubelet patch；对于更早的版本，仅在其他 bootstrap 设置也必须更改时才修改它。参见 更新 Bootstrap 模板。

应用更改：

以下命令包含 Kubernetes 1.35 或更高版本所需的 bootstrap 引用。对于没有 bootstrap 变更的较早目标版本，请省略 bootstrap 对象。

kubectl patch machinedeployment <cluster_name>-md-0 -n <namespace> \
  --type='merge' -p='{
    "spec": {
      "template": {
        "spec": {
          "version": "<target_kubernetes_version>",
          "infrastructureRef": {
            "name": "<new-worker-template-name>"
          },
          "bootstrap": {
            "configRef": {
              "name": "<new-bootstrap-template-name>"
            }
          }
        }
      }
    }
  }'

监控 worker 滚动更新：

kubectl -n <namespace> get machinedeployment <cluster_name>-md-0 -w
kubectl -n <namespace> get machine
kubectl --kubeconfig=/tmp/<cluster_name>.kubeconfig get nodes -o wide