Зоны доступности в Служба Azure Kubernetes (AKS)

Статья
02/04/2025

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

Использование AKS с зонами доступности физически распределяет ресурсы между различными зонами доступности в одном регионе, повышая надежность. Развертывание узлов в нескольких зонах не несет дополнительных затрат.

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

Ресурсы AKS

На этой схеме показаны ресурсы Azure, созданные при создании кластера AKS:

Уровень управления AKS

Корпорация Майкрософт размещает плоскость управления AKS, сервер API Kubernetes и службы, такие как scheduleretcd управляемая служба. Корпорация Майкрософт реплицирует плоскость управления в нескольких зонах.

Другие ресурсы кластера развертываются в управляемой группе ресурсов в подписке Azure. По умолчанию эта группа ресурсов имеет префикс MC_ для управляемого кластера и содержит следующие ресурсы:

Пулы узлов

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

При создании кластера AKS требуется один пул системных узлов и создается автоматически. Он размещает критически важные системные модули pod, такие как CoreDNS и metrics-server. Дополнительные пулы узлов пользователей можно добавить в кластер AKS для размещения приложений.

Можно развернуть три способа развертывания пулов узлов:

Охват зоны
Выравнивание зоны
Региональный

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

Охват зоны

Масштабируемый набор зон распределяет узлы по всем выбранным зонам, указав эти зоны с параметром --zones .

# Create an AKS Cluster, and create a zone spanning System Nodepool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1, 2, 3
# Add one new zone spanning User Nodepool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a  --node-count 6 --zones 1, 2, 3

AKS балансирует количество узлов между зонами автоматически.

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

Выравнивание зоны

Каждый узел выровнен (закреплен) до определенной зоны. Чтобы создать три пула узлов для региона с тремя Зоны доступности:

# # Add three new zone aligned User Nodepools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x  --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y  --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z  --node-count 2 --zones 3

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

Примечание.

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

Региональные (не использующие Зоны доступности)

Региональный режим используется, если назначение зоны не задано в шаблоне развертывания ("zones"=[] or "zones"=null).

В этой конфигурации пул узлов создает экземпляры региональных (незоны, закрепленные) и неявно помещает экземпляры по всему региону. Нет никаких гарантий для баланса или распространения между зонами или того, что экземпляры приземлились в одной зоне доступности.

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

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

kubectl describe nodes | grep -e "Name:" -e "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

Развертывания

Объекты pod

Kubernetes знает о Зоны доступности Azure и может сбалансировать модули pod между узлами в разных зонах. В случае недоступности зоны Kubernetes перемещает модули pod от затронутых узлов автоматически.

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

Чтобы просмотреть, на каких узлах pod запущены, выполните следующую команду:

  kubectl describe pod | grep -e "^Name:" -e "^Node:"

Параметр MaxSkew описывает степень, к которой модули Pod могут быть неравномерно распределены. При условии, что три зоны и три реплики, при установке этого значения равно 1, каждая зона имеет по крайней мере один модуль pod:

kind: Pod
apiVersion: v1
metadata:
  name: myapp
spec:
  replicas: 3
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule # or ScheduleAnyway
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.1

Хранилище и тома

По умолчанию Kubernetes версии 1.29 и более поздних версий используют Azure Управляемые диски с помощью хранилища с избыточностью между зонами (ZRS) для утверждений постоянных томов.

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

Пример утверждения постоянного тома, использующего SSD уровня "Стандартный" в ZRS:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  #storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 5Gi

Для развертываний, выровненных между зонами, можно создать класс хранилища с параметром skuname LRS (локально избыточное хранилище). Затем можно использовать новый класс хранилища в утверждении постоянного тома (PVC).

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

Пример класса хранилища SSD уровня "Стандартный" LRS:

kind: StorageClass

metadata:
  name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
  #skuname: PremiumV2_LRS

Подсистемы балансировки нагрузки

Kubernetes развертывает Load Balancer (цен. категория Azure по умолчанию, которая балансирует входящий трафик во всех зонах в регионе. Если узел становится недоступным, подсистема балансировки нагрузки перенаправляет трафик на здоровые узлы.

Пример службы, использующая Azure Load Balancer:

apiVersion: v1
kind: Service
metadata:
  name: example
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080

Внимание

30 сентября 2025 г. базовая подсистема балансировки нагрузки будет прекращена. Дополнительные сведения см. в официальном объявлении. Если вы используете базовую подсистему балансировки нагрузки, обязательно обновите ее до Load Balancer (цен. категория до даты выхода на пенсию.

Ограничения

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

См . сведения о квотах, ограничениях размера виртуальной машины и доступности регионов в AKS.
Количество используемых Зоны доступности невозможно изменить после создания пула узлов.
Большинство регионов поддерживают Зоны доступности. Список можно найти здесь.

Следующие шаги

Сведения о пуле системных узлов
Сведения о пулах узлов пользователей
Сведения о подсистемах балансировки нагрузки
Лучшие методики по обеспечению непрерывности бизнес-процессов и аварийного восстановления в AKS

Поделиться через