Миграция из публичного облака в Managed Service for Kubernetes

В этом руководстве описан перенос рабочих нагрузок Kubernetes из управляемого сервиса другого облачного провайдера в Managed Service for Kubernetes.

Ключевой принцип миграции — поэтапный перенос с параллельной работой кластеров. Это позволяет минимизировать влияние на production-сервисы и сохранить возможность отката.

Чтобы перенести рабочие нагрузки в Managed Service for Kubernetes:

1. Разработайте план миграции.
2. Подготовьте инфраструктуру Yandex Cloud.
3. Перенесите образы контейнеров.
4. Перенесите stateful-нагрузки.
5. Перенесите stateless-нагрузки.
6. Настройте балансировщики и переключите DNS.
7. Завершите миграцию.

Необходимые платные ресурсыНеобходимые платные ресурсы

• Мастер Managed Service for Kubernetes (тарифы Managed Service for Kubernetes).
• Узлы кластера Managed Service for Kubernetes: использование вычислительных ресурсов и хранилища (тарифы Yandex Compute Cloud).
• Публичные IP-адреса для мастера и узлов кластера Managed Service for Kubernetes, если для них включен публичный доступ (тарифы Yandex Virtual Private Cloud).
• Каждый активный L7-балансировщик, если используется контроллер Gwin: использование вычислительных ресурсов (тарифы Application Load Balancer).
• Каждый сетевой балансировщик, если используются Service типа LoadBalancer: обработанный балансировщиком входящий и исходящий трафик (тарифы Yandex Network Load Balancer).
• Сервис Container Registry: хранение перенесенных Docker-образов (тарифы Container Registry).
• Бакет Object Storage: использование хранилища и выполнение операций с данными (тарифы Yandex Object Storage).
• Трансферы Data Transfer, если используется перенос управляемых баз данных (тарифы Yandex Data Transfer).

Перед началом работыПеред началом работы

Зарегистрируйтесь в Yandex Cloud и создайте платежный аккаунт:

1. Перейдите в консоль управления, затем войдите в Yandex Cloud или зарегистрируйтесь.
2. На странице Yandex Cloud Billing убедитесь, что у вас подключен платежный аккаунт, и он находится в статусе ACTIVE или TRIAL_ACTIVE. Если платежного аккаунта нет, создайте его и привяжите к нему облако.

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

Подробнее об облаках и каталогах.

Разработайте план миграцииРазработайте план миграции

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

Проведите инвентаризацию рабочих нагрузокПроведите инвентаризацию рабочих нагрузок

Получите список ресурсов исходного кластера для всех пространств имен — приложения, версии, зависимости, сетевые правила. Заранее ознакомьтесь с полным планом миграции, чтобы определить последовательность переноса ресурсов.

Убедитесь, что все stateful-нагрузки — управляемые базы данных, StatefulSets с PersistentVolume — имеют актуальные резервные копии.

Команда для выгрузки полного списка ресурсов из исходного кластера:

for ns in $(kubectl get ns --no-headers -o custom-columns=':metadata.name'); do
  echo "=== Namespace: $ns ==="
  kubectl get deploy,sts,ds,job,cronjob,svc,ingress,pvc,cm,secret,hpa,pdb -n $ns
done

Чек-лист инвентаризации:

Оцените совместимостьОцените совместимость

Чтобы компоненты кластера корректно работали после миграции, предварительно оцените их совместимость с целевым кластером. Составьте список изменений, которые нужно внести в манифесты, а также план замены несовместимых компонентов исходного кластера на аналогичные в Yandex Cloud.

Объем изменений зависит от разницы версий Kubernetes в исходном и целевом кластерах. Чем больше разница, тем больше изменений потребуется — могут отличаться как вендор-специфичные CRD, так и стандартные API-группы Kubernetes. Поддерживаемые версии смотрите в разделе Поддержка версий Kubernetes.

При оценке особенно обратите внимание на следующие моменты:

• Проверьте наличие вендор-специфичных CRD исходного кластера, которые могут быть недоступны в Yandex Cloud. Замените компоненты сервисами Yandex Cloud или решениями из Yandex Cloud Marketplace.
• PodSecurityPolicy удалены в Kubernetes версий 1.25 и выше. Если вы используете PodSecurityPolicy в исходном кластере, мигрируйте на PodSecurity Admission.
• В манифестах замените классы хранилищ (storageClassName) на те, которые поддерживаются в Managed Service for Kubernetes.
• Для L7-балансировки рекомендуется использовать контроллер Gwin.

