#Обновление кластеров на VMware vSphere

#Создайте целевые шаблоны машин

Перед началом поэтапного обновления создайте новые ресурсы 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 задает providerID как BIOS UUID VM после ее создания; предварительное заполнение этого поля в шаблоне нарушает связывание идентичности в контроллере.

3. Экспортируйте и измените шаблон рабочих узлов

   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

#Обновите плоскость управления

Перед началом соберите все необходимые значения из целевой строки ACP в матрице поддержки ОС, как описано в разделе Необходимые значения из матрицы поддержки ОС.

1. Исправьте KubeadmControlPlane, указав целевые значения Kubernetes

   Обновите ресурс KubeadmControlPlane одной операцией редактирования, чтобы spec.version, тег образа CoreDNS, тег образа etcd и ссылка на инфраструктурный шаблон оставались согласованными с одним и тем же шаблоном VM:

   • spec.version ← Kubernetes Version из строки матрицы поддержки ОС

   • spec.kubeadmConfigSpec.clusterConfiguration.dns.imageTag ← столбец coredns из той же строки

   • spec.kubeadmConfigSpec.clusterConfiguration.etcd.local.imageTag ← столбец etcd из той же строки

   • spec.machineTemplate.infrastructureRef.name ← имя нового VSphereMachineTemplate, созданного выше

     kubectl edit kubeadmcontrolplane <cluster_name> -n <namespace>

   Одного только обновления spec.version недостаточно. Теги образов CoreDNS и etcd должны изменяться вместе с версией Kubernetes, потому что они собираются из одного и того же выпуска; если оставить их в прежних значениях, это может привести к тому, что поды CoreDNS и etcd не будут соответствовать новой minor-версии Kubernetes.

2. Обновите аннотацию версии Kube-OVN в ресурсе Cluster

   Если в целевой строке ACP в матрице поддержки ОС указано значение kube-ovn (chart), отличающееся от текущего кластера, обновите аннотацию в ресурсе Cluster, чтобы провайдер vSphere согласовал новый AppRelease Kube-OVN.

   INFO

   Предварительное условие — аннотация-гейт для согласования Kube-OVN (только vSphere)

   В vSphere провайдер согласует AppRelease Kube-OVN только тогда, когда ресурс Cluster содержит аннотацию cpaas.io/network-type: kube-ovn. Обычно эта аннотация задается при создании кластера. Если она отсутствует, приведенные ниже шаги успешно запишут аннотацию версии, но AppRelease Kube-OVN согласован не будет. Перед продолжением проверьте:

   kubectl get cluster <cluster_name> -n <namespace> \
     -o jsonpath='{.metadata.annotations.cpaas\.io/network-type}{"\n"}'
   # Expected output: kube-ovn

   Это предварительное условие специфично для vSphere. Провайдеры DCS и Huawei Cloud Stack используют вместо этого поле spec.networkType ресурсов DCSCluster / HCSCluster и не требуют этой аннотации.

   kubectl annotate cluster <cluster_name> -n <namespace> \
     cpaas.io/kube-ovn-version=<kube-ovn-version-from-matrix> --overwrite

   Kube-OVN — это компонент жизненного цикла Core, но на неизменяемой ОС провайдер vSphere управляет его доставкой на основе этой аннотации; аннотация не обновляется автоматически при изменении spec.version.

   Провайдер vSphere согласует один AppRelease Kube-OVN с именем cni-kube-ovn в пространстве имен cpaas-system рабочего кластера. Запустите следующую команду в рабочем кластере (не в bootstrap KIND и не в кластере global), чтобы отслеживать согласование:

   # Overall AppRelease state — Sync and Health columns must reach a Success-equivalent reason
   kubectl get apprelease cni-kube-ovn -n cpaas-system
   
   # Installed revision and chart phase
   kubectl get apprelease cni-kube-ovn -n cpaas-system \
     -o jsonpath='Installed: {.status.charts.*.installedRevision}{"\n"}Phase: {.status.charts.*.phase}{"\n"}'

   Обычная последовательность: Upgrading → HealthChecking → Success. На небольших кластерах полный переход обычно завершается примерно за одну минуту. Интерпретируйте фазы следующим образом:

   Фаза	Значение	installedRevision
   Upgrading	Идет обновление Helm release. Состояние Sync — Unknown(Syncing).	Все еще предыдущая версия
   HealthChecking	Helm release применен; контроллер проверяет поды Kube-OVN. Состояние Sync — True(Synced).	Уже целевая версия
   Success	Все три состояния (Validate, Sync, Health) равны True.	Целевая версия

   WARNING

   Не объявляйте обновление завершенным только по значению installedRevision. Это поле переходит в целевое значение во время HealthChecking, до того как поды будут проверены на состояние Ready. Chart считается обновленным только тогда, когда phase имеет значение Success и installedRevision соответствует целевому значению.

   API AppRelease также определяет состояния Downloading, Installing, Syncing, DownloadFailed, DeployFailed и NotReady. Первые три являются переходными, и обновление должно завершиться само. Последние три указывают на ошибку, требующую ручного анализа; начните с kubectl describe apprelease cni-kube-ovn -n cpaas-system, чтобы прочитать поле message для каждого состояния.

3. Отслеживайте rollout плоскости управления

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

#Обновите рабочие узлы

После завершения обновления плоскости управления измените MachineDeployment, чтобы он ссылался на новый шаблон рабочих узлов и целевую версию Kubernetes.

Обычно изменяются следующие поля:

• spec.template.spec.version — целевая версия Kubernetes
• spec.template.spec.infrastructureRef.name — имя нового VSphereMachineTemplate
• spec.template.spec.bootstrap.configRef.name — имя нового KubeadmConfigTemplate, если необходимо изменить параметры 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>"
          }
        }
      }
    }
  }'

Отслеживайте rollout рабочих узлов:

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