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

  • Статья
  • Чтение занимает 6 мин

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

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

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

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

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

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

Кластеры AKS могут использовать зоны доступности в любом регионе Azure, где есть зоны доступности.

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

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

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

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

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

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

При создании кластера AKS ознакомьтесь со следующими сведениями об указании зон доступности в шаблоне:

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

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

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

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

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

Распределение узлов AKS между зонами доступности

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

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

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

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

В следующем примере создается кластер AKS с именем myAKSCluster в группе ресурсов myResourceGroup с тремя узлами. Один агент в зоне 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 является сбалансированным, если каждая зона имеет одинаковое количество виртуальных машин или одну виртуальную машину во всех остальных зонах для масштабируемого набора.

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

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

Сначала получите учетные данные для кластера 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. Вы можете получить тот же результат от выполнения kubelet describe nodes команды на предыдущем шаге, выполнив следующий скрипт:

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.