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

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

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

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

Масштабирование элементов pod или узлов вручную.

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

При уменьшении масштаба узлов API Kubernetes вызывает соответствующий API вычислений Azure, привязанный к типу вычислений, используемому кластером. Например, для кластеров, созданных на основе масштабируемых наборов виртуальных машин, API масштабируемых наборов виртуальных машин определяет, какие узлы следует удалить. Дополнительные сведения о том, как узлы выбираются для удаления при горизонтальном масштабировании, см. в разделе Масштабируемые наборы виртуальных машин вопросы и ответы.

Чтобы начать работать с ручным масштабированием узлов, см. "Масштабирование узлов вручную в кластере AKS". Чтобы вручную масштабировать количество подов, смотрите команду kubectl scale.

Механизм горизонтального автомасштабирования pod

Kubernetes использует горизонтальный автоматический масштабировщик подов (HPA) для отслеживания спроса на ресурсы и автоматического масштабирования количества подов. По умолчанию HPA проверяет API метрик каждые 15 секунд на наличие необходимых изменений в количестве реплик, а API метрик извлекает данные из Kubelet каждые 60 секунд. В результате HPA обновляется каждые 60 секунд. При необходимости изменения количество реплик масштабируется соответствующим образом. HPA работает с кластерами AKS, которые развернули сервер метрик для Kubernetes версии 1.8 и выше.

Горизонтальное автомасштабирование pod в Kubernetes

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

Чтобы приступить к работе со средством горизонтального автомасштабирования подов в AKS, см. раздел Автомасштабирование подов в AKS.

Время ожидания событий масштабирования

Так как HPA эффективно обновляется каждые 60 секунд, предыдущие события масштабирования, возможно, не были успешно завершены до того, как будет выполнена другая проверка. Такое поведение может привести к тому, что HPA изменит количество реплик до того, как предыдущее событие масштабирования получит рабочую нагрузку приложения и требования к ресурсам скорректируются соответствующим образом.

Чтобы избежать событий гонки, задается значение задержки. Это значение определяет время ожидания HPA после события масштабирования перед активацией другого события масштабирования. Такое поведение позволит применить новое число реплик, и API метрик будет отражать распределенную рабочую нагрузку. Нет задержки для событий масштабирования по состоянию на Kubernetes 1.12. Однако задержка по умолчанию для событий уменьшения масштаба составляет 5 минут.

Система автомасштабирования кластера

Чтобы реагировать на изменение требований подов, средство автомасштабирования кластера Kubernetes настраивает количество узлов на основе запрошенных вычислительных ресурсов в пуле узлов. По умолчанию средство автомасштабирования кластера проверяет сервер API метрик каждые 10 секунд на наличие изменений, которые нужно внести в число узлов. Если средство автомасштабирования кластера определяет необходимость изменения, количество узлов в кластере AKS увеличивается или уменьшается соответствующим образом. Автоматическое масштабирование кластера работает с кластерами Kubernetes с поддержкой RBAC AKS, на которых работает Kubernetes 1.10.x или выше.

Средство автомасштабирования кластера Kubernetes

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

Чтобы приступить к работе с автомасштабированием кластера в AKS, см. раздел Автомасштабирование кластера в AKS.

События расширения масштабов

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

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

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

Масштаб в событиях

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

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

Автомасштабирование на основе событий Kubernetes (KEDA)

Автомасштабирование на основе событий Kubernetes (KEDA) — это компонент с открытым исходным кодом для автоматического масштабирования рабочих нагрузок. Он масштабирует рабочие нагрузки динамически на основе количества полученных событий. KEDA расширяет Kubernetes с помощью пользовательского определения ресурсов (CRD), называемого ScaledObject, чтобы описать, как приложения должны масштабироваться в ответ на конкретный трафик.

Масштабирование KEDA полезно в сценариях, когда рабочие нагрузки получают всплески трафика или обрабатывают большие объемы данных. KEDA отличается от горизонтального автомасштабирования подов, так как KEDA является событийно-ориентированным и масштабируется на основе количества событий, а масштабирование в HPA производится на основе использования ресурсов (например, ЦП и памяти).

Чтобы приступить к работе с надстройкой KEDA в AKS, ознакомьтесь с обзором KEDA.

Автоматическое предоставление ресурсов узла

Автоматическая подготовка узла (предварительная версия) (NAP) использует проект Karpenter с открытым исходным кодом, который автоматически развертывает, настраивает и управляет Karpenter в кластере AKS. NAP динамически подготавливает узлы на основе ожидающих требований к ресурсам pod; он автоматически выбирает оптимальный номер SKU виртуальной машины и количество для удовлетворения спроса в режиме реального времени.

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

Плоскость управления: масштабирование и защита

Kubernetes имеет многомерную модель масштабирования, где каждый тип ресурса представляет отдельное измерение. Не все ресурсы одинаковы. Например, часы обычно задаются по секретам, что приводит к вызовам списка вызовов kube-apiserver, которые добавляют затраты и непропорционально высокую нагрузку на плоскость управления по сравнению с ресурсами без часов.

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

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

Чтобы проверить, масштабируется ли уровень управления, проверьте ConfigMap с именем "large-cluster-control-plane-scaling-status"

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Защита уровня управления

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

Чтобы проверить, применена ли защита управляемого сервера API, проверьте наличие FlowSchema и PriorityLevelConfiguration в aks-managed-apiserver-guard .

kubectl get flowschemas
kubectl get prioritylevelconfigurations

Ознакомьтесь с руководством по устранению неполадок сервера API и Etcd, если в кластере были применены FlowSchema и PriorityLevelConfiguration для быстрого принятия мер.

Масштабирование на экземпляры контейнеров Azure (ACI)

Чтобы быстро масштабировать кластер AKS, можно интегрировать его с Azure Container Instances (ACI). В Kubernetes есть встроенные компоненты, которые позволяют масштабировать число реплик и узлов. Однако, если вашему приложению необходимо быстро масштабироваться, горизонтальный автомасштабировщик модулей может запланировать больше модулей, чем существующие вычислительные ресурсы в пуле узлов могут поддержать. Если этот сценарий настроен, он запускает автомасштабирование кластера для развертывания дополнительных узлов в узловом пуле, но на успешное выделение ресурсов для этих узлов может потребоваться несколько минут, прежде чем планировщик Kubernetes сможет запускать на них контейнеры.

Всплесковое масштабирование Kubernetes на ACI

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

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

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

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

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

Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях:

  • Last updated on