Миграция из групп доступности в службе Azure Kubernetes (AKS)

В этой статье описано, как служба Azure Kubernetes (AKS) отказывается от поддержки групп доступности виртуальных машин (VMAS) в пользу виртуальных машин. Мы рекомендуем использовать пулы узлов виртуальных машин , оптимизированных для AKS.

Пулы узлов виртуальной машины:

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

Это важно

Начиная с 30 сентября 2025 г. служба Azure Kubernetes (AKS) больше не поддерживает группы доступности. Кластеры с группами доступности после этой даты считаются неподдерживаемыми. Перенесите все рабочие нагрузки в пулы узлов виртуальных машин до этой даты, чтобы обеспечить постоянную поддержку и воспользоваться расширенными функциями управления. Для получения дополнительной информации об этом снятии с поддержки, см. соответствующую проблему на GitHub. Чтобы оставаться в курсе объявлений и обновлений, следуйте заметкам о выпуске AKS.

Обзор наборов доступности

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

Поэтапный отказ от наборов доступности

По состоянию на 2019 год мы больше не добавляем другие функции в группы доступности в AKS. Все функции, представленные с 2019 года, например AKS Backup, не поддерживаются в группах доступности.

Миграция из групп доступности в пулы узлов виртуальных машин

Теперь можно использовать скрипт для переноса кластера AKS с использования групп доступности в пулы узлов виртуальных машин. Этот скрипт также автоматически обновляет подсистемы балансировки нагрузки уровня "Базовый" в кластере до уровня "Стандартный".

Это важно

Этот процесс также переносит базовый IP-адрес на стандартный IP-адрес, сохраняя входящий IP-адрес, связанный с подсистемой балансировки нагрузки. Во время этого процесса создается новый общедоступный IP-адрес и связан с правилами исходящего трафика стандартной подсистемы балансировки нагрузки для обслуживания исходящего трафика кластера.

Дополнительные сведения и ответы об обновлении с Basic Load Balancer до Standard Load Balancer см. в статье Об обновлении с Basic Load Balancer в службе Azure Kubernetes.

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

Требования

  • Минимальная версия Kubernetes для этого сценария — 1.27. Если вам нужно обновить кластер AKS, ознакомьтесь с обновлением кластера AKS.
  • Вам нужна установленная версия 2.76.0 Azure CLI.
  • Если кластер работает со службой управления ключами с закрытым хранилищем ключей, служба управления ключами должна быть отключена во время всей миграции.
  • Если кластер использует любой ValidatingAdmissionWebhooks или MutatingAdmissionWebhooks, перед миграцией эти веб-перехватчики должны быть отключены. Веб-перехватчики уровня управления по умолчанию не должны быть отключены. Например aks-node-mutating-webhook, webhook-admission-controllerи aks-node-validating-webhook.

Подготовка к миграции

  • Создайте план миграции для запланированного простоя.
  • После запуска миграции откат не разрешен.

Запуск скрипта миграции для миграции группы доступности

В следующих командах замените <myResourceGroup> на своё название группы ресурсов, а <myAKSCluster> на имя кластера AKS.

  1. Следующая команда инициирует сценарий для переноса кластера с групп доступности на пулы узлов виртуальных машин, используя команду az aks update и установку --migrate-vmas-to-vms. Этот скрипт также обновляет Базовый балансировщик нагрузки и Базовый IP до уровня Стандартный балансировщик нагрузки и Стандартный IP, если это применимо.

    az aks update \
  --name <myAKSCluster> \
  --resource-group <myResourceGroup> \
  --migrate-vmas-to-vms \

  2. Убедитесь, что миграция прошла успешно с помощью az aks show команды. Выходные данные команды отображают сведения о кластере.

    az aks show \
  --name <myAKSCluster> \
  --resource-group <myResourceGroup>

    Успешная миграция может быть проверена, когда сведения о кластере с помощью команды az aks show включают в себя набор type с VirtualMachines, и loadbalancerSku присвоено значение Standard.

      "type": "VirtualMachines"
  "loadBalancerSku": "standard",

  3. Убедитесь, что все pod и службы работают успешно с помощью команд kubectl get pods и kubectl get svc.

    kubectl get svc -A \
kubectl get pods -A

  4. Вы можете подтвердить новые IP-адреса, связанные с правилами исходящего трафика, перечислив исходящие IP-адреса. Этот шаг выполняется путем подтверждения идентификаторов ресурсов для IP-адресов, а затем перечисления IP-адресов.

    Используйте следующую команду, чтобы получить идентификатор ресурса для исходящих IP-адресов:

    # Get the outbound IP Resource ID
az aks show \
  --resource-group <myResourceGroup> \
  --name <myAKSCluster> \
  --query networkProfile.loadBalancerProfile.effectiveOutboundIPs[].id

    Используйте следующую команду, чтобы получить каждый IP-адрес для идентификатора ресурса и заменить <IPResourceID> идентификатором ресурса из предыдущей команды:

    # get the new IP for each IP Resource ID
az network public-ip show --ids <IPResourceID> --query ipAddress -o tsv

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

  • Последнее обновление: