Создание кластера Службы Azure Kubernetes (AKS), который использует зоны доступности

Кластер Azure Kubernetes Service (AKS) распространяет ресурсы, такие как узлы и хранилище, по логическим разделам базовой инфраструктуры Azure. Эта модель развертывания при использовании зон доступности гарантирует, что узлы в заданной зоне доступности физически отделены от тех, которые определены в другой зоне доступности. Кластеры AKS, развернутые с несколькими зонами доступности, настроенными в кластере, обеспечивают более высокий уровень доступности для защиты от сбоев оборудования или запланированного обслуживания.

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

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

Перед началом

Вам необходимо установить и настроить службу Azure CLI версии 2.0.76 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.

Ограничения и доступность в регионах

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

  • Восточная Австралия
  • Brazil South
  • Центральная Канада
  • Центральная Индия
  • Центральная часть США
  • Восточная Азия
  • Восточная часть США
  • восточная часть США 2
  • Центральная Франция
  • Центрально-Западная Германия
  • Восточная Япония
  • Республика Корея, центральный регион
  • Северная Европа
  • Восточная Норвегия;
  • Юго-Восточная Азия
  • Северная часть ЮАР;
  • Центрально-южная часть США
  • Центральная Швеция
  • южная часть Соединенного Королевства
  • US Gov (Вирджиния)
  • Западная Европа
  • западная часть США 2
  • Западная часть США — 3

При создании кластера AKS с помощью зон доступности применяются следующие ограничения.

  • Зоны доступности можно определить только при создании кластера или пула узлов.
  • Параметры зон доступности невозможно обновить после создания кластера. Вы также не можете обновить существующий кластер зон, не являющихся зонами доступности, для использования зон доступности.
  • Выбранный размер узла (SKU виртуальной машины) должен быть доступен во всех выбранных зонах доступности.
  • Для кластеров с включенными зонами доступности необходимо использовать Load Balancer (цен. категория "Стандартный") Azure для распределения между зонами. Этот тип подсистемы балансировки нагрузки может быть определен только во время создания кластера. Дополнительные сведения и ограничения стандартной подсистемы балансировки нагрузки см. в статье Ограничения Load Balancer (цен. категория "Стандартный") Azure.

Поддержка зоны доступности дисков Azure

  • Тома, использующие управляемые диски LRS Azure, не являются ресурсами, избыточными в зоне. Эти тома не могут быть подключены по зонам, и они должны располагаться в той же зоне, что и заданный узел, в котором размещается целевой pod.
  • Тома, использующие управляемые диски ZRS Azure (поддерживаемые драйвером CSI Диска Azure версии 1.5.0+), являются ресурсами, избыточными в зоне. Эти тома можно запланировать во всех узлах агентов зон и вне зон.

Kubernetes учитывает зоны доступности Azure, начиная с версии 1.12. Вы можете развернуть объект PersistentVolumeClaim, ссылающийся на Управляемый диск Azure в кластере AKS с несколькими зонами, и Kubernetes выполнит планирование для всех групп pod, которые объявляют PVC, в правильной зоне доступности.

Шаблоны Azure Resource Manager и зоны доступности

Если при создании кластера AKS в шаблоне явно задано значение NULL с помощью такого синтаксиса, как "availabilityZones": null, то шаблон Resource Manager посчитает это свойство несуществующим. Это означает, что в кластере не будут включены зоны доступности. Кроме того, при создании кластера с помощью шаблона Resource Manager, в котором не указано свойство зон доступности, зоны доступности отключаются.

Вы не можете обновить параметры для зон доступности в существующем кластере, поэтому при обновлении кластера AKS с помощью шаблонов Resource Manager поведение отличается. Если явно задать значение NULL в шаблоне для зон доступности и обновить кластер, то в кластер не будут внесены изменения параметров зон доступности. Однако если опустить свойство зон доступности, используя такой синтаксис, как "availabilityZones": [], то операция развертывания попытается отключить зоны доступности в существующем кластере AKS и завершится сбоем.

Общие сведения о зонах доступности для кластеров AKS

Зоны доступности являются предложением, обеспечивающим высокий уровень доступности и защищающим приложения и данные от сбоев центров обработки данных. Зоны — уникальные физические расположения в пределах одного региона Azure. Каждая зона состоит из одного или нескольких центров обработки данных, оснащенных независимыми системами электроснабжения, охлаждения и сетевого взаимодействия. Для обеспечения устойчивости во всех регионах с поддержкой зон всегда существует более чем одна зона. Физическое разделение зон доступности в пределах региона защищает приложения и данные от сбоев центров обработки данных.

Дополнительные сведения см. в статье Что такое зоны доступности в Azure?.

Кластеры AKS, развернутые с помощью зон доступности, могут распределять узлы по нескольким зонам в одном регионе. Например, кластер в регионе Восточная часть США 2 может создавать узлы во всех трех зонах доступности в зоне Восточная часть США 2. Это распределение ресурсов кластера AKS повышает доступность кластера, так как они устойчивы к сбоям определенной зоны.

AKS node distribution across availability zones

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

Создание кластера AKS в разных зонах доступности

При создании кластера с помощью команды az aks create параметр --zones определяет, в какие зоны развертываются узлы агента. Компоненты уровня управления, такие как etcd или API, распределяются между доступными зонами в регионе, если вы определяете параметр --zones во время создания кластера. Отдельные зоны, по которым распределяются компоненты уровня управления, не зависят от того, какие явные зоны выбраны для начального пула узлов.

Если вы не определили зоны для пула агентов по умолчанию при создании кластера AKS, компоненты уровня управления не будут распределяться между зонами доступности. Вы можете добавить дополнительные пулы узлов с помощью команды az aks nodepool add и указать --zones для новых узлов, но это не изменит способ распределения уровня управления между зонами. Параметры зоны доступности можно определить только во время создания кластера или пула узлов.

В следующем примере в группе ресурсов myResourceGroup создается кластер AKS с именем myAKSCluster. Создается всего 3 узла — один агент в зоне 1, один в зоне 2 и один — в зоне 3.

az group create --name myResourceGroup --location eastus2

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --generate-ssh-keys \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --node-count 3 \
    --zones 1 2 3

Создание кластера AKS занимает несколько минут.

При принятии решения о зоне, к которой должен принадлежать новый узел, в заданном пуле узлов AKS будет использоваться оптимальная балансировка по зонам, предлагаемая базовыми масштабируемыми наборами виртуальных машин Azure. Пул узлов AKS считается сбалансированным, если каждая зона имеет одинаковое количество виртуальных машин или +/- 1 виртуальная машина во всех остальных зонах для масштабируемого набора.

Проверка распределения узлов между зонами

Когда кластер будет готов, вызовите список узлов агента в масштабируемом наборе, чтобы увидеть, в какой зоне доступности они развернуты.

Сначала получите учетные данные для кластера AKS с помощью команды az aks get-credentials.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Затем выполните команду kubectl describe, чтобы получить список узлов в кластере, и отфильтруйте их по значению topology.kubernetes.io/zone. Ниже приведен пример для оболочки Bash.

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

В следующем примере выходных данных показаны три узла, распределенные по заданному региону и зонам доступности, такие как eastus2-1 для первой зоны доступности и eastus2-2 для второй зоны доступности.

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3

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

Обратите внимание, что в более новых версиях Kubernetes (начиная с 1.17.0) AKS использует более новую метку topology.kubernetes.io/zone в дополнение к устаревшей failure-domain.beta.kubernetes.io/zone. Аналогичный результат можно получить, выполнив следующий скрипт:

kubectl get nodes -o custom-columns=NAME:'{.metadata.name}',REGION:'{.metadata.labels.topology\.kubernetes\.io/region}',ZONE:'{metadata.labels.topology\.kubernetes\.io/zone}'

Но он возвращает менее подробные выходные данные:

NAME                                REGION   ZONE
aks-nodepool1-34917322-vmss000000   eastus   eastus-1
aks-nodepool1-34917322-vmss000001   eastus   eastus-2
aks-nodepool1-34917322-vmss000002   eastus   eastus-3

Проверка распределения узлов между зонами

Как описано в статье Хорошо известные метки, заметки и taint, Kubernetes использует метку topology.kubernetes.io/zone для автоматического распределения модулей pod в контроллере или службе репликации в разных доступных зонах. Чтобы протестировать это, можно увеличить масштаб кластера с 3 до 5 узлов, чтобы убедиться в правильности распределения модулей pod:

az aks scale \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 5

Через несколько минут, когда завершится операция масштабирования, команда kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone" в оболочке Bash должна вернуть примерно такой результат:

Name:       aks-nodepool1-28993262-vmss000000
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000001
            topology.kubernetes.io/zone=eastus2-2
Name:       aks-nodepool1-28993262-vmss000002
            topology.kubernetes.io/zone=eastus2-3
Name:       aks-nodepool1-28993262-vmss000003
            topology.kubernetes.io/zone=eastus2-1
Name:       aks-nodepool1-28993262-vmss000004
            topology.kubernetes.io/zone=eastus2-2

Теперь у нас есть два дополнительных узла в зонах 1 и 2. Можно развернуть приложение, состоящее из трех реплик. В качестве примера мы будем использовать NGINX:

kubectl create deployment nginx --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
kubectl scale deployment nginx --replicas=3

При просмотре узлов, на которых выполняются модули pod, вы увидите модули pod на узлах, соответствующих трем различным зонам доступности. Например, команда kubectl describe pod | grep -e "^Name:" -e "^Node:" в оболочке Bash должна вернуть примерно такой результат:

Name:         nginx-6db489d4b7-ktdwg
Node:         aks-nodepool1-28993262-vmss000000/10.240.0.4
Name:         nginx-6db489d4b7-v7zvj
Node:         aks-nodepool1-28993262-vmss000002/10.240.0.6
Name:         nginx-6db489d4b7-xz6wj
Node:         aks-nodepool1-28993262-vmss000004/10.240.0.8

Как видно из предыдущих выходных данных, первый модуль pod выполняется на узле 0, который находится в зоне доступности eastus2-1. Второй модуль pod выполняется на узле 2, который соответствует eastus2-3, а третий — на узле 4 в eastus2-2. Без дополнительной настройки Kubernetes правильно распределяет модули pod по всем трем зонам доступности.

Дальнейшие действия

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