/ DOCS
Облако VMware
Тема интерфейса
Managed Kubernetes

Миграция кластера в Evolution Managed Kubernetes

В этой инструкции описано как мигрировать кластер Managed Kubernetes с платформы Облако VMware на платформу Evolution.

Подготовьте инфраструктуру в облаке Evolution

  1. Проверьте, что сервисы Managed Kubernetes, Object Storage и VPC подключены в облаке Evolution и вы можете создавать ресурсы.

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

  3. В Magic Router добавьте маршруты до созданных подсетей, выбрав VPC и AZ, в которой они созданы.

  4. Создайте сервисный аккаунт с ролью k8s.admin. Для работы с объектным хранилищем на сервисный аккаунт необходимо назначить роли s3e.editor и s3e.viewer.

  5. Для сервисного аккаунта создайте ключ доступа и получите Key ID и Key Secret.

  6. Создайте целевой кластер в облаке Evolution такой же размерности, как кластер на платформе Облако VMware.

    Выберите сервисный аккаунт, созданный ранее. Обратите внимание, из кластера должен быть доступ в интернет для запуска подов Velero.

  7. Сохраните kubeconfig целевого кластера и переименуйте его в kubeconfig_evo.

Подготовьте инфраструктуру на платформе Облако VMware

  1. Сохраните kubeconfig кластера, который необходимо перенести, и переименуйте его в kubeconfig_ent.

  2. Определите список подсетей, с которыми необходимо настроить доступ в целевой кластер и из целевого кластера на платформе Evolution. Подсети должны быть доступны через edge клиентского ВЦОД.

  3. Проверьте, что из исходного кластера есть доступ в интернет для запуска подов Velero. Иногда доступ у клиентов платформы Облако VMware в интернет из кластеров отключен.

  4. Создайте МПС в Evolution через сейл-менеджера с указанием идентификатора проекта в Evolution и подсетей платформы Облако VMware.

  5. На Edge клиентского ВЦОД настройте разрешающие правила Firewall для доступа между подсетями Evolution и платформы Облако VMware.

  6. Настройте no-snat правило для подсети Evolution c приоритетом ноль.

  7. На виртуальной машине, расположенной в клиентском ВЦОД, подготовьте в одном каталоге файлы:

    • s3_creds

      [default]
      aws_access_key_id=<tenant_id>:<key_id>
      aws_secret_access_key=<key_secret>

      Где:

      • <tenant_id> — идентификатор тенанта. Его можно посмотреть в сервисе Object Storage в меню бакета на вкладке :guilabel:Object Storage API.

      • <key_id> — значение Key ID сервисного аккаунта, полученное на шаге 6 предыдущего раздела.

      • <key_secret> — значение Key Secret сервисного аккаунта, полученное на шаге 6 предыдущего раздела.

    • evo_velero_change_storage_class_cm.yaml

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: change-storage-class-config
        namespace: velero
        labels:
          velero.io/plugin-config: ""
          velero.io/change-storage-class: RestoreItemAction
      data:
          csi-sbercloud-nd: cloudru-nvme

    • ent_add_annotations_for_LBs.sh

      #/bin/bash
      evo_subnet_id="<evo_network_id>"
      for svc in $(kubectl get svc --all-namespaces -o jsonpath='{range .items[?(@.spec.type=="LoadBalancer")]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}'); do
        namespace=$(echo "$svc" | cut -d '/' -f 1)
        name=$(echo "$svc" | cut -d '/' -f 2)
        kubectl patch svc "$name" -n "$namespace" --patch "{\"metadata\":{\"annotations\":{\"loadbalancer.mk8s.cloud.ru/internal-subnet-id\":\"${evo_subnet_id}\",\"loadbalancer.mk8s.cloud.ru/type\": \"internal\"}}}"
      done

      Где <evo_network_id> — идентификатор подсети, созданной в облаке Evolution.

    • evo_rm_loadbalancerIP_in_svc_spec.sh

      #/bin/bash
      for svc in $(kubectl get svc --all-namespaces -o jsonpath='{range .items[?(@.spec.loadBalancerIP)]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}')
      do
        namespace=$(echo "$svc" | cut -d '/' -f 1)
        name=$(echo "$svc" | cut -d '/' -f 2)
        kubectl patch svc "$name" -n "$namespace" --type json -p='[{"op": "remove", "path": "/spec/loadBalancerIP"}]'
      done

    • kubeconfig_ent

    • kubeconfig_evo

  8. С виртуальной машины:

  9. Проверьте доступ к исходному и целевому кластеру с виртуальной машины.

Перенесите рабочие нагрузки

Внимание

Далее команды выполняются с использованием различных конфигурационных файлов. Контекст передается через команду export KUBECONFIG=<filename>.

  1. Установите Velero в кластер для переноса:

    export KUBECONFIG=kubeconfig_ent && \
    velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.5.2 --bucket ent-to-evo-migration-bucket --secret-file ./s3_creds --backup-location-config region=ru-central-1,s3ForcePathStyle="true",s3Url=https://s3.cloud.ru --use-node-agent --use-volume-snapshots=false --default-volumes-to-fs-backup

  2. Установите Velero в целевой кластер:

    export KUBECONFIG=kubeconfig_evo && \
    velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.5.2 --bucket ent-to-evo-migration-bucket --secret-file ./s3_creds --backup-location-config region=ru-central-1,s3ForcePathStyle="true",s3Url=https://s3.cloud.ru --use-node-agent --use-volume-snapshots=false --default-volumes-to-fs-backup

  3. Примените манифест ConfigMap для изменения StorageClass при восстановлении в целевой кластер:

    kubectl apply -f evo_velero_change_storage_class_cm.yaml --kubeconfig kubeconfig_evo

  4. Для успешной миграции сервисов типа LoadBalancer необходимо добавить нужные аннотации перед резервным копированием и удалить прописанные в спецификации loadBalancerIP после восстановления в целевом кластере:

    export KUBECONFIG=kubeconfig_ent && \
    bash ent_add_annotations_for_LBs.sh

    Сервисы типа LoadBalancer в Managed Kubernetes на Evolution создаются немного иначе, чем в Managed Kubernetes в облаке Облако VMware. В Evolution сервису нельзя назначить определенный IP. Адрес назначается автоматически из указанной сети.

  5. Запустите резервное копирование необходимых пространств имен:

    export KUBECONFIG=kubeconfig_ent && \
    velero backup create < backup_name > --include-namespaces <namespace_1>,<namespace_2>,...

    Где <namespace_1>,<namespace_2> — список пространств имен для миграции.

    Статус создания копии можно отслеживать командой:

    watch --color velero backup describe <backup_name>

  6. Проверьте наличие резервной копии:

    export KUBECONFIG=kubeconfig_evo && \
    velero backup get

    Резервная копия может появиться не сразу. Время зависит от объема бэкапов.

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

    export KUBECONFIG=kubeconfig_evo && \
    velero restore create --from-backup <backup_name>

    Статус восстановления из копии можно отслеживать командой:

    watch --color velero restore describe <restore_name>

    Где <restore_name> — уникальное имя восстановления вида <backup_name>-xxxxxxxxxxxxxx, выдается после запуска восстановления.

  8. Удалите loadBalancerIP в спецификациях восстановленных сервисов:

    export KUBECONFIG=kubeconfig_evo && \
    bash evo_rm_loadbalancerIP_in_svc_spec.sh

    Сервисам назначатся IP-адреса из выбранной подсети Evolution.

  9. Настройте NAT-правила на Edge клиентского VDC для доступа к новому сервису, развернутого в Evolution. Дополнительно необходимо создать Firewall-правила для доступа снаружи к опубликованным сервисам.

  10. После запуска подов в целевом кластере проверьте корректность мигрированных данных и работы сервисов.

Сервисы, развернутые в старом кластере с помощью операторов (CloudNativePG, Strimzi и других), нельзя перенести подобным образом. Используйте штатные механизмы миграции базы данных.

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

Предыдущая статья
Управление кластерами в Managed Kubernetes на платформе Облако VMware
Следующая статья
Создание кластера Kubernetes
Была ли эта статья полезна?
Поддержка Юридические документы
© 2025 Cloud.ru