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

Используйте это руководство, если вы обновляете существующий кластер Huawei DCS со старой схемы template-disk до текущей модели постоянных дисков, управляемых пулом.

В DCS provider v1.0.16 или более поздней версии эта миграция выполняется на основе YAML, поскольку DCSIpHostnamePool.spec.pool[].persistentDisk не доступен в веб-интерфейсе.

#Обзор

В старых кластерах DCS повторно используемые data disks создавались через DCSMachineTemplate. Такая схема не предоставляет controller достаточно информации, чтобы безопасно сохранить диски во время замены через delete-recreate.

В текущей модели диски, сохраняемые при обновлении, переносятся в DCSIpHostnamePool.spec.pool[].persistentDisk. Каждый диск привязывается к идентичности (ip, slot). Во время rolling replacement controller:

1. Захватывает существующий диск у старой VM.
2. Безопасно останавливает старую VM.
3. Отсоединяет диск.
4. При необходимости преобразует stock volumes в независимые persistent volumes.
5. Удаляет старую VM.
6. Повторно подключает диск к VM-замене.
7. Загружает VM-замену, которая монтирует существующую файловую систему без повторного форматирования.

Это также документированная модель для обязательного платформой диска /var/cpaas.

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

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

• Кластер исправен и в настоящее время стабилен.
• Поскольку для pool-managed persistent disks требуется поочередная замена, соответствующие стратегии обновления control plane и worker используют maxSurge: 0.
• Вы можете определить текущие значения sequenceNum для дисков на старых VM через DCS UI или запросив сведения о VM через DCS API.
• Вы знаете, какие диски необходимо сохранить, а какие по-прежнему можно пересоздать вместе с VM.
• Целевой DCSIpHostnamePool уже существует и сопоставляет каждый узел с фиксированным IP slot.

#Проверьте текущую схему дисков

Сначала определите объекты management-cluster и DCS VM, которая обслуживает каждый узел:

kubectl get kubeadmcontrolplane -n cpaas-system
kubectl get machinedeployment -n cpaas-system
kubectl get machine -n cpaas-system
kubectl get dcsmachine -n cpaas-system
kubectl get dcsiphostnamepool -n cpaas-system

Для любого DCSMachine, который вы планируете мигрировать, изучите текущие сведения о VM и зафиксируйте sequenceNum диска, размер, datastore и тип PCI для каждого диска, который вы хотите сохранить.

Эти сведения можно получить из следующих источников:

• DCS platform UI.
• Ваших существующих operational tools, которые оборачивают QueryVmInfo.
• Прямого API-инспектирования, если в вашей среде уже доступен такой сценарий.

Для каждого сохраняемого диска нужны следующие значения:

• Старый sequenceNum
• quantityGB
• datastoreName или datastoreClusterName
• path
• format
• pciType

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

Существующие кластеры могут захватывать только те диски, которые находятся в хвостовой непрерывной области старой схемы дисков VM.

Используйте следующую формулу:

slot = oldSequenceNum - systemDiskCount - newTemplateDataDiskCount - 1

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

• systemDiskCount = 1
• newTemplateDataDiskCount = количество не системных дисков, которые остаются в новом DCSMachineTemplate

Вычисленный slot должен:

• Быть больше или равен 0
• Быть уникальным в пределах одной записи IP

Если диск не находится в хвостовой непрерывной области, вам нужно либо:

• Переместить в список pool-managed persistent-disk также диски между ним и хвостом старого template, либо
• Принять, что незахватываемый диск все равно будет потерян вместе со старой VM

#Пример расчета

Предположим, что порядок дисков в старом template такой:

Если новый template оставляет только system + /var/lib/kubelet + /var/lib/containerd, то newTemplateDataDiskCount = 2.

#Обновите DCSMachineTemplate

Отредактируйте текущий DCSMachineTemplate на месте так, чтобы он больше не объявлял диски, которые вы хотите сохранить.

1. Экспортируйте текущий template:

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

2. Обновите экспортированный manifest:

   • Оставьте system disk.
   • Оставьте только те template-local диски, которые по-прежнему должны пересоздаваться вместе с VM.
   • Удалите все диски, которые вы хотите сохранить через IP pool.
   • Если целевой диск можно захватить только при переносе и хвостовых дисков, удалите эти хвостовые диски из template тоже.
   • Сохраните исходный metadata.name, потому что эта миграция обновляет текущий используемый template на месте.
   • Удалите временные поля metadata, такие как resourceVersion, uid, creationTimestamp и managedFields.

3. Примените обновленный template:

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

#Обновите DCSIpHostnamePool

Добавьте записи persistentDisk в соответствующий IP slot для каждого сохраненного диска.

Spec взаимодействует с атрибутами живого диска тремя способами:

Строгое соответствие при захвате. Несоответствие любого из этих полей приводит к неудачному захвату и устанавливает phase=Error с lastError. Controller повторяет попытку с медленным интервалом, пока spec не будет исправлен:

• quantityGB — должен точно совпадать с фактическим размером диска
• datastoreName или datastoreClusterName — должно указывать на тот же storage target, что и у фактического диска
• pciType — должен совпадать с фактическим типом PCI диска. Если поле не указано, provider использует значение по умолчанию VIRTIO; перед тем как опускать это поле, проверьте фактический тип PCI диска, потому что диск с типом, отличным от VIRTIO, может не пройти строгое соответствие при захвате

isThin используется только при создании. Оно отправляется только тогда, когда provider создает новый DCS persistent volume. Во время захвата существующего тома оно не сравнивается и не преобразует существующие тома.

Файловая система (влияет на инициализацию на стороне guest, а не на проверку захвата):

• format — используется только при инициализации нового диска. Если на фактическом диске уже есть файловая система, существующий формат сохраняется и mkfs пропускается.

Сторона guest (применяется только на VM-замене, не входит в проверку захвата):

• path — путь монтирования внутри guest
• mountOptions — параметры монтирования
• options — параметры mkfs, применяемые только при первом форматировании

Для обязательного платформой диска /var/cpaas перенесите его в layout, управляемый пулом, в рамках этой миграции.

Установите slot в значение, вычисленное в предыдущем разделе. Не используйте одно и то же фиксированное примерное значение для разных схем дисков.

Пример:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DCSIpHostnamePool
metadata:
  name: <iphostname-pool-name>
  namespace: cpaas-system
spec:
  pool:
  - ip: "<node-ip>"
    mask: "<mask>"
    gateway: "<gateway>"
    dns: "<dns>"
    hostname: "<hostname>"
    machineName: "<machine-name>"
    persistentDisk:
    - slot: <calculated-slot>
      quantityGB: 40
      datastoreClusterName: <datastore-cluster-name>
      path: /var/cpaas
      format: xfs
      pciType: VIRTIO

Примените обновление пула:

kubectl apply -f <updated-pool-file>.yaml -n cpaas-system

#Запустите rolling upgrade

Перед запуском замены:

• Убедитесь, что KubeadmControlPlane.spec.rolloutStrategy.rollingUpdate.maxSurge = 0
• Убедитесь, что у каждого MachineDeployment.spec.strategy.rollingUpdate.maxSurge = 0

Эти параметры являются предварительными условиями для миграции, а также для последующего повторного использования pool-managed persistent disks во время upgrade.

Затем запустите rollout:

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)"'"}}'

#Проверьте захват, отсоединение, преобразование и повторное подключение

Наблюдайте за ресурсами management-cluster во время rollout:

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

Проверьте status пула, чтобы убедиться, что controller захватил диски и отслеживает их:

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

Во время перехода каждая запись отображается в status.persistentDiskStatus. Стабильные фазы, за которыми следует следить:

• phase: Attached, пока старая VM по-прежнему владеет диском
• phase: Available после отсоединения диска (и преобразования из stock volume в независимый persistent volume, если это требуется)
• phase: Attached снова после того, как VM-замена повторно подключит диск

Промежуточные фазы (Attaching, Detaching) могут кратковременно появляться во время соответствующих операций; Deleting появляется, когда диск удаляется окончательно, например во время очистки пула или кластера. Полный набор фаз: Creating, Available, Attaching, Attached, Detaching, Deleting, Error.

Если диск переходит в phase: Error, перед повторной попыткой проверьте lastError.

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

• В сценарии миграции существующего кластера можно захватывать только хвостовые непрерывные диски.
• Controller защищает только те диски, которые объявлены в persistentDisk. Любой необъявленный диск по-прежнему следует жизненному циклу VM и может быть удален вместе со старой VM.
• Эта миграция изменяет модель владения сохраненными дисками. Не определяйте один и тот же диск одновременно в DCSMachineTemplate и DCSIpHostnamePool.
• Если вам нужно сохранить /var/cpaas, перенесите его в IP pool в рамках этой миграции, а не оставляйте в template.
• Этот runbook применяется к кластерам на ACP v4.2.1 или более поздней версии, которые переходят на DCS provider v1.0.16 или более поздней версии.

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

• Инфраструктурные ресурсы для Huawei DCS
• Обновление Kubernetes на Huawei DCS