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

Статья
03/20/2024

Примечание.

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

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

Помните, что большой является относительным термином. Kubernetes имеет многомерный конверт масштабирования, а конверт масштабирования для рабочей нагрузки зависит от используемых ресурсов. Например, кластер с 100 узлами и тысячами модулей pod или CRD может считаться большим. Кластер узлов с 1000 узлами с 1000 pod и различными другими ресурсами может считаться небольшим с точки зрения плоскости управления. Лучшим сигналом для масштабирования плоскости управления Kubernetes является скорость успешного выполнения http-запроса API сервера HTTP и задержка, так как это прокси-сервер для объема нагрузки на плоскости управления.

В этой статье раскрываются следующие темы:

Масштабируемость плоскости управления AKS и Kubernetes.
Рекомендации клиента Kubernetes, включая обратный выход, часы и разбиение на страницы.
Ограничения регулирования api Azure и платформы.
Ограничения компонентов.
Рекомендации по масштабированию сетевого и пула узлов.

Масштабируемость плоскости управления AKS и Kubernetes

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

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

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

Размер конверта пропорциональен размеру плоскости управления Kubernetes. AKS поддерживает три уровня уровня управления в рамках базового номера SKU: "Бесплатный", "Стандартный" и "Премиум". Дополнительные сведения см. в разделе "Бесплатный", "Стандартный" и "Премиум" для управления кластерами AKS.

Внимание

Настоятельно рекомендуется использовать уровень "Стандартный" или "Премиум" для рабочей или масштабируемой рабочей нагрузки. AKS автоматически масштабирует плоскость управления Kubernetes, чтобы обеспечить следующие ограничения масштабирования:

До 5000 узлов на кластер AKS
200 000 модулей pod на кластер AKS (с наложением Azure CNI)

В большинстве случаев пересечение порогового значения шкалы приводит к снижению производительности, но не приводит к немедленному отработке отказа кластера. Чтобы управлять нагрузкой на плоскость управления Kubernetes, рассмотрите возможность масштабирования в пакетах до 10–20 % текущего масштаба. Например, для кластера узлов 5000 масштабирование увеличивается на 500–1000 узлов. Хотя AKS выполняет автомасштабирование плоскости управления, это не происходит мгновенно.

Вы можете использовать приоритет и справедливость API (APF) для регулирования конкретных клиентов и типов запросов для защиты плоскости управления во время высокой загрузки и загрузки.

Клиенты Kubernetes

Клиенты Kubernetes — это клиенты приложений, такие как операторы или агенты мониторинга, развернутые в кластере Kubernetes, которые должны взаимодействовать с сервером kube-api для выполнения операций чтения или мутации. Важно оптимизировать поведение этих клиентов, чтобы свести к минимуму нагрузку, которую они добавляют на сервер kube-api и плоскость управления Kubernetes.

Вы можете анализировать трафик сервера API и поведение клиента с помощью журналов аудита Kube. Дополнительные сведения см. в разделе "Устранение неполадок с плоскостью управления Kubernetes".

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

Учитывайте количество объектов (CR), которые в конечном итоге будут существовать при определении нового типа ресурса (CRD).
Нагрузка на сервер etcd и API в основном зависит от количества существующих объектов, а не количества возвращаемых объектов. Даже если вы используете селектор полей для фильтрации списка и получения только небольшого количества результатов, эти рекомендации по-прежнему применяются. Единственным исключением является извлечение одного объекта по metadata.name.
Избегайте повторных вызовов LIST, если возможно, если код должен поддерживать обновленный список объектов в памяти. Вместо этого рекомендуется использовать классы информатора, предоставляемые в большинстве библиотек Kubernetes. Информаторы автоматически объединяют функции LIST и WATCH, чтобы эффективно поддерживать коллекцию в памяти.
Рассмотрите необходимость строгой согласованности , если информаторы не соответствуют вашим потребностям. Нужно ли просмотреть последние данные до точного момента, когда вы выпустили запрос? Если нет, задайте ResourceVersion=0. Это приводит к тому, что кэш сервера API обслуживает запрос вместо etcd.
Если вы не можете использовать информаторы или кэш сервера API, считывайте большие списки в блоках.
Избегайте перечисления чаще, чем требуется. Если вы не можете использовать информаторы, рассмотрите частоту перечисления ресурсов приложения. После чтения последнего объекта в большом списке не выполняйте запрос к одному и тому же списку. Вы должны ждать некоторое время вместо этого.
Рассмотрим количество запущенных экземпляров клиентского приложения. Существует большая разница между размещением объектов с одним контроллером и наличием модулей pod на каждом узле, выполняя то же самое. Если вы планируете иметь несколько экземпляров клиентского приложения периодически перечислять большое количество объектов, решение не будет масштабироваться до больших кластеров.

Регулирование API Azure и платформы

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

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

Управление регулированием в AKS

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

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

Всегда обновляйте кластеры Kubernetes до последней версии. Новые версии содержат множество улучшений, которые устраняют проблемы с производительностью и регулированием. Если вы используете обновленную версию Kubernetes и по-прежнему видите регулирование из-за фактической загрузки или количества клиентов в подписке, можно попробовать следующие варианты:

Анализ ошибок с помощью диагностики и решения проблем AKS. Вы можете использовать AKS Для анализа ошибок, идентификации первопричин и получения рекомендаций по разрешению .
- Увеличьте интервал сканирования автомасштабирования кластера: если отчеты диагностики показывают, что обнаружена регулирование автомасштабирования кластера, можно увеличить интервал сканирования, чтобы уменьшить количество вызовов для Масштабируемые наборы виртуальных машин из автомасштабирования кластера.
- Перенастройка сторонних приложений для уменьшения количества вызовов: если вы фильтруете агентыпользователей в диагностике частоты запросов просмотра и регулирования сведений и видите, что стороннее приложение, например приложение мониторинга, делает большое количество запросов GET, можно изменить параметры этих приложений, чтобы уменьшить частоту вызовов GET. Убедитесь, что клиенты приложений используют экспоненциальное обратное отключение при вызове API Azure.
Разделение кластеров на разные подписки или регионы: если у вас есть большое количество кластеров и пулов узлов, использующих Масштабируемые наборы виртуальных машин, их можно разделить на разные подписки или регионы в одной подписке. Большинство ограничений API Azure используются на уровне региона подписки, поэтому вы можете перемещать или масштабировать кластеры в разные подписки или регионы для разблокировки регулирования API Azure. Этот параметр особенно полезен, если вы ожидаете, что кластеры будут иметь высокую активность. Для этих ограничений нет общих рекомендаций. Если требуется конкретное руководство, можно создать запрос в службу поддержки.

Ограничения функций

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

AKS поддерживает масштабирование до 5000 узлов по умолчанию для всех кластеров уровня "Стандартный" или "LTS". AKS масштабирует уровень управления кластера во время выполнения на основе размера кластера и использования ресурсов сервера API. Если вы не можете масштабировать до поддерживаемого ограничения, включите метрики плоскости управления (предварительная версия) с помощью управляемой службы Azure Monitor для Prometheus для мониторинга плоскости управления. Сведения об устранении неполадок с производительностью или надежностью масштабирования см. в следующих ресурсах:
- Руководство по устранению неполадок AKS в масштабе
- Устранение неполадок уровня управления Kubernetes

Примечание.

Во время операции масштабирования плоскости управления может возникнуть задержка или время ожидания сервера API с повышенными привилегиями до 15 минут. Если у вас по-прежнему возникают проблемы с масштабированием до поддерживаемого ограничения, откройте запрос в службу поддержки.

Диспетчер политик сети Azure (Azure npm) поддерживает только до 250 узлов.
Некоторые метрики узлов AKS, включая использование диска узла, использование ЦП и памяти узла и сетевое подключение, не будут доступны в метриках платформы Azure Monitor после увеличения масштаба плоскости управления. Чтобы убедиться, что плоскость управления масштабирована, найдите конфигурацию карты "control-plane-scaling-status"

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

Вы не можете использовать функцию остановки и запуска с кластерами, имеющими более 100 узлов. Дополнительные сведения см. в статье "Остановка и запуск кластера AKS".

Сеть

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

Используйте управляемый NAT для исходящего трафика кластера по крайней мере с двумя общедоступными IP-адресами на шлюзе NAT. Дополнительные сведения см. в статье "Создание управляемого шлюза NAT" для кластера AKS.
Используйте наложение Azure CNI для масштабирования до 200 000 модулей pod и 5 000 узлов на кластер. Дополнительные сведения см. в статье "Настройка сети наложения Azure CNI" в AKS.
Если приложению требуется прямая связь между кластерами pod и pod, используйте Azure CNI с динамическим выделением IP-адресов и масштабируйте до 50 000 модулей pod приложений на кластер с одним routable IP-адресом для каждого модуля pod. Дополнительные сведения см. в статье Настройка сети Azure CNI для динамического распределения IP-адресов в AKS.
При использовании внутренних служб Kubernetes за внутренней подсистемой балансировки нагрузки рекомендуется создать внутреннюю подсистему балансировки нагрузки или службу ниже 750 узлов, чтобы обеспечить оптимальную производительность масштабирования и эластичность подсистемы балансировки нагрузки.
Azure npm поддерживает только до 250 узлов. Если вы хотите применить политики сети для крупных кластеров, рассмотрите возможность использования Azure CNI на базе Cilium, которая объединяет надежную плоскость управления Azure CNI с плоскостем данных Cilium для обеспечения высокой производительности сети и безопасности.

Масштабирование пула узлов

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

Для пулов системных узлов используйте номер SKU Standard_D16ds_v5 или эквивалентный номер SKU виртуальной машины ядра или памяти с временными дисками ОС, чтобы обеспечить достаточные вычислительные ресурсы для модулей pod kube-system.
Так как AKS имеет ограничение в 1000 узлов на пул узлов, рекомендуется создавать по крайней мере пять пулов пользовательских узлов для масштабирования до 5000 узлов.
При выполнении кластеров AKS в масштабе используйте автомасштабирование кластера, если это возможно, чтобы обеспечить динамическое масштабирование пулов узлов в зависимости от спроса на вычислительные ресурсы. Дополнительные сведения см. в статье "Автоматическое масштабирование кластера AKS для удовлетворения требований приложения".
Если вы масштабируете более 1000 узлов и не используете автомасштабирование кластера, рекомендуется масштабировать в пакетах из 500-700 узлов одновременно. Операции масштабирования должны иметь двухминутное до пятиминутного времени ожидания между операциями масштабирования, чтобы предотвратить регулирование API Azure. Дополнительные сведения см. в разделе "Управление API: кэширование и регулирование политик".