Перенос рабочей нагрузки после миграции ресурсов

Это руководство поможет вам завершить перенос своей рабочей нагрузки (workload) после того, как сотрудники VK Cloud завершат работы по миграции ресурсов кластера первого поколения между зонами доступности. Вы выполните следующие шаги:

1. Определите, зависит ли ваша рабочая нагрузка (workload) от старой зоны доступности, так как в таком случае метаданные вашей рабочей нагрузки продолжат ссылаться на нее.
2. Адаптируете рабочую нагрузку на уже смигрированных группах worker-узлов под новую зону доступности.
3. Перенесете stateful-нагрузку на новые PVC.
4. Если привязка к зоне доступности была установлена в helm-чартах или при настройке аддонов, обновите эти значения на новую зону доступности.

1. Перейдите в кластер первого поколения, ресурсы которого были перенесены на другую зону доступности.

2. Установите и настройте kubectl, если это еще не сделано.

3. Подключитесь к кластеру при помощи kubectl.

4. (Опционально) Установите утилиту для переименования PVC rename-pvc.

Определите, повлияет ли миграция на рабочую нагрузку (workload) ваших кластеров. Для этого узнайте, указана ли зона доступности:

• в правилах планирования пода:

  • в параметрах nodeAffinity, topologySpreadConstraints или nodeSelector;
  • в метках topology.kubernetes.io/zone,failure-domain.beta.kubernetes.io/zone и topology.cinder.csi.openstack.org/zone.

• в классе хранения (StorageClass) для подов StatefulSet.

Если зона доступности не указана, миграция на другую зону доступности никак не повлияет на вашу рабочую нагрузку и дополнительных действий по переносу от вас не потребуется.

1. Дождитесь окончания работ по миграции ресурсов со стороны VK Cloud.

   Узлы смигрированных групп worker-узлов (то есть тех, которые были созданы до миграции) будут иметь следующие метки, указывающие на старую зону доступности:

   • topology.kubernetes.io/zone,
   • failure-domain.beta.kubernetes.io/zone.

   Эти метки необходимо обновить, так как сам узел физически будет находиться уже в новой зоне доступности.

   Метку topology.cinder.csi.openstack.org/zone обновлять не нужно: в ней новая зона доступности будет установлена для узлов, созданных как до, так и после миграции.

2. Обновите зоны доступности в метках:

   Для отдельных узлов

   Для всех узлов

    
   kubectl label node ≠ \       topology.kubernetes.io/zone=<НОВАЯ_ЗОНА_ДОСТУПНОСТИ> \       failure-domain.beta.kubernetes.io/zone=<НОВАЯ_ЗОНА_ДОСТУПНОСТИ> \       --overwrite

   Здесь <НОВАЯ_ЗОНА_ДОСТУПНОСТИ> — зона доступности после миграции.

    
   kubectl label nodes -l topology.kubernetes.io/zone=<СТАРАЯ_ЗОНА_ДОСТУПНОСТИ>,failure-domain.beta.kubernetes.io/zone=<СТАРАЯ_ЗОНА_ДОСТУПНОСТИ> \       topology.kubernetes.io/zone=<НОВАЯ_ЗОНА_ДОСТУПНОСТИ> \       failure-domain.beta.kubernetes.io/zone=<НОВАЯ_ЗОНА_ДОСТУПНОСТИ> \       --overwrite

   Здесь:

   • <СТАРАЯ_ЗОНА_ДОСТУПНОСТИ> — зона доступности до миграции;
   • <НОВАЯ_ЗОНА_ДОСТУПНОСТИ> — зона доступности после миграции.

   Новая зона доступности для обеих меток должна быть одна и та же.

Так как работы по миграции ресурсов со стороны VK Cloud уже завершены, диски, на которых расположены PV, уже физически изменили свою зону. Теперь вам нужно актуализировать их метаданные в кластере.

Чтобы перенести stateful-нагрузку на PVC в новой зоне доступности,

1. Подготовьте PVC.
2. Перенесите нагрузку одним из предложенных способов.

Чтобы предотвратить случайное удаление данных с PVC при переносе нагрузки:

1. Поменяйте политику освобождения (reclaim policy) PV на Retain:

    
   pv_name=$(kubectl get pvc <ИМЯ_PVC> -n <ПРОСТРАНСТВО_ИМЕН_PVC> -o jsonpath='{.spec.volumeName}') kubectl patch pv "$pv_name" -n <ПРОСТРАНСТВО_ИМЕН_PVC> -p '{"spec": {"persistentVolumeReclaimPolicy": "Retain"}}'

   Здесь:

   • <ИМЯ_PVC> — имя PVC, который вы хотите перенести.
   • <ПРОСТРАНСТВО_ИМЕН_PVC> — пространство имен, в котором PVC расположен.

2. Клонируйте диск, связанный с PVC.

3. (Опционально) Сохраните старый PVC до окончания работ по миграции, переименовав его в <ИМЯ_PVC>-old, чтобы иметь возможность вернуться к нему при необходимости.

   Когда будете создавать новый PVC, используйте <ИМЯ_PVC> — так он получит имя оригинального смигрированного.

   Вы можете переименовать PVC вручную или с помощью утилиты rename-pvc. Пример команды для rename-pvc:

    
   rename-pvc -n <ПРОСТРАНСТВО_ИМЕН_PVC> <СТАРОЕ_ИМЯ_PVC> <НОВОЕ_ИМЯ_PVC>

Доступны несколько способов переноса PVC:

• с помощью снимка диска (через личный кабинет VK Cloud или через плагин Cinder CSI);
• с помощью утилиты pv-migrate;
• с помощью ID диска.

1. Проверьте, была ли привязка к зонам доступности дополнительно установлена через Helm-чарты или при редактировании кода аддона в личном кабинете VK Cloud.

2. Если да, вручную укажите для них зону доступности, куда была выполнена миграция. Это нужно, чтобы при следующем обновлении манифестов результаты миграции не были перезаписаны.

   Helm-чарты

   Аддоны

   1. Укажите зону доступности, куда была выполнена миграция, в values.yaml:

       
      topology:  zone: <ЗОНА_ДОСТУПНОСТИ>

   2. Примените обновление. Подробнее в официальной документации Helm.

   1. Перейдите в личный кабинет VK Cloud.
   2. Выберите проект, где находится нужный кластер первого поколения.
   3. Перейдите в раздел Контейнеры → Кластеры Kubernetes.
   4. Нажмите на имя нужного кластера.
   5. Перейдите на вкладку Аддоны.
   6. Нажмите для аддона, код которого нужно отредактировать, и выберите пункт Редактировать.
   7. Внесите необходимые изменения и нажмите кнопку Изменить настройки.

Работающие ресурсы в кластере тарифицируются и потребляют вычислительные ресурсы. Если вы не планируете использовать PVC и снимки диска, оставшиеся после миграции, а также саму зону доступности, удалите их и связанные с ними ресурсы:

1. Удалите старый PVC и снимки диска.

2. Удалите класс хранения (StorageClass) старой зоны доступности:

    
   kubectl get sc -o name | grep <СТАРАЯ_ЗОНА_ДОСТУПНОСТИ> | xargs -I {} kubectl delete {}

   Здесь <СТАРАЯ_ЗОНА_ДОСТУПНОСТИ> — имя зоны доступности, из которой была проведена миграция, указанная в нижнем регистре.