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

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

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

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

Ресурсы AKS

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

Плоскость управления AKS

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

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

Пулы узлов

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

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

Существует три способа развертывания пулов узлов:

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

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

Зональный охват

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

# Create an AKS cluster, and create a zone-spanning system node pool 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 node pool, 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 автоматически балансирует количество узлов между зонами.

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

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

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

Выравненный по зонам

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

# # Add three new zone-aligned user node pools, 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

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

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

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

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

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

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

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   0
aks-nodepool1-34917322-vmss000001   eastus   0
aks-nodepool1-34917322-vmss000002   eastus   0

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

Подшипники

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

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

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

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

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: my-app
      containers:
      - name: my-container
        image: my-image

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

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

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

В следующем примере показан запрос на постоянный том, использующий стандартный SSD Azure с хранением с зональной избыточностью.

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 (локально избыточному хранилищу). Затем можно использовать новый класс хранилища в заявке на постоянный том.

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

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

kind: StorageClass

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

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

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

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

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

Ограничения

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

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

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

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