• Русский
  • Обновление кластеров на VMware vSphere

    В этом документе описано, как выполнить обновление Kubernetes-кластеров на VMware vSphere после завершения обновления дистрибутива на стороне платформы. Описанный рабочий процесс сосредоточен на обновлении control plane и worker nodes через ресурсы Cluster API.

    Последовательность обновления

    Обновляйте кластеры VMware vSphere в следующем порядке:

    1. Завершите обновление версии дистрибутива, описанное в Обновление кластеров.
    2. Убедитесь, что control plane работает нормально и текущий кластер стабилен.
    3. Обновите версию Kubernetes control plane.
    4. Обновите worker nodes до целевой версии Kubernetes.

    Предварительные требования

    Перед началом убедитесь, что выполнены следующие условия:

    • Обновление версии дистрибутива завершено.
    • Control plane работает нормально и доступен.
    • Все узлы находятся в состоянии Ready.
    • Целевой VM template совместим с целевой версией Kubernetes.
    • Machine config pools имеют достаточную емкость для rolling updates.
    WARNING

    Templates являются неизменяемыми

    Ресурсы VSphereMachineTemplate не могут быть изменены на месте. Для каждого обновления, которое меняет параметры VM или имя VM template, требуется создать новый VSphereMachineTemplate с новым именем и обновить ссылку в KubeadmControlPlane или MachineDeployment.

    Шаги

    Создайте целевые machine templates

    Перед началом rolling upgrade создайте новые ресурсы VSphereMachineTemplate для control plane и worker nodes.

    1. Экспортируйте существующий template control plane

      kubectl get vspheremachinetemplate <cluster_name>-control-plane -n <namespace> -o yaml > new-cp-template.yaml
    2. Измените template control plane

      Отредактируйте new-cp-template.yaml:

      • Установите metadata.name в новое уникальное имя (например, <cluster_name>-control-plane-v2)
      • Обновите spec.template.spec.template до имени целевого VM template
      • При необходимости обновите настройки CPU, memory или disk
      • Удалите поля, сгенерированные сервером: metadata.resourceVersion, metadata.uid, metadata.generation, metadata.creationTimestamp, metadata.managedFields, metadata.annotations["kubectl.kubernetes.io/last-applied-configuration"] и status
    3. Экспортируйте и измените worker template

      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 template
      • При необходимости обновите настройки CPU, memory или disk
      • Удалите те же поля, сгенерированные сервером, перечисленные выше
    4. Примените оба новых template

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

    Обновите control plane

    Обновите ресурс KubeadmControlPlane, чтобы он ссылался на новый template control plane и целевую версию Kubernetes.

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

    • spec.version — целевая версия Kubernetes
    • spec.machineTemplate.infrastructureRef.name — новое имя VSphereMachineTemplate
    • Связанные теги образов, например dns.imageTag и etcd.local.imageTag, если они требуются целевым выпуском

    Примените изменения:

    kubectl patch kubeadmcontrolplane <cluster_name> -n <namespace> \
      --type='merge' -p='{
        "spec": {
          "version": "<target_kubernetes_version>",
          "machineTemplate": {
            "infrastructureRef": {
              "name": "<new-cp-template-name>"
            }
          }
        }
      }'
    TIP

    Если целевому выпуску Kubernetes также требуются обновленные теги образов (например, dns.imageTag или etcd.local.imageTag), включите их в payload patch или примените полный manifest с помощью kubectl apply -f.

    Отслеживайте rollout control plane:

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

    Обновите worker nodes

    После завершения обновления control plane обновите MachineDeployment, чтобы он ссылался на новый worker template и целевую версию Kubernetes.

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

    • spec.template.spec.version — целевая версия Kubernetes
    • spec.template.spec.infrastructureRef.name — новое имя VSphereMachineTemplate
    • spec.template.spec.bootstrap.configRef.name — новое имя KubeadmConfigTemplate, если требуется изменить настройки bootstrap (см. Обновление bootstrap templates)

    Примените изменения:

    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 worker nodes:

    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

    Откат неудачного обновления

    Если rolling update завершается с ошибкой (например, новые VM не загружаются или узлы не переходят в состояние Ready), верните ссылки на template к предыдущим именам template. Старые templates по-прежнему существуют, и Cluster API выполнит откат к предыдущей конфигурации.

    • Для control plane: выполните patch KubeadmControlPlane, чтобы восстановить прежние значения spec.machineTemplate.infrastructureRef.name и spec.version.
    • Для worker nodes: выполните patch MachineDeployment, чтобы восстановить прежние значения spec.template.spec.infrastructureRef.name и spec.template.spec.version.

    Проверка

    После обновления подтвердите следующие результаты:

    • KubeadmControlPlane достигает целевой версии и требуемого количества реплик.
    • MachineDeployment достигает целевой версии и требуемого количества реплик.
    • Control plane и worker nodes возвращаются в состояние Ready.
    • DaemonSet vSphere CPI остается доступным в workload cluster.

    Следующие шаги

    После завершения обновления Kubernetes продолжите стандартные операции с узлами в Управление узлами на VMware vSphere.