Возможности масштабирования приложений в Службе Azure Kubernetes (AKS)
При запуске приложений в Служба Azure Kubernetes (AKS) может потребоваться увеличить или уменьшить объем вычислительных ресурсов. При изменении количества экземпляров приложения может потребоваться изменить количество базовых узлов Kubernetes. Также может потребоваться подготовить большое количество других экземпляров приложения.
В этой статье приводятся основные понятия масштабирования приложений AKS, включая масштабирование модулей pod или узлов вручную, использование средства автомасштабирования горизонтального модуля pod, использование средства автомасштабирования кластера и интеграцию с Экземпляры контейнеров Azure (ACI).
Масштабирование элементов pod или узлов вручную.
Вы можете вручную масштабировать реплика или модули pod и узлы, чтобы проверить, как приложение реагирует на изменение доступных ресурсов и состояний. Масштабирование ресурсов вручную позволяет определить набор ресурсов, используемых для поддержания фиксированной стоимости, например количество узлов. Для масштабирования вручную нужно задать количество реплик или узлов. Затем API Kubernetes планирует создание дополнительных модулей pod или очистку узлов на основе этого реплика или количества узлов.
При уменьшении размера узлов Kubernetes API вызывает соответствующий API вычислений Azure, привязанный к типу вычислений, используемому вашим кластером. Например, для кластеров, созданных на основе Масштабируемые наборы виртуальных машин, api Масштабируемые наборы виртуальных машин определяет, какие узлы следует удалить. Дополнительные сведения о том, как узлы выбираются для удаления при горизонтальном масштабировании, см. в разделе Масштабируемые наборы виртуальных машин вопросы и ответы.
Сведения о начале работы с узлами масштабирования вручную см. в разделе "Масштабирование узлов вручную" в кластере AKS. Чтобы вручную масштабировать количество модулей pod, см . команду kubectl scale.
Средство горизонтального автомасштабирования объектов pod
Kubernetes использует горизонтальное автомасштабирование pod (HPA) для отслеживания спроса на ресурсы и автоматического масштабирования количества модулей pod. По умолчанию HPA проверка API метрик каждые 15 секунд для любых необходимых изменений в реплика счетчике, а API метрик извлекает данные из Kubelet каждые 60 секунд. Таким образом, HPA обновляется каждые 60 секунд. При необходимости изменения число реплик увеличивается или уменьшается соответствующим образом. HPA работает с кластерами AKS, которые развернули сервер метрик для Kubernetes версии 1.8 и выше.
При настройке HPA для данного развертывания необходимо определить минимальное и максимальное количество реплика, которые могут выполняться. Можно также определить метрики для мониторинга и принятия решений о масштабировании, например метрику использования ЦП.
Чтобы приступить к работе со средством горизонтального автомасштабирования pod в AKS, ознакомьтесь с разделом Автомасштабирование pod.
Время ожидания событий масштабирования
Так как HPA эффективно обновляется каждые 60 секунд, предыдущие события масштабирования, возможно, не были успешно завершены до выполнения другого проверка. Это может привести к изменению числа реплика HPA до того, как предыдущее событие масштабирования может получить рабочую нагрузку приложения и требования к ресурсам соответствующим образом.
Чтобы избежать событий гонки, задается значение задержки. Это значение определяет время ожидания HPA после события масштабирования перед активацией другого события масштабирования. Такое поведение позволит применить новое число реплик, и API метрик будет отражать распределенную рабочую нагрузку. Однако задержка в событиях масштабирования по сравнению с Kubernetes 1.12 отсутствует, однако задержка по умолчанию для событий уменьшения масштаба составляет 5 минут.
Средство автомасштабирования кластера
Чтобы реагировать на изменение требований pod, средство автомасштабирования кластера Kubernetes настраивает количество узлов на основе запрошенных вычислительных ресурсов в пуле узлов. По умолчанию средство автомасштабирования кластера проверяет сервер API метрик каждые 10 секунд на наличие изменений, которые нужно внести в число узлов. Если средство автомасштабирования кластера определяет необходимость изменения, количество узлов в кластере AKS увеличивается или уменьшается соответствующим образом. Автоматическое масштабирование кластера работает с кластерами Kubernetes с поддержкой RBAC AKS, на которых работает Kubernetes 1.10.x или выше.
Автомасштабирование кластера обычно используется вместе с горизонтальным автомасштабированием pod. При объединении горизонтальное автоматическое масштабирование pod увеличивает или уменьшает количество модулей pod по требованию приложения, а автомасштабирование кластера настраивает количество узлов для выполнения дополнительных модулей pod.
Чтобы приступить к работе с автомасштабированием кластера в AKS, см . раздел автомасштабирование кластера в AKS.
События увеличения масштаба
Если у узла недостаточно вычислительных ресурсов для запуска запрошенного модуля Pod, этот модуль не сможет выполнить процесс планирования. Модуль pod не может запускаться, если в пуле узлов не доступны дополнительные вычислительные ресурсы.
Когда средство автомасштабирования кластера заметит модули pod, которые не могут быть запланированы из-за ограничений ресурсов пула узлов, число узлов в пуле узлов увеличивается для предоставления дополнительных вычислительных ресурсов. Когда узлы успешно развертываются и доступны для использования в пуле узлов, модули pod затем планируются для их запуска.
Если приложению необходимо быстро масштабироваться, некоторые модули pod могут оставаться в состоянии ожидания, пока не будут запланированы дополнительные узлы, развернутые автомасштабированием кластера, могут принимать запланированные модули pod. Для приложений со скачкообразными потребностями в ресурсах можно использовать масштабирование с помощью виртуальных узлов и Экземпляров контейнеров Azure.
События уменьшения масштаба
Средство автомасштабирования кластера также отслеживает состояние планирования pod для узлов, которые не получали новые запросы на планирование в недавнем времени. Этот сценарий указывает, что пул узлов имеет больше вычислительных ресурсов, чем требуется, и количество узлов можно уменьшить. По умолчанию узлы, которые передают пороговое значение, которые больше не требуются в течение 10 минут, запланированы на удаление. При возникновении такой ситуации запуск элементов pod планируются на других узлах в пуле узлов, и средство автомасштабирования кластера уменьшает число узлов.
Работа приложений может ненадолго прерваться при переносе запуска элементов pod на другие узлы, когда средство автомасштабирования кластера уменьшает число узлов. Чтобы свести к минимуму нарушение работы, избегайте приложений, использующих отдельный экземпляр pod.
Автомасштабирование на основе событий Kubernetes (KEDA)
Автомасштабирование на основе событий Kubernetes (KEDA) — это компонент открытый код для автомасштабирования на основе событий рабочих нагрузок. Он масштабирует рабочие нагрузки динамически на основе количества полученных событий. KEDA расширяет Kubernetes с помощью пользовательского определения ресурсов (CRD), называемого ScaledObject, чтобы описать, как приложения должны масштабироваться в ответ на конкретный трафик.
Масштабирование KEDA полезно в сценариях, когда рабочие нагрузки получают всплески трафика или обрабатывают большие объемы данных. Он отличается от горизонтального автомасштабирования Pod, так как KEDA управляет событиями и масштабируется на основе количества событий, а HPA — это метрики, основанные на использовании ресурсов (например, ЦП и памяти).
Чтобы приступить к работе с надстройкой KEDA в AKS, ознакомьтесь с обзором KEDA.
Ускорение до Экземпляры контейнеров Azure (ACI)
Чтобы быстро масштабировать кластер AKS, можно интегрировать его с Экземплярами контейнеров Azure (ACI). В Kubernetes есть встроенные компоненты, которые позволяют масштабировать число реплик и узлов. Однако если приложение должно быстро масштабироваться, горизонтальное автомасштабирование pod может запланировать больше модулей pod, чем может быть предоставлено существующими вычислительными ресурсами в пуле узлов. Если этот сценарий настроен, этот сценарий активирует автомасштабирование кластера для развертывания дополнительных узлов в пуле узлов, но для успешной подготовки этих узлов может потребоваться несколько минут и разрешить планировщику Kubernetes запускать модули pod на них.
ACI позволяет быстро развертывать экземпляры контейнеров без дополнительных затрат на инфраструктуру. При подключении к AKS служба ACI становится защищенным логическим расширением кластера AKS. Компонент виртуальных узлов, основанный на виртуальном Kubelet, устанавливается в кластере AKS, который представляет ACI в качестве виртуального узла Kubernetes. После этого Kubernetes может планировать запуск элементов pod в качестве экземпляров ACI на виртуальных узлах, а не в качестве элементов pod на узлах виртуальных машин непосредственно в кластере AKS.
Приложению не требуется никаких изменений для использования виртуальных узлов. Развертывания могут масштабироваться в AKS и ACI и без задержки, так как средство автомасштабирования кластера развертывает новые узлы в кластере AKS.
Виртуальные узлы развертываются в другую подсеть в той же виртуальной сети, что и кластер AKS. Эта конфигурация виртуальной сети защищает трафик между ACI и AKS. Как и кластер AKS, экземпляр ACI — это безопасный логический вычислительный ресурс, изолированный от других пользователей.
Следующие шаги
Чтобы приступить к работе с приложениями масштабирования, ознакомьтесь со следующими ресурсами:
- Масштабирование элементов pod или узлов вручную.
- Использование средства горизонтального автомасштабирования pod.
- Использование средства автомасштабирования кластера
- Используйте надстройку [Автомасштабирование на основе событий Kubernetes (KEDA)][keda-addon]
Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях: