Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Зоны доступности помогают защитить приложения и данные от сбоев центра обработки данных. Зоны являются уникальными физическими расположениями в регионе 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
Эту конфигурацию можно использовать, если требуется низкая задержка между узлами. Кроме того, он обеспечивает более детализированный контроль над операциями масштабирования или при использовании автомасштабирования кластера.
Замечание
Если одна рабочая нагрузка развертывается в пулах узлов, рекомендуется установить --balance-similar-node-groups
в значение true
, чтобы поддерживать сбалансированное распределение узлов между зонами для рабочих нагрузок во время операций масштабирования.
Региональные (не использующие зоны доступности)
Региональный режим используется, если назначение зоны не задано в шаблоне развертывания (например, "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
Это важно
30 сентября 2025 г. базовая подсистема балансировки нагрузки будет прекращена. Дополнительные сведения см. в официальном объявлении. Если вы используете Базовую подсистему балансировки нагрузки, обязательно обновите до стандартной подсистемы балансировки нагрузки до даты окончания поддержки.
Ограничения
Следующие ограничения применяются при использовании зон доступности.
- См. сведения о квотах, ограничениях размера виртуальной машины и доступности регионов в AKS.
- Количество используемых зон доступности невозможно изменить после создания пула узлов.
- Большинство регионов поддерживают зоны доступности. См. список регионов.
Связанный контент
- Узнайте о пулах системных узлов.
- Узнайте о пулах узлов пользователей.
- Сведения о подсистемах балансировки нагрузки.
- Ознакомьтесь с рекомендациями по обеспечению непрерывности бизнес-процессов и аварийному восстановлению в AKS.
Azure Kubernetes Service