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

Общие сведения о зонах доступности в Служба Azure Kubernetes (AKS)

  • Статья

В этой статье представлен обзор использования зон доступности в Служба Azure Kubernetes (AKS) для повышения доступности приложений.

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

Что такое зоны доступности?

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

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

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

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

Дополнительные сведения см. в разделе "Использование зон доступности Azure".

Примечание.

При реализации зон доступности с помощью автомасштабирования кластера рекомендуется использовать один пул узлов для каждой зоны. Параметр можно задать --balance-similar-node-groups для true поддержания сбалансированного распределения узлов между зонами для рабочих нагрузок во время операций увеличения масштаба. Если этот подход не реализован, операции уменьшения масштаба могут нарушить баланс узлов между зонами. Эта конфигурация не гарантирует, что аналогичные группы узлов будут иметь одинаковое количество узлов:

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

Вы также можете использовать диски хранилища, избыточного между зонами Azure (ZRS), для реплика хранения в трех зонах доступности в выбранном регионе. Диск ZRS позволяет восстановиться после сбоя зоны доступности без потери данных. Дополнительные сведения см. в разделе ZRS для управляемых дисков.

Ограничения

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

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

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

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-csi-zrs
provisioner: disk.csi.azure.com
parameters:
  skuName: StandardSSD_ZRS  # or Premium_ZRS
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

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

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

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

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