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

Рекомендации по обеспечению устойчивости зоны для Служба Azure Kubernetes (AKS)

В этой статье вы узнаете о различных рекомендациях по обеспечению устойчивости зоны в Служба Azure Kubernetes (AKS), в том числе о том, как:

  • Устойчивость зоны компонентов кластера AKS
  • Разработка приложения без отслеживания состояния
  • Принятие решения о диске хранилища
  • Проверка устойчивости зоны доступности (AZ)

Обзор

Устойчивость AZ является ключевой частью запуска кластеров Kubernetes производственного класса. Благодаря масштабируемости в основном Kubernetes использует все преимущества независимой инфраструктуры в центрах обработки данных без дополнительных затрат путем подготовки новых узлов только при необходимости.

Внимание

Простое увеличение или уменьшение числа узлов в кластере недостаточно, чтобы обеспечить устойчивость приложений. Необходимо получить более глубокое представление о приложении и его зависимостях, чтобы лучше планировать устойчивость. AKS позволяет настроить зоны доступности (AZ) для кластеров и пулов узлов, чтобы обеспечить устойчивость приложений к сбоям и продолжать обслуживать трафик, даже если вся зона исчезнет.

Устойчивость зоны компонентов кластера AKS

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

Создание избыточных между зонами кластеров и пулов узлов

AKS позволяет выбрать несколько AZ во время создания кластера и пула узлов. При создании кластера в регионе с несколькими AZ плоскость управления автоматически распределяется по всем AZ в этом регионе. Однако узлы в пуле узлов распределяются только по выбранным AZ. Этот подход гарантирует, что плоскость управления и узлы распределяются по нескольким AZ, обеспечивая устойчивость в случае сбоя AZ. Вы можете настроить AZ с помощью портала Azure, Azure CLI или шаблонов Azure Resource Manager.

В следующем примере показано, как создать кластер с тремя узлами, распределенными по трем AZ с помощью Azure CLI:

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3

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

kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"

В следующем примере выходных данных показан регион и зона доступности для каждого узла агента:

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 (AKS).

Убедитесь, что модули pod распределены по AZ

Начиная с версии Kubernetes 1.33, значение Kube-Scheduler в AKS по умолчанию настроено на использование значения MaxSkew равного 1 для topology.kubernetes.io/zone, как указано ниже:

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: "topology.kubernetes.io/zone"
  whenUnsatisfiable: ScheduleAnyway

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

Однако если в развертывании имеются определенные потребности в топологии, можно переопределить указанные выше значения по умолчанию, добавив свои собственные значения в спецификацию pod. Ограничения на топологию pod можно использовать, основываясь на метках zone и hostname, чтобы распределять pod по AZ в пределах региона и между узлами внутри AZ.

Например, предположим, что у вас есть кластер с четырьмя узлами, в котором три модуля pod, помеченные app: mypod-app , находятся в node1, node2и node3 соответственно. Если вы хотите, чтобы новое развертывание размещалось на различных узлах насколько это возможно, можно использовать манифест, аналогичный следующему примеру:

apiVersion: v1
kind: Deployment
metadata:
  name: mypod-deployment
  labels:
    app: mypod-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mypod-app
  template:
    metadata:
      labels:
        app: mypod-app
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "kubernetes.io/hostname"
        whenUnsatisfiable: ScheduleAnyway
      containers:
      - name: pause
        image: registry.k8s.io/pause

Замечание

Если в вашем приложении существуют строгие требования к распределению по зонам, и ожидаемым поведением является оставление пода в состоянии ожидания, если подходящий узел не найден, вы можете использовать whenUnsatisfiable: DoNotSchedule. Эта конфигурация сообщает планировщику оставить pod в ожидании, если узел в подходящей зоне или на другом хосте не существует или его нельзя масштабировать.

Дополнительные сведения о настройке распространения модулей и понимании последствий MaxSkew см. в документации по топологии модулей Kubernetes.

Настройка сети с поддержкой AZ

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

Azure Load Balancer поддерживает как внутреннюю, так и внешнюю балансировку нагрузки, и ее можно настроить для балансировки нагрузки, избыточной между зонами. Номер SKU "Стандартный" — это номер SKU по умолчанию в AKS, который поддерживает региональную устойчивость с зонами доступности, чтобы гарантировать, что ваше приложение не влияет на сбой региона. В случае сбоя зоны подсистема балансировки нагрузки SKU уровня "Стандартный" не влияет на сбой и позволяет развертываниям продолжать обслуживать трафик из оставшихся зон. Вы можете использовать глобальную подсистему балансировки нагрузки, например Front Door или Диспетчер трафика, или использовать подсистемы балансировки нагрузки между регионами перед региональными кластерами AKS, чтобы гарантировать, что ваше приложение не влияет на региональные сбои. Сведения о создании подсистемы балансировки нагрузки SKU уровня "Стандартный" в AKS см. в статье "Использование стандартной подсистемы балансировки нагрузки" в Служба Azure Kubernetes (AKS).

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

Внимание

С помощью шлюза NAT Azure можно создавать шлюзы NAT в определенных AZ или использовать зональное развертывание для изоляции в определенных зонах. Шлюз NAT поддерживает зональные развертывания, но не развертывания, избыточные между зонами. Это может быть проблема, если вы настроите кластер AKS с исходящим типом, равным шлюзу NAT, и шлюз NAT находится в одной зоне. В этом случае, если зона, на котором размещен шлюз NAT, исчезнет, кластер теряет исходящее подключение. Дополнительные сведения см. в разделе "Шлюз NAT" и зон доступности.

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

Чтобы убедиться, что образы контейнеров являются высокодоступными и устойчивыми к сбоям, необходимо настроить реестр контейнеров, избыточный по зонам. Номер SKU Реестр контейнеров Azure (ACR) Premium поддерживает георепликацию и необязательное избыточность зоны. Эти функции обеспечивают доступность и сокращение задержки для региональных операций.

Обеспечение доступности и избыточности ключей и секретов

Azure Key Vault предоставляет несколько уровней избыточности, чтобы убедиться, что ключи и секреты остаются доступными для приложения, даже если отдельные компоненты службы завершаются сбоем, или если регионы Azure или AZ недоступны. Дополнительные сведения см. в статье Доступность и избыточность хранилища ключей Azure.

Использование функций автомасштабирования

Вы можете улучшить доступность и устойчивость приложений в AKS с помощью функций автомасштабирования, которые помогут достичь следующих целей:

  • Оптимизация использования ресурсов и экономичности путем увеличения или уменьшения масштаба на основе использования ЦП и памяти модулей pod.
  • Повышение отказоустойчивости и восстановления путем добавления дополнительных узлов или модулей pod при сбое зоны.

Для реализации автомасштабирования в AKS можно использовать горизонтальное автомасштабирование pod (HPA) и кластерный автомасштабирование . HPA автоматически масштабирует количество модулей pod в развертывании на основе наблюдаемого использования ЦП, использования памяти, пользовательских метрик и метрик других служб. Средство автомасштабирования кластера автоматически настраивает количество узлов в пуле узлов на основе запросов ресурсов модулей pod, работающих на узлах. Если вы хотите использовать оба автомасштабирования вместе, убедитесь, что пулы узлов с включенным автомасштабированием охватывают несколько зон. Если пул узлов находится в одной зоне, и эта зона выходит из строя, автомасштабирование не может масштабировать кластер по зонам.

Предварительная версия поставщика AKS Karpenter позволяет автоматически создавать узлы с помощью Karpenter в кластере AKS. Дополнительные сведения см. в обзоре функции поставщика AKS Karpenter.

Надстройка Автомасштабирования на основе событий Kubernetes (KEDA) для AKS применяет автомасштабирование на основе событий для масштабирования приложения на основе метрик внешних служб для удовлетворения спроса. Дополнительные сведения см. в разделе "Установка надстройки KEDA" в Служба Azure Kubernetes (AKS).

Разработка приложения без отслеживания состояния

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

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

Принятие решения о диске хранилища

Выбор подходящего типа диска в зависимости от потребностей приложения

Azure предлагает два типа дисков для постоянного хранилища: локально избыточное хранилище (LRS) и избыточное между зонами хранилище (ZRS). LRS реплицирует данные в пределах одного AZ. ZRS реплицирует данные в нескольких AZ в пределах региона. Начиная с AKS версии 1.29, класс хранилища по умолчанию использует диски ZRS для постоянного хранилища. Дополнительные сведения см. в встроенных классах хранилища AKS.

Способ репликации данных приложения может повлиять на выбор диска. Если приложение находится в нескольких зонах и реплицирует данные из приложения, вы можете достичь устойчивости с помощью диска LRS в каждой из них, так как если один AZ выходит из строя, другие AZ будут иметь последние данные для них. Если уровень приложений не обрабатывает такую репликацию, то диски ZRS лучше подходят, так как Azure обрабатывает репликацию на уровне хранилища.

В следующей таблице описаны плюсы и минусы каждого типа диска:

Тип диска Плюсы Минусы
Система регистрации и отслеживания (LRS) • Более низкая стоимость
• Поддерживается для всех размеров дисков и регионов
• Простое использование и подготовка		 • Низкая доступность и устойчивость
• Уязвимые к зональным сбоям
• Не поддерживает зону или георепликацию
ZRS • Более высокая доступность и устойчивость
• Более устойчивый к зональным сбоям
• Поддерживает репликацию зоны для обеспечения устойчивости внутри региона		 • Более высокая стоимость
• Не поддерживается для всех размеров дисков и регионов
• Требуется дополнительная конфигурация для включения

Дополнительные сведения о типах дисков LRS и ZRS см. в служба хранилища Azure избыточности. Сведения о подготовке дисков хранилища в AKS см. в статье "Подготовка хранилища дисков Azure" в Служба Azure Kubernetes (AKS).

Мониторинг производительности диска

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

Дополнительные сведения см. в статье "Мониторинг Служба Azure Kubernetes (AKS) с помощью Azure Monitor.

Проверка устойчивости AZ

Метод 1. Кордон и узлы очистки в одном AZ

Одним из способов проверки устойчивости кластера AKS для AZ является очистка узла в одной зоне и сведения о том, как он влияет на трафик, пока он не выполнит отработку отказа в другую зону. Этот метод имитирует реальный сценарий, в котором вся зона недоступна из-за аварии или сбоя. Чтобы протестировать этот сценарий, можно использовать kubectl drain команду для корректного вытеснения всех модулей pod с узла и пометить ее как неуправляемую. Затем можно отслеживать трафик кластера и производительность с помощью таких средств, как Azure Monitor или Prometheus.

В следующей таблице описаны преимущества и минусы этого метода:

Плюсы Минусы
• Имитация реалистичного сценария сбоя и тестирование процесса восстановления
• Позволяет проверить доступность и устойчивость данных в разных регионах.
• Помогает определить потенциальные проблемы или узкие места в конфигурации кластера или проектировании приложений.		 • Может привести к временному нарушению или снижению уровня обслуживания для пользователей
• Требуется ручное вмешательство и координация для очистки и восстановления узла
• Может привести к дополнительным затратам из-за увеличения сетевого трафика или репликации хранилища

Метод 2. Имитация сбоя AZ с помощью Azure Chaos Studio

Еще одним способом тестирования кластера AKS для обеспечения устойчивости AZ является внедрение сбоев в кластер и наблюдение за воздействием на приложение с помощью Azure Chaos Studio. Azure Chaos Studio — это служба, которая позволяет создавать эксперименты хаоса и управлять ими в ресурсах и службах Azure. С помощью Chaos Studio можно имитировать сбой AZ, создав эксперимент внедрения ошибок, предназначенный для определенной зоны, и останавливает или перезапускает виртуальные машины в этой зоне. Затем можно измерить доступность, задержку и частоту ошибок приложения с помощью метрик и журналов.

В следующей таблице описаны преимущества и минусы этого метода:

Плюсы Минусы
• Предоставляет контролируемый и автоматизированный способ внедрения ошибок и мониторинга результатов
• Поддерживает различные типы сбоев и сценариев, такие как задержка сети, стресс ЦП, сбой диска и т. д.
• Интегрируется с Azure Monitor и другими средствами для сбора и анализа данных		 • Может потребоваться дополнительная настройка и настройка для создания и запуска экспериментов
• Может не охватывать все возможные режимы сбоев и пограничные зоны, которые могут возникнуть во время реального сбоя
• Могут иметь ограничения или ограничения для области и /или длительности экспериментов

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

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

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