Перемещение кластера Azure Kubernetes Service (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). Если взаимодействие между сайтами требуется для локальной среды в целевом регионе, необходимо создать виртуальную шлюзовую сеть (VNG) в целевой виртуальной сети.

    • Частная конечная точка Azure. Ресурсы Azure PaaS, использующие конечные точки приватного соединения, должны быть проверены, а в целевом регионе созданы новые экземпляры приватного соединения, такие как ACR, база данных Azure SQL, KeyVault и т. д.

    • Шлюз приложений Azure

    • Azure DNS

    • Брандмауэр Azure

    • Azure Monitor (Аналитика контейнеров)

    • Реестр контейнеров Azure может реплицировать образы между экземплярами ACR. Для оптимальной производительности при извлечении образов реестр должен существовать в целевом регионе.

      Замечание

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

    • Управляемые диски Azure

    • Файлы Azure

Подготовьте

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

  • Чтобы разместить узлы и модули pod кластера AKS, при использовании сети Azure CNI разверните виртуальную сеть с большим количеством подсетей достаточного размера.
  • Если вы используете Azure Key Vault, разверните Хранилище ключей.
  • Убедитесь, что для развертывания доступны соответствующие сертификаты входящего трафика TLS, в идеале в безопасном хранилище, например Azure Key Vault.
  • Разверните реестр контейнеров. Синхронизируйте образы исходного реестра автоматически или перестройте и отправьте новые образы в целевой реестр с помощью конвейера или скрипта CI/CD.
  • Разверните Azure Monitor рабочую область.
  • (Необязательно) Разверните шлюз приложений Azure для обработки входящего трафика. Контроллер входящего трафика приложения (AGIC) может тесно интегрироваться с кластером.
  • Разверните все источники данных, необходимые рабочей нагрузке кластера, и восстановите или синхронизируйте исходные данные.
  • Выполните существующие артефакты IaC, определенные в конвейере CI/CD, использовавшиеся для развертывания исходного кластера и зависящих от него служб. Измените входные параметры кода или шаблона для повторного развертывания в другой группе ресурсов и регионе Azure.

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

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

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

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

    Замечание

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

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

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

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

  5. Измените общедоступные записи DNS, чтобы указать внешний IP-адрес входа целевого кластера (общедоступный IP-адрес Azure Load Balancer или общедоступный IP-адрес шлюза приложений).

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

Повторное развертывание и миграция данных

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

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

  • Last updated on