Составьте план переноса сервисовСоставьте план переноса сервисов

Определите порядок переноса сервисов — начинайте с наименее критичных, заканчивайте production-нагрузками. Для переключения трафика используйте стратегию сине-зеленого развертывания (blue-green deployment) без простоя или поэтапное переключение с окном обслуживания.

Учитывайте следующие критические моменты:

• Проведите полный цикл миграции на staging-среде перед переносом в production.
• Подготовьте план отката на случай критических проблем и согласуйте его с командой заранее.
• Координируйте работу с командами разработки и поддержки на всех этапах.
• Выберите часы минимальной нагрузки для выполнения миграции.
• Следите за метриками до, во время и после миграции с помощью Yandex Monitoring.

Подготовьте инфраструктуру Yandex CloudПодготовьте инфраструктуру Yandex Cloud

Подготовьте целевую среду в Yandex Cloud для переноса нагрузок.

Настройте доступы и праваНастройте доступы и права

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

Создайте сетевую инфраструктуруСоздайте сетевую инфраструктуру

Настройте сетевую инфраструктуру, необходимую для работы кластера, — изолированную сеть с настроенными правилами безопасности для всех типов трафика кластера.

1. Создайте VPC и подсети в трех зонах для обеспечения высокой доступности.
2. Создайте группы безопасности для изоляции трафика кластера, узлов и входящих соединений. Всего создается пять групп.

Создайте кластер Managed Service for KubernetesСоздайте кластер Managed Service for Kubernetes

1. Создайте кластер Managed Service for Kubernetes. Выбирайте версию Kubernetes не ниже версии в исходном кластере.
2. Создайте группу узлов в каждой зоне доступности.

Перенесите образы контейнеровПеренесите образы контейнеров

Последовательно перенесите образы контейнеров в Yandex Container Registry с сохранением тегов и метаданных.

В качестве альтернативного сервиса для хранения образов можно использовать Yandex Cloud Registry. В отличие от Yandex Container Registry, Cloud Registry предназначен для хранения не только Docker-образов, но и других типов артефактов.

Перенесите stateful-нагрузкиПеренесите stateful-нагрузки

Перенос stateful-нагрузок — управляемых баз данных, StatefulSets с PersistentVolumes — является самым сложным шагом миграции, так как они хранят данные и их нельзя пересоздать без потерь.

Перенесите управляемые базы данныхПеренесите управляемые базы данных

Для переноса управляемых баз данных используйте Yandex Data Transfer. Сервис позволяет перенести данные с сохранением рабочего состояния источника и минимизировать время простоя для использующих его приложений.

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

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

Перенесите StatefulSets с PersistentVolumesПеренесите StatefulSets с PersistentVolumes

Для переноса StatefulSets с PersistentVolumes используйте Velero с резервным копированием файловой системы через node-agent (бывший kopia). Этот способ работает с любыми PVC и не зависит от CSI-провайдера.

Порядок действий:

1. Создайте бакет в Yandex Object Storage для хранения резервных копий.

2. Создайте файл credentials-velero с данными статического ключа доступа для сервисного аккаунта, имеющего доступ к бакету:

   [default]
   aws_access_key_id = <идентификатор_ключа>
   aws_secret_access_key = <секретный_ключ>
   

3. Установите Velero CLI на машину, с которой будет выполняться перенос и есть kubectl-доступ к исходному и целевому кластерам.

   Совет

   Версия плагина velero-plugin-for-aws в командах ниже может быть устаревшей. Актуальную версию смотрите в документации Velero.

4. Установите Velero в исходном кластере:

   1. Убедитесь, что активен контекст исходного кластера:

      kubectl config current-context
      

   2. Создайте пространство имен для Velero:

      kubectl create namespace velero
      

   3. Установите Velero:

      velero install \
        --provider aws \
        --plugins velero/velero-plugin-for-aws:v1.14.0 \
        --bucket <имя_бакета> \
        --secret-file ./credentials-velero \
        --backup-location-config \
          region=ru-central1,s3ForcePathStyle=true,s3Url=https://storage.yandexcloud.net \
        --use-volume-snapshots=false \
        --use-node-agent \
        --uploader-type=kopia
      

      Где:

      • --provider aws — использует плагин AWS, совместимый с Object Storage.
      • --use-node-agent — включает DaemonSet для резервного копирования файловой системы.
      • --uploader-type=kopia — рекомендуемый загрузчик, работает быстрее restic.
      • --use-volume-snapshots=false — отключает CSI-снапшоты, данные переносятся через kopia.

   4. Проверьте статус компонентов:

      kubectl get pods -n velero
      kubectl get backupstoragelocation -n velero
      velero backup-location get
      

      BackupStorageLocation должен перейти в статус Available.

5. Создайте резервную копию нужных пространств имен:

   velero backup create migration-backup \
     --include-namespaces <пространство_имен> \
     --default-volumes-to-fs-backup \
     --wait
   

   Проверить статус и логи можно командами:

   velero backup describe migration-backup --details
   velero backup logs migration-backup
   

6. Установите Velero в целевом кластере Managed Service for Kubernetes:

   1. Переключитесь на контекст целевого кластера:

      kubectl config use-context <контекст_целевого_кластера>
      

   2. Создайте пространство имен для Velero:

      kubectl create namespace velero
      

   3. Установите Velero с теми же параметрами, что и в исходном кластере, указав тот же бакет:

      velero install \
        --provider aws \
        --plugins velero/velero-plugin-for-aws:v1.14.0 \
        --bucket <имя_бакета> \
        --secret-file ./credentials-velero \
        --backup-location-config \
          region=ru-central1,s3ForcePathStyle=true,s3Url=https://storage.yandexcloud.net \
        --use-volume-snapshots=false \
        --use-node-agent \
        --uploader-type=kopia
      

   4. Убедитесь, что резервная копия из исходного кластера видна в целевом:

      kubectl get pods -n velero
      velero backup-location get
      velero backup get
      

      BackupStorageLocation должен перейти в статус Available, а резервная копия migration-backup — в статус Completed.

7. Восстановите данные из резервной копии:

   velero restore create \
     --from-backup migration-backup \
     --wait
   

   Проверить статус и логи можно командами:

   velero restore describe migration-backup --details
   velero restore logs migration-backup
   

   Совет

   Если StorageClass в исходном кластере и Managed Service for Kubernetes называются по-разному, создайте ConfigMap с маппингом StorageClass до запуска восстановления:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: change-storage-class-config
     namespace: velero
     labels:
       velero.io/plugin-config: ""
       velero.io/change-storage-class: RestoreItemAction
   data:
     <исходный_storage_class>: yc-network-ssd
   

Перенесите stateless-нагрузкиПеренесите stateless-нагрузки

Для переноса stateless-нагрузок экспортируйте манифесты исходного кластера, адаптируйте для применения в Yandex Cloud и примените в целевом кластере.

Чек-лист адаптации манифестов:

• Вендор-специфичные CRD заменены сервисами Yandex Cloud или решениями из Yandex Cloud Marketplace.
• Устаревшие apiVersion заменены на актуальные для целевой версии Kubernetes.
• Контроллер Gwin (gwin-default) используется в ingressClassName и gatewayClassName.
• Аннотации ресурсов для настройки балансировщика нагрузки заменены на аннотации Yandex Cloud.
• Ссылки на образы ведут в Yandex Container Registry (cr.yandex/<id>/...).

Для очистки манифестов можно использовать утилиту kubectl-neat.

Настройте балансировщики и переключите DNSНастройте балансировщики и переключите DNS

Переключите трафик на новый кластер.

Managed Service for Kubernetes поддерживает два способа балансировки:

• Gwin.
• Network Load Balancer — создается автоматически для Service типа LoadBalancer.

Порядок переключения трафика:

1. Разверните Gateway или Ingress-ресурсы в кластере Managed Service for Kubernetes.
2. Получите внешние IP-адреса новых балансировщиков.
3. Проверьте работу сервисов через тестовые DNS-записи.
4. Снизьте TTL production DNS-записей заранее, затем поэтапно обновите их.
5. Следите за распространением DNS и обновлением TLS-сертификатов.

Завершите миграциюЗавершите миграцию

Завершите миграцию и оптимизируйте конфигурацию.

1. Убедитесь, что все сервисы работают корректно в Managed Service for Kubernetes.
2. Проверьте метрики и производительность в Yandex Monitoring.
3. Отключите ресурсы в исходном облаке после подтверждения стабильной работы.
4. Оптимизируйте конфигурацию кластера под реальную нагрузку.
5. Удалите промежуточные ресурсы: бакет Velero, трансферы Data Transfer, VPN-туннели, временные учетные данные.