Миграция в службу Azure Kubernetes (AKS)

Чтобы помочь вам спланировать и успешно выполнить миграцию в Службу Azure Kubernetes (AKS), в этом разделе приводятся подробные сведения о текущей рекомендуемой конфигурации AKS. Хотя в этой статье не рассматриваются все сценарии, она содержит ссылки на более подробные сведения о планировании успешной миграции.

Этот документ поможет реализовать следующие сценарии:

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

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

Некоторые средства с открытым кодом могут помочь при миграции в зависимости от сценария:

В этой статье приводится сводная информация о миграции:

  • Контейнеризация приложений с помощью службы "Миграция Azure"
  • AKS с подсистемой балансировки нагрузки ценовой категории "Стандартный" и Масштабируемые наборы виртуальных машин
  • Существующие подключенные службы Azure
  • Обеспечение допустимых квот
  • Высокая доступность и непрерывность бизнес-процессов
  • Соображения по приложениям без отслеживания состояния
  • Соображения по приложениям с отслеживанием состояния
  • Развертывание конфигурации кластера

Используйте Миграцию Azure для миграции ваших приложений в AKS

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

AKS с подсистемой балансировки нагрузки ценовой категории "Стандартный" и Масштабируемые наборы виртуальных машин

AKS — это управляемая служба, предлагающая уникальные возможности с более низкими затратами на управление. Так как AKS — управляемая служба, необходимо выбрать один из регионов, поддерживаемых AKS. Возможно, потребуется изменить существующие приложения, чтобы они оставались работоспособными на управляемом AKS уровне управления во время перехода с существующего кластера на AKS.

Мы рекомендуем использовать кластеры AKS на основе масштабируемых наборов виртуальных машин и Azure Load Balancer (цен. категория "Стандартный"), чтобы получить следующие возможности:

В кластерах AKS, поддерживающих группы доступности виртуальных машин, отсутствует поддержка многих из этих функций.

В следующем примере создается кластер AKS с одним пулом узлов на базе масштабируемого набора виртуальных машин. Этот кластер:

  • использует подсистему балансировки нагрузки (цен. категория "Стандартный");
  • содержит средство автомасштабирования кластера в пуле узлов для кластера;
  • использует не менее 1 и не более 3 узлов.
# First create a resource group
az group create --name myResourceGroup --location eastus

# Now create the AKS cluster and enable the cluster autoscaler
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --node-count 1 \
  --vm-set-type VirtualMachineScaleSets \
  --load-balancer-sku standard \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Существующие подключенные службы Azure

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

  • Реестр контейнеров Azure
  • Log Analytics
  • Application Insights
  • Диспетчер трафика
  • Учетная запись хранения
  • Внешние базы данных

Обеспечение допустимых квот

Так как прочие виртуальные машины будут развернуты в рамках подписки во время миграции, следует убедиться, что квоты и ограничения достаточны для этих ресурсов. При необходимости запросите увеличение квоты виртуальных ЦП.

Может потребоваться запросить увеличение сетевых квот, чтобы не допустить исчерпания IP-адресов. Дополнительные сведения см. в разделе Использование сети kubenet с пользовательскими диапазонами IP-адресов в Службе Azure Kubernetes (AKS).

Дополнительные сведения см. в статье Подписка Azure и ограничения службы. Чтобы проверить текущие квоты, на портале Azure перейдите к колонке подписок, выберите свою подписку, а затем — Использование + квоты.

Высокая доступность и непрерывность бизнес-процессов

Если ваше приложение должно работать без простоев, вам необходимо следовать лучшим методикам для реализации сценариев миграции с высокой доступностью. Узнайте больше о рекомендациях по комплексному планированию непрерывности бизнес-процессов, аварийному восстановлению и обеспечению максимального времени работы в Службе Azure Kubernetes (AKS).

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

Чтобы завершить миграцию, нужно будет указать на новые службы, работающие в AKS. Для перенаправления трафика рекомендуется обновить DNS, указав на подсистему Load Balancer, которая обслуживает кластер AKS.

Диспетчер трафика Azure может направлять клиентов в нужный кластер Kubernetes и экземпляр приложения. Диспетчер трафика — это подсистема балансировки нагрузки на основе DNS, которая может распределять сетевой трафик между регионами. Чтобы обеспечить оптимальную производительность и избыточность, направляйте весь трафик приложений через диспетчер трафика перед передачей в кластер AKS.

В развертывании с несколькими кластерами клиентам следует подключаться по DNS-имени диспетчера трафика, которое приведет их к службам в каждом кластере AKS. Эти службы определяются через конечные точки диспетчера трафика. Каждая конечная точка имеет IP-адрес службы подсистемы балансировки нагрузки. Такая конфигурация позволяет направить трафик из конечной точки диспетчера трафика в одном регионе в конечную точку в другом регионе.

AKS с Диспетчером трафика

Служба Azure Front Door — это еще один вариант для маршрутизации трафика для кластеров AKS. Azure Front Door Service позволяет определять, управлять и отслеживать глобальную маршрутизацию для вашего веб-трафика, применяя оптимизацию для обеспечения наилучшей производительности и мгновенную глобальную отработку отказа для обеспечения высокой доступности.

Соображения по приложениям без отслеживания состояния

Перенос приложений без отслеживания состояния — это самый простой вариант.

  1. Примените определения ресурсов (в формате YAML или Helm) к новому кластеру.
  2. Убедитесь, что все работает правильно.
  3. Перенаправьте трафик для активации нового кластера.

Соображения по приложениям с отслеживанием состояния

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

Файлы Azure

В отличие от дисков, файлы Azure можно одновременно подключить к нескольким узлам. В кластере AKS службы Azure и Kubernetes не препятствуют созданию контейнера pod, который по-прежнему используется кластером ACS. Чтобы избежать потери данных и непредвиденного поведения, убедитесь, что кластеры не записывают данные в одни и те же файлы одновременно.

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

В противном случае для миграции возможен следующий порядок действий.

  1. Проверьте, правильно ли работает приложение.
  2. Направьте реальный трафик в новый кластер AKS.
  3. Отключите старый кластер.

Если нужно начать с пустой общей папкой, а затем создать копию исходных данных, для переноса данных можно использовать команды az storage file copy.

Миграция постоянных томов

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

  1. Заморозить запись в приложение.
    • Этот шаг является необязательным и требует простоя.
  2. Создать моментальные снимки дисков.
  3. Создать новые управляемые диски из моментальных снимков.
  4. Создать постоянные тома в службе AKS.
  5. Обновить спецификации Pod для использования существующих томов вместо PersistentVolumeClaims (статической подготовки).
  6. Развернуть приложение в AKS.
  7. Проверьте, правильно ли работает приложение.
  8. Направьте реальный трафик в новый кластер AKS.

Важно!

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

Существуют инструменты с открытым кодом, которые помогут создать управляемые диски и перенести тома между кластерами Kubernetes:

Развертывание конфигурации кластера

Мы рекомендуем использовать существующий конвейер непрерывной интеграции (CI) и непрерывной поставки (CD) для развертывания известной работоспособной конфигурации в AKS. Azure Pipelines можно использовать для создания и развертывания приложений в AKS. Следует клонировать существующие задачи развертывания и убедиться, что kubeconfig указывает на новый кластер AKS.

Если это невозможно, экспортируйте определения ресурсов из существующего кластера Kubernetes и примените их к AKS. Для экспорта объектов можно использовать kubectl. Например:

kubectl get deployment -o yaml > deployments.yaml

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

Перемещение существующих ресурсов в другой регион

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

Кроме того, при наличии каких-либо служб, выполняющихся в кластере AKS, необходимо также установить и настроить эти службы в кластере в новом регионе.

В этой статье приводится сводная информация о миграции:

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