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

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

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

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

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 → Кластеры Kubernetes.
   4. Нажмите на имя нужного кластера.
   5. Перейдите на вкладку Аддоны.
   6. Нажмите для аддона, код которого нужно отредактировать, и выберите пункт Редактировать.
   7. Внесите необходимые изменения и нажмите кнопку Изменить настройки.

Если вы управляете ресурсами кластера через Terraform, после переноса кластера синхронизируйте Terraform State с фактической инфраструктурой:

1. Добавьте в ресурс кластера vkcs_kubernetes_cluster блок lifecycle:

    
   lifecycle {  prevent_destroy = true}

   Это предотвратит пересоздание или удаление кластера, если в файле конфигурации или Terraform State останутся несинхронизированные поля.

2. Привяжите кластер к ресурсу vkcs_kubernetes_cluster, используя данные из файла конфигурации Terraform:

    
   terraform import vkcs_kubernetes_cluster.<ИМЯ_РЕСУРСА> <ID_КЛАСТЕРА>

3. Привяжите каждую группу узлов к ресурсу vkcs_kubernetes_node_group:

    
   terraform import vkcs_kubernetes_node_group.<ИМЯ_РЕСУРСА> <ID_ГРУППЫ_УЗЛОВ>

4. Посмотрите, какие параметры появились у новых ресурсов, и добавьте их в файл конфигурации Terraform:

    
   terraform state show <РЕСУРС>.<ИМЯ_РЕСУРСА>

5. Если в группе узлов включено автомасштабирование, значение параметра node_count из файла Terraform может расходиться с реально используемым количеством узлов. Добавьте блок lifecycle в ресурс группы узлов:

    
   lifecycle {  ignore_changes = [node_count]}

   Так Terraform не будет отслеживать изменения параметра node_count, которое автоматически меняется при автомасштабировании.

6. Сгенерируйте файл изменений и убедитесь, что он не содержит указаний на пересоздание ресурсов:

    
   terraform plan

   Если вывод команды показывает No changes, то файл конфигурации и Terraform State полностью синхронизированы. Если вывод все еще показывает изменения, продолжайте синхронизацию до тех пор, пока вывод команды не покажет No changes.

   Если вывод команды предлагает операции пересоздания ресурса по полям availability_zone или availability_zones:

   1. Узнайте актуальное значение поля в конфигурации с помощью команды:

       
      terraform state show <РЕСУРС>.<ИМЯ_РЕСУРСА>

   2. Обновите значение в файле конфигурации Terraform.

7. Удалите ранее добавленный блок lifecycle с параметром prevent_destroy = true из ресурса кластера.

Подробнее в разделе Использование Terraform и документации Terraform-провайдера.

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

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

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

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

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