Надежность в службе Azure Kubernetes (AKS)

2025-04-06

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

Надежность — это общая ответственность между вами и корпорацией Майкрософт. Это руководство позволяет определить, какие варианты надежности соответствуют конкретным бизнес-целям и целям простоя.

Обзор архитектуры надежности

При создании кластера AKS платформа Azure автоматически создает и настраивает:

Плоскость управления, в которой находятся API-сервер, etcd, планировщик и другие поды, необходимые для управления вашей рабочей нагрузкой.
Пул системных узлов в вашей подписке, в котором размещаются ваши надстройки и другие pods, которые выполняются в пространстве имен kube-system.

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

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

Корпорация Майкрософт управляет плоскостем управления и другими управляемыми компонентами AKS.
Это ваша ответственность
- Определите, как компоненты, включая пулы узлов и подсистемы балансировки нагрузки, которые присоединяются к службам, должны быть настроены в соответствии с требованиями к надежности. После определения компонентов корпорация Майкрософт развертывает и управляет ими от вашего имени.
- Управление любыми компонентами за пределами кластера AKS, включая хранилище и базы данных. Убедитесь, что эти компоненты соответствуют вашим требованиям к надежности. При развертывании рабочих нагрузок убедитесь, что другие компоненты Azure также настроены для обеспечения устойчивости, следуя рекомендациям по этим службам.

Временные сбои

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

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

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

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

Задайте бюджеты нарушения работы пода (PDB) в YAML пода, чтобы указать, сколько подов необходимо иметь в состоянии Ready в определенный момент времени. При настройке PDBs AKS обеспечивает минимальную доступность реплик при выполнении операций по кордону и очистке узлов. Если во время таких процессов, как обновления, требования PDB не могут быть удовлетворены, pod продолжает функционировать, и операция может завершиться ошибкой. Дополнительные сведения см. в разделе "PDF-файлы".
Используется maxUnavailable для определения максимального количества реплик, которые могут стать недоступными в определенное время. Например, при выполнении последовательного перезапуска AKS гарантирует, что в каждый момент времени чилеруется не более maxUnavailable модулей. Дополнительные сведения см. в разделе maxUnavailable.
Следуйте рекомендациям по развертыванию. Реплики Pod могут выйти из строя из-за проблем с приложением. Дополнительные сведения см. в рекомендациях по обеспечению надежности кластера AKS на уровне развертывания .

Примечание.

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

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

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

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

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

Поддержка регионов

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

Соображения

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

Разверните несколько реплик. Kubernetes распределяет поды по узлам на основе меток узлов. Чтобы распределить рабочую нагрузку между зонами, необходимо развернуть несколько реплик вашего pod (пода). Например, если вы настраиваете пул узлов с тремя зонами, но развертываете только одну реплику pod-объекта, ваше развертывание не является устойчивым к отказам в зонах.
Включите автоматическое масштабирование. Пулы узлов Kubernetes предоставляют параметры ручного и автоматического масштабирования. С помощью ручного масштабирования вы можете добавлять или удалять узлы по мере необходимости, а ожидающие pod'ы ждут до тех пор, пока вы не увеличите пул узлов. Масштабирование, управляемое AKS, использует автомасштабирование кластера или автоматическое выделение узлов (NAP). AKS увеличивает или уменьшает пул узлов на основе требований pod в рамках квоты и емкости SKU вашей подписки. Этот метод помогает убедиться, что поды распределены по доступным узлам в зонах доступности.
Задайте ограничения топологии pod. Используйте ограничения распространения топологии pod для управления распределением модулей pod по разным узлам или зонам. Ограничения помогают достичь высокой доступности, отказоустойчивости и эффективного использования ресурсов. Если вы предпочитаете распределять модули pod строго по зонам, можно задать ограничения, чтобы принудительно поместить модуль pod в состояние ожидания для поддержания баланса модулей pod между зонами. Дополнительные сведения см. в разделе "Ограничения распространения топологии Pod".
Настроить отказоустойчивую сетевую зону. Если ваши поды обрабатывают внешний трафик, настройте сетевую архитектуру кластера с помощью таких служб, как Шлюз приложений Azure, Azure Load Balancer или Azure Front Door.
Убедитесь, что зависимости являются зонально устойчивыми. Большинство приложений AKS используют другие службы для хранения, безопасности или сети. Убедитесь, что вы просмотрите рекомендации по устойчивости зоны для этих служб.

Себестоимость

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

Настройка поддержки зоны доступности

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

Нормальная работа

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

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

Опыт понижения зоны

Обнаружение и ответ: При сбое зоны контрольная плоскость автоматически выполняет переключение. Если пулы узлов используют зоны доступности и следуют рекомендациям по устойчивости зон, вы можете ожидать, что AKS развёртывает узлы и реплики в доступных зонах. AKS выполняет эту задачу автоматически при использовании управляемых решений, таких как автомасштабирование кластера или NAP. Без автомасштабирования узлы и реплики остаются в состоянии ожидания и требуют ручного увеличения пула узлов.

AKS также пытается перераспределять поды по здоровым зонам. Если вы решили вручную масштабировать пул узлов в ситуации с недоступной зоной, ваши поды могут оставаться в состоянии ожидания, если в здоровых зонах нет доступных узлов. Масштабирование в оставшихся зонах также зависит от доступности квоты и емкости для используемого SKU виртуальной машины.
Уведомление: AKS не уведомляет вас, когда зона выходит из строя. Вы можете использовать метрики работоспособности узлов или подов для мониторинга работоспособности узлов и подов.
Активные запросы: Любые активные запросы могут столкнуться с перебоями. Некоторые запросы могут завершиться ошибкой, и задержка может увеличиться, пока рабочая нагрузка переключается на другой резервный участок.
Ожидаемая потеря данных: Если вы храните состояние в кластере с помощью дисков Azure и используете зону с избыточным хранилищем, то сбой в зоне не должен привести к потере данных.
Ожидаемое время простоя: Если вы правильно настроите устойчивость зоны для вашего кластера и pod, то сбой зоны не приведет к простою рабочей нагрузки AKS.
Перенаправка трафика: Системы балансировки нагрузки перенаправляют новые входящие запросы на поды, которые выполняются на работоспособных узлах.

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

Возврат к исходной системе

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

Контрольная плоскость: AKS автоматически восстанавливает функции контрольной плоскости во всех зонах доступности. Никаких действий вручную не требуется.
Пулы узлов и узлы: Сразу после переключения узлы остаются в ранее работоспособных зонах и не восстанавливаются в зоне, которая была восстановлена. Однако при следующем выполнении операции масштабирования узлов, например, при расширении пула узлов, пул узлов может создавать узлы в восстановленной зоне.
Pods: Сразу после возврата модули pods продолжают работать на узлах, на которых они в настоящее время работают. При создании новых подов или повторном создании существующих подов они могут использовать узлы в восстановленной зоне.
Хранение: Любое хранилище, подключенное к подам, восстанавливается в зависимости от того, как работает зонально-избыточное хранилище.

Тестирование зон сбоев

Вы можете проверить устойчивость к сбоям зоны доступности с помощью следующих методов:

Поддержка нескольких регионов

Кластеры AKS — это одно-регионные ресурсы. Если регион недоступен, кластер AKS также недоступен.

Альтернативные подходы с несколькими регионами

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

Используйте Диспетчер флотов Azure Kubernetes , если требуется более простой управляемый интерфейс. С помощью Azure Kubernetes Fleet Manager можно:
- Управление набором кластеров AKS в виде одной единицы, и эти кластеры можно распределять по нескольким регионам Azure.
- Автоматизация конкретных аспектов управления кластерами, таких как обновление образа кластера и узла.
- Используйте возможности распределения трафика для равномерного распределения нагрузки между кластерами и автоматического переключения при отказе, если регион становится недоступен.
Обеспечьте отработку отказа, используя ручную модель развертывания активно-активного или активно-пассивного типа, если для вашей рабочей нагрузки требуется более детальный контроль над различными компонентами межрегиональных отработок отказа. Дополнительные сведения см. в обзоре высокого уровня доступности и аварийного восстановления для AKS.

Резервные копии

Azure Backup имеет расширение, которое можно использовать для резервного копирования ресурсов кластера AKS и присоединённых к нему постоянных томов. Хранилище резервных копий взаимодействует с кластером AKS через расширение для выполнения операций резервного копирования и восстановления.

Если кластер AKS находится в парном регионе, можно настроить резервные копии для хранения в геоизбыточное хранилище. Геоизбыточные резервные копии можно восстановить в сопряжённом регионе.

Дополнительные сведения см. в следующих статьях:

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

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

Надежность при проведении технического обслуживания

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

Чтобы сократить нарушения работы службы в критические периоды времени, AKS предоставляет элементы управления, чтобы указать запланированное время обслуживания. Дополнительные сведения см. в статье "Использование планового обслуживания для планирования и контроля обновлений для кластера службы Azure Kubernetes".

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для AKS описывает ожидаемую доступность службы и условия, которые должны быть выполнены для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.

AKS предоставляет три ценовые категории для управления кластерами: "Бесплатный", "Стандартный" и "Премиум". Уровень "Бесплатный" позволяет использовать AKS для тестирования рабочих нагрузок. Уровни "Стандартный" и "Премиум" предназначены для рабочих нагрузок. При развертывании кластера AKS с включенными зонами доступности увеличивается процент времени простоя, определенный в уровне обслуживания. Однако соглашение об уровне обслуживания применяется только при развертывании кластера в ценовой категории "Стандартный" или "Премиум".

Надежность в Azure