Поделиться через

Перемещение кластера Служба Azure Kubernetes (AKS) в другой регион

  • Статья

В этой статье рассматриваются рекомендации по перемещению кластера Служба Azure Kubernetes в другой регион.

Существуют различные причины, по которым может потребоваться переместить существующие ресурсы Azure из одного региона в другой. Возможно, вам потребуется:

  • Воспользуйтесь новым регионом Azure.
  • Развертывание функций или служб, доступных только в определенных регионах.
  • Отвечайте требованиям к внутренней политике и управлению.
  • Согласование слияний и приобретений компании
  • Отвечайте требованиям к планированию емкости.

Примечание.

Клиенты с циклами быстрого выпуска часто используют конвейеры CI/CD. В этих случаях можно изменить конвейеры сборки и выпуска вместо повторного развертывания кластеров AKS в целевом регионе.

Необходимые компоненты

Прежде чем начать этап планирования перемещения, сначала просмотрите следующие предварительные требования:

  • Убедитесь, что целевой регион имеет достаточно емкости (SKU виртуальных машин), чтобы разместить новые узлы кластера.

  • Убедитесь, что у вас есть разрешения на создание ресурсов для целевой подписки. Убедитесь, что политика Azure не ограничивает регионы, в которые можно развернуть AKS.

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

  • Соберите манифесты Kubernetes, чтобы повторно создать рабочую нагрузку приложения в целевом кластере.

    Совет

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

  • Просмотрите реализацию входящего трафика кластера.

  • Задокументируйте изменения DNS, необходимые для указания общедоступного домена на конечную точку входящего трафика кластера.

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

  • Документируйте управление и распространение общедоступных сертификатов TLS.

  • Захват всех IP-адресов, определенных в списке разрешений службы API AKS.

  • Общие сведения обо всех зависимых ресурсах. Некоторые ресурсы могут быть следующими:

    • Очереди, автобусы сообщений, обработчики кэша
    • Azure Key Vault
    • управляемое удостоверение;
    • виртуальная сеть конфигурации. Определение достаточного размера подсети, чтобы разрешить рост IP-адресов контейнера при использовании расширенной сетевой модели Azure
    • Общедоступный IP-адрес
    • шлюз виртуальная сеть (VNG). Если взаимодействие между сайтами требуется для локальной среды в целевом регионе, в целевом регионе необходимо создать виртуальную сеть в целевой виртуальной сети.
    • Частная конечная точка Azure. Ресурсы Azure PaaS, использующие конечные точки приватного канала, должны быть проверены, а новые экземпляры приватного канала, созданные в целевом регионе, например ACR, базе данных SQL Azure, KeyVault и т. д.
    • Шлюз приложений Azure
    • Azure DNS
    • Брандмауэр Azure
    • Azure Monitor (Аналитика контейнеров)
    • Реестр контейнеров Azure может реплицировать образы между экземплярами ACR. Для оптимальной производительности при извлечении образов реестр должен существовать в целевом регионе.

      Примечание.

      Если вы используете Реестр контейнеров Azure для проверки подлинности в реестре контейнеров, новое управляемое удостоверение кластера AKS может быть предоставленной AcrPull ролью RBAC.

    • управляемые диски Azure.
    • Файлы Azure

Подготовить

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

  1. Чтобы разместить узлы и модули pod кластера AKS, при использовании сети Azure CNI разверните виртуальную сеть с большим количеством подсетей достаточного размера.

  2. Если вы используете Azure Key Vault, разверните Хранилище ключей.

  3. Убедитесь, что для развертывания доступны соответствующие сертификаты входящего трафика TLS, в идеале в безопасном хранилище, например Azure Key Vault.

  4. Разверните реестр контейнеров. Синхронизируйте образы исходного реестра автоматически или перестройте и отправьте новые образы в целевой реестр с помощью конвейера или скрипта CI/CD.

  5. Разверните рабочую область Azure Monitor.

  6. (Необязательно) Развертывание Шлюз приложений Azure для обработки трафика входящего трафика Шлюз приложений контроллер входящего трафика (AGIC) может тесно интегрироваться с кластером.

  7. Разверните все источники данных, необходимые рабочей нагрузке кластера, и восстановите или синхронизируйте исходные данные.

  8. Выполните существующие артефакты IaC, определенные в конвейере CI/CD, который использовался для развертывания исходного кластера и служб, от которых она зависит. Измените входные параметры кода или шаблона для повторного развертывания в другой группе ресурсов и регионе Azure.

Повторное развертывание

Разверните кластер AKS без переноса данных, выполнив следующие действия.

  1. Чтобы создать целевую среду в Azure, вручную запустите существующие артефакты IaC на локальной рабочей станции.

  2. Если нет существующих ресурсов IaC, текущая конфигурация кластера может быть экспортирована как шаблон ARM и выполнена в целевом регионе. Шаблоны IaC создаются с нуля или изменяются с помощью Bicep, JSON, Terraform или другого решения.

    Примечание.

    • Приватный канал подключения, подключенные реестры ACR и источники данных рабочей области Azure Monitor в настоящее время не экспортируются с помощью этого метода и поэтому необходимо удалить из созданного шаблона перед выполнением.

  3. Разверните рабочую нагрузку контейнера в кластере AKS, который можно достичь двумя способами:

    • Манифесты извлечения извлекаются из репозитория и применяются контроллером, работающим в кластере, как подход GitOps.
    • Отправка. Манифесты отправляются в кластер с помощью службы API Kubernetes и средства командной строки kubectl из конвейера CI/CD или локальной рабочей станции.

  4. Чтобы обеспечить выполнение нового кластера как ожидающегося, выполните тестирование и проверку.

  5. Измените общедоступные записи DNS, чтобы указать внешний IP-адрес входящего трафика целевого кластера (ОБЩЕДОСТУПНЫй IP-адрес Azure Load Balancer или Шлюз приложений общедоступный IP-адрес).

  6. Развертывание с помощью глобального решения балансировки нагрузки, например Azure DNS или Диспетчер трафика Azure, необходимо добавить регион в конфигурацию.

Повторное развертывание с помощью миграции данных

Рабочие нагрузки AKS, использующие локальное хранилище, такие как постоянные тома, для хранения данных или служб баз данных узла в кластере можно создать резервную копию в исходном кластере и восстановить в целевом кластере. Сведения о том, как выполнять резервное копирование и восстановление, см. в статье "Резервное копирование Служба Azure Kubernetes с помощью Azure CLI".

Связанный контент