#Миграция существующих кластеров Huawei Cloud Stack на постоянные диски, управляемые пулом

Используйте это руководство, если вы обновляете существующий кластер Huawei Cloud Stack (HCS) со старой схемы томов данных HCSMachineTemplate на модель постоянных дисков, управляемых пулом.

Начиная с HCS provider v1.0.1 или более поздней версии, диски, которые должны сохраняться при замене узла, объявляются в HCSMachineConfigPool.spec.configs[].persistentDisks[]. Это включает диск /var/cpaas, требуемый платформой.

#Обзор

В старых кластерах HCS каталог /var/cpaas часто располагался в HCSMachineTemplate.spec.template.spec.dataVolumes[]. Такая схема создает тома данных вместе с ECS. При пошаговой замене старый ECS и принадлежащие шаблону тома данных могут быть удалены одновременно.

Модель, управляемая пулом, переносит диски, сохраняемые при обновлении, в HCSMachineConfigPool.spec.configs[].persistentDisks[]. Каждый постоянный диск привязан к фиксированной идентичности (hostname, slot). Во время пошаговой замены provider:

1. Забирает существующий диск EVS у старого ECS, если он соответствует объявлению пула.
2. Останавливает старый ECS.
3. Отключает диск EVS и ожидает, пока он станет доступен.
4. Удаляет старый ECS.
5. Создает заменяющий ECS с тем же диском EVS, подключенным до первой загрузки.
6. Загружает заменяющий ECS, который монтирует существующую файловую систему без повторного форматирования.

#Перед началом

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

• В управляющем кластере установлен HCS provider версии v1.0.1 или более поздней.
• Рабочий кластер находится в здоровом состоянии, и все узлы имеют статус Ready.
• Для назначения фиксированных hostnames и IP addresses в кластере используется HCSMachineConfigPool.
• Сохраняемые диски имеют непустые пути монтирования в старом HCSMachineTemplate.spec.template.spec.dataVolumes[].
• Соответствующие стратегии rollout используют maxSurge: 0.
• У вас есть окно обслуживания для поочередной замены узлов.
• У вас есть проверенная резервная копия etcd и конфигурации платформы.

#Проверка текущей схемы дисков

Определите объекты управляющего кластера, которые контролируют кластер:

kubectl get cluster -n cpaas-system
kubectl get kubeadmcontrolplane -n cpaas-system
kubectl get machinedeployment -n cpaas-system
kubectl get hcsmachinetemplate -n cpaas-system
kubectl get hcsmachineconfigpool -n cpaas-system
kubectl get hcsmachine -n cpaas-system

Проверьте текущие machine templates:

kubectl get hcsmachinetemplate <template-name> -n cpaas-system -o yaml

Зафиксируйте каждую запись dataVolumes[], которую требуется сохранить. Для каждого диска запишите:

#Определите, какие диски нужно сохранить

Переносите в модель, управляемую пулом, только те диски, которые должны переживать замену узла.

Используйте следующую схему разделения:

Для автоматической миграции provider забирает существующий том данных, сопоставляя mountPath. Если у сохраняемого диска нет mountPath, автоматический захват недоступен. Используйте поддерживаемую эксплуатационную процедуру, чтобы записать существующий EVS volumeID в status.persistentDiskStatus[], либо перенесите данные на диск с объявленным путем монтирования до запуска замены.

#Создайте новые Machine Templates

Создайте новые ресурсы HCSMachineTemplate для заменяющих узлов. Не редактируйте существующие шаблоны на месте.

Скопируйте текущий шаблон:

kubectl get hcsmachinetemplate <current-template-name> -n cpaas-system -o yaml > new-template.yaml

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

1. Установите metadata.name в новое имя шаблона.
2. Удалите метаданные, создаваемые сервером, такие как resourceVersion, uid, creationTimestamp, managedFields и status.
3. Оставьте без значений поля runtime identity, включая spec.template.spec.providerID и spec.template.spec.serverId.
4. Удалите сохраняемые пути из spec.template.spec.dataVolumes[].
5. Оставьте только временные тома данных, которые могут быть созданы заново с каждым ECS.
6. Обновите spec.template.spec.imageName и другие поля обновления, если эта миграция выполняется как часть обновления Kubernetes или образа.

Например, после переноса /var/cpaas в пул шаблон сохраняет только временные диски:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSMachineTemplate
metadata:
  name: <new-template-name>
  namespace: cpaas-system
spec:
  template:
    spec:
      imageName: <vm-image-name>
      flavorName: <instance-flavor>
      availabilityZone: <availability-zone>
      rootVolume:
        type: SSD
        size: 100
      configPoolRef:
        name: <pool-name>
      dataVolumes:
        - size: 100
          type: SSD
          mountPath: /var/lib/containerd
          format: xfs

Примените новый шаблон:

kubectl apply -f new-template.yaml -n cpaas-system

#Подготовьте стратегию rollout

Перед обновлением пула убедитесь в стратегии rollout для каждого контроллера, который будет использовать обновленный пул. Пропустите команду MachineDeployment, если в этой миграции в кластере нет пула worker-узлов.

kubectl get kubeadmcontrolplane <kcp-name> -n cpaas-system \
  -o jsonpath='{.spec.rolloutStrategy.rollingUpdate.maxSurge}{"\n"}'

kubectl get machinedeployment <md-name> -n cpaas-system \
  -o jsonpath='{.spec.strategy.rollingUpdate.maxSurge}{"\n"}'

Каждое возвращаемое значение должно быть 0 для пулов, которые используют постоянные диски.

Если хотя бы одно возвращаемое значение не равно 0, исправьте соответствующую стратегию rollout перед обновлением пула:

kubectl patch kubeadmcontrolplane <kcp-name> -n cpaas-system \
  --type='merge' \
  -p='{"spec":{"rolloutStrategy":{"type":"RollingUpdate","rollingUpdate":{"maxSurge":0}}}}'

kubectl patch machinedeployment <md-name> -n cpaas-system \
  --type='merge' \
  -p='{"spec":{"strategy":{"type":"RollingUpdate","rollingUpdate":{"maxSurge":0}}}}'

#Обновите Machine Configuration Pool

Отредактируйте HCSMachineConfigPool, на который ссылаются старый и новый HCSMachineTemplate.spec.template.spec.configPoolRef.name.

Добавьте одну запись persistentDisks[] под каждым hostname, для которого диск должен сохраняться:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: HCSMachineConfigPool
metadata:
  name: <pool-name>
  namespace: cpaas-system
  labels:
    cluster.x-k8s.io/cluster-name: <cluster-name>
spec:
  configs:
    - hostname: <node-hostname>
      networks:
        - subnetName: <subnet-name>
          ipAddress: <node-ip>
      persistentDisks:
        - slot: 0
          size: 40
          type: SSD
          mountPath: /var/cpaas
          format: xfs
          mountOptions:
            - defaults
            - noatime

При редактировании пула используйте следующие правила:

• Начинайте slot с 0 для каждого hostname.
• Для каждого hostname сохраняйте слоты непрерывными.
• Установите size, type, mountPath и format в соответствии со старым томом данных, который требуется захватить.
• Добавьте cluster.x-k8s.io/cluster-name: <cluster-name>, если такого параметра в пуле еще нет.
• Используйте одинаковое объявление постоянного диска для всех узлов, которые должны сохранять один и тот же путь.

Применяйте обновленный пул только после того, как существует заменяющий шаблон, из dataVolumes[] удалены сохраняемые пути, а стратегия rollout использует maxSurge: 0:

kubectl apply -f hcs-pool-persistent-disk.yaml -n cpaas-system

#Запустите пошаговую замену

После применения обновленного пула немедленно укажите в том же окне обслуживания control plane или worker controller на новый шаблон. Не оставляйте пул, который объявляет постоянные диски /var/cpaas, если активный rollout по-прежнему указывает на старый шаблон, где /var/cpaas также объявлен в dataVolumes[].

Для миграции control plane укажите KubeadmControlPlane на новый шаблон:

kubectl patch kubeadmcontrolplane <kcp-name> -n cpaas-system \
  --type='merge' \
  -p='{"spec":{"machineTemplate":{"infrastructureRef":{"name":"<new-template-name>"}}}}'

Для миграции worker-узлов укажите MachineDeployment на новый шаблон:

kubectl patch machinedeployment <md-name> -n cpaas-system \
  --type='merge' \
  -p='{"spec":{"template":{"spec":{"infrastructureRef":{"name":"<new-template-name>"}}}}}'

Если ссылка на шаблон уже указывает на целевой шаблон и вам нужно принудительно выполнить поочередную замену, задайте rolloutAfter:

kubectl patch kubeadmcontrolplane <kcp-name> -n cpaas-system \
  --type='merge' \
  -p='{"spec": {"rolloutAfter": "'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"}}'

kubectl patch machinedeployment <md-name> -n cpaas-system \
  --type='merge' \
  -p='{"spec": {"rolloutAfter": "'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"}}'

#Проверьте миграцию

Наблюдайте за пошаговой заменой:

kubectl get kubeadmcontrolplane <kcp-name> -n cpaas-system -w
kubectl get machinedeployment <md-name> -n cpaas-system -w
kubectl get machine -n cpaas-system -w
kubectl get hcsmachine -n cpaas-system -w

Проверьте состояние пула:

kubectl get hcsmachineconfigpool <pool-name> -n cpaas-system -o yaml

Каждый перенесенный диск отображается в status.persistentDiskStatus:

Убедитесь, что заменяющий узел может прочитать данные из сохраненного пути:

kubectl --kubeconfig <workload-kubeconfig> debug node/<node-name> --image=busybox -- \
  chroot /host sh -c 'mount | grep /var/cpaas && ls -la /var/cpaas'

Для более надежной проверки сохранения данных запишите маркер до rollout и прочитайте его после того, как заменяющий узел станет Ready:

kubectl --kubeconfig <workload-kubeconfig> debug node/<node-name> --image=busybox -- \
  chroot /host sh -c 'cat /var/cpaas/<marker-file>'

#Обработка сбоев

Используйте состояние пула, чтобы определить следующее действие, когда диск переходит в phase: Error.

Не удаляйте старый HCSMachine и не выполняйте принудительное удаление finalizers, пока постоянный диск находится в неразрешенном состоянии ошибки. Provider блокирует удаление, чтобы не удалить старый ECS до того, как он сможет безопасно забрать и отключить диск.

#Ограничения и примечания по восстановлению

• Эта процедура применяется к кластерам, которые используют HCSMachineConfigPool с фиксированными hostname и IP addresses.
• Постоянные диски, управляемые пулом, требуют поочередной замены. Для каждого rollout control plane или worker, использующего постоянные диски, сохраняйте maxSurge: 0.
• Provider автоматически забирает существующие тома данных, сопоставляя непустой mountPath.
• dataVolumes[], которые не объявлены в persistentDisks[], остаются принадлежащими шаблону и могут быть удалены вместе со старым ECS.
• После того как provider примет запись постоянного диска, считайте slot, size, type, format и mountPath неизменяемыми.
• mountOptions можно изменять, но изменение вступает в силу только на заменяющей VM.
• Кластеры HCS с одним control-plane являются топологиями только для создания в описанном рабочем процессе обновления. Не используйте эту процедуру пошаговой миграции для кластера с одним control-plane.

#Связанные темы

• Infrastructure Resources for Huawei Cloud Stack
• Creating Clusters on Huawei Cloud Stack
• Upgrading Clusters on Huawei Cloud Stack