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

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

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

В этой статье вы узнаете:

Руководство по режиму AKS для больших рабочих нагрузок

AKS поддерживает два режима кластера:

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

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

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

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

• При эксплуатации крупных кластеров AKS по возможности используйте автомасштабирование кластера или автоматическое выделение узлов (NAP), чтобы обеспечить динамическое масштабирование узлов в зависимости от потребности в вычислительных ресурсах.
• AkS Automatic является рекомендуемой отправной точкой для большинства рабочих нагрузок, но большие кластеры в любом режиме кластера по-прежнему требуют тщательного масштабирования узлов, пакетного планирования и проверки плоскости управления.
• Если вы масштабируете более 1000 узлов и не используете автомасштабирование кластера, рекомендуется масштабировать в пакетах из 500-700 узлов одновременно. Между операциями увеличения масштаба следует выдерживать интервал от двух до пяти минут, чтобы предотвратить ограничение частоты запросов к API Azure.
• Для пулов системных узлов используйте номер SKU Standard_D16ds_v5 или эквивалентный номер SKU виртуальной машины ядра или памяти с временными дисками ОС, чтобы обеспечить достаточные вычислительные ресурсы для модулей pod kube-system.
• Так как AKS имеет ограничение в 1000 узлов на пул узлов, рекомендуется создавать по крайней мере пять пулов пользовательских узлов для масштабирования до 5000 узлов.

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

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

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

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

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

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

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

Чтобы убедиться, что уровень управления был масштабирован, найдите карту конфигурации large-cluster-control-plane-scaling-status.

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

Рекомендации по масштабированию границ Kubernetes и контрольной плоскости управления

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

AKS Automatic не устраняет необходимость в эффективном поведении клиента; для крупных кластеров по-прежнему требуются паттерны, основанные на watch-запросах, пагинация, механизмы backoff и ограничение трафика LIST-запросов.

Число запросов, активно обрабатываемых сервером API в любой момент, определяется --max-requests-inflight и --max-mutating-requests-inflight флагами. AKS использует значения по умолчанию 400 и 200 запросов для этих флагов, что позволяет отправлять в течение определенного времени 600 запросов. Так как мы масштабируем сервер API до более крупных размеров, мы соответствующим образом увеличиваем запросы на полет.

Два типа объектов Kubernetes, PriorityLevelConfiguration и FlowSchema (APF) определяют, как сервер API делит общую емкость запросов по типам запросов. AKS использует конфигурацию по умолчанию.

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

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

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

Сопоставление FlowSchemas с PriorityLevelConfigurations можно просмотреть с помощью этой команды:

kubectl get flowschemas

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

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Рекомендации клиента Kubernetes

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

• Учитывайте количество объектов (CR), которые в конечном итоге будут существовать при определении нового типа ресурса (CRD).
• Нагрузка на сервер etcd и API в основном зависит от размера ответа. Это руководство применяется, если клиент выдает небольшое количество запросов LIST для больших объектов или большое количество запросов LIST для небольших объектов.

Использование информаторов

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

Использование кэша сервера API

Используется resourceVersion=0 для возврата результатов из кэша сервера API. Это может предотвратить получение объектов из etcd, тем самым уменьшая нагрузку на etcd, но он не поддерживает разбиение на страницы.

/api/v1/namespaces/default/pods?resourceVersion=0

Эффективное использование API Kubernetes

По возможности рекомендуется использовать аргумент watch. Без аргументов поведение по умолчанию — вывод списка объектов. Рассмотрим пример.

/api/v1/namespaces/default/pods?watch=true

Используйте часы с набором resourceVersion, чтобы установить самое последнее известное значение, полученное из предшествующего списка или часов. Эта обработка выполняется автоматически в client-go. Но проверьте, используется ли клиент Kubernetes на других языках.

/api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>

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

• Оптимизированный СПИСОК:

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running
  

• Неоптимизованный СПИСОК:

  /api/v1/pods
  

Используйте разбиение на страницы , чтобы уменьшить размер ответов LIST, если клиент должен получить данные из etcd. В следующем примере используется аргумент ограничения для ограничения ответа до 100 объектов.

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100

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

/api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>

Если используется kubectl, --chunk-size аргумент можно применить непосредственно для постраничного вывода ответов.

kubectl get pods -n default --chunk-size=100

Если ваши контроллеры или операторы используют обновления аренды для выборов лидера, убедитесь, что они устойчивы к временным проблемам соединения, оптимизируя leaseDuration, renewDeadline и retryPeriod для ваших рабочих нагрузок. Для контроллеров Kubernetes, использующих выборы лидера клиента, используйте следующую формулу:

lease_duration > renew_deadline > retry_period

Демонсеты

• Существует значительное различие между контроллером, который перечисляет объекты, и DaemonSet, работающим на каждом узле и выполняющим то же самое. Если несколько экземпляров клиентского приложения периодически перечисляют большое количество объектов, решение не будет хорошо масштабироваться в больших кластерах.

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

• Используйте стратегию RollingUpdate, чтобы постепенно развертывать новые pod DaemonSet. При обновлении шаблона DaemonSet контроллер заменяет старые модули pod новыми управляемым образом. Если стратегия последовательного обновления не настроена явно, Kubernetes будет по умолчанию создавать RollingUpdate с maxUnavailable равным 1, maxSurge равным 0 и minReadySeconds равным 0 секунд. См. следующий пример.

    minReadySeconds: 30
    updateStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 0
        maxUnavailable: 1
  

• Стратегия RollingUpdate применяется только к существующим модулям pod DaemonSet. Это не ограничивает влияние добавления новых узлов, что создает дополнительные модули pod DaemonSet или развертывает совершенно новые daemonSets.

• Чтобы предотвратить одновременное выполнение запросов LIST на сервер API во время запуска после увеличения числа узлов или новых развертываний DaemonSet, реализуйте разброс времени запуска в точке входа контейнера и настройте соответствующие политики экспоненциального отката и повторных попыток для ответов 5xx или 429, чтобы избежать повторных попыток выполнения больших запросов LIST.

    spec:
      template:
        spec:
          containers:
          - name: my-daemonset-container
            image: <image>
            command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]
  

Оптимизация etcd

• Поддерживайте общий размер etcd небольшим и не используйте etcd в качестве базы данных общего назначения. AKS предоставляет 8 ГБ хранилища etcd по умолчанию, но большие базы данных etcd увеличивают время дефрагментации, что может привести к проблемам с производительностью чтения и записи. Более крупные базы данных etcd также могут увеличить вероятность возникновения проблем с надежностью сервера API и etcd, если неоптимизированный клиент часто получает большое количество объектов из etcd. Если размер базы данных etcd превышает 2 ГБ, рассмотрите возможность использования методов уменьшения размера объекта, перечисленных ниже.
• Чтобы уменьшить размеры спецификаций pod, переместите переменные среды из спецификаций pod в ConfigMaps.
• Разделение больших секретов или ConfigMaps на более мелкие, более управляемые части.
• Храните секреты в Azure Key Vault вместо Kubernetes Secrets по возможности, чтобы сократить количество секретов в etcd.
• Очистка неиспользуемых объектов
  • Удаление устаревших заданий и завершенных модулей pod. Используйте ttlSecondsAfterFinished для заданий, чтобы готовые объекты были удалены автоматически.
  • Убедитесь, что контроллеры задают ownerReferences. Это позволяет сборщику мусора Kubernetes автоматически удалять зависимые объекты при удалении родительского ресурса.
  • Ограничение журнала CronJob путем задания successfulJobsHistoryLimit и failedJobsHistoryLimit, чтобы сохранить только небольшое количество записей о выполненных заданиях.
  • Сократите историю развертывания. Старые наборы реплик хранятся в качестве объектов API. Значение по умолчанию — 10.
• Уменьшите историю редакций Helm с помощью аргумента --history-max. В больших кластерах сохраните его ниже 5.

Мониторинг метрик и журналов контрольной плоскости AKS

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

AKS Automatic сокращает операционные затраты, но при высокой нагрузке вам по-прежнему нужен тот же уровень наблюдаемости за состоянием плоскости управления, задержкой запросов и нагрузкой на etcd.

Azure Monitor предлагает комплексные метрики и журналы работоспособности плоскости управления через Azure Managed Prometheus и Diagnostic settings.

• Список оповещений для настройки работоспособности плоскости управления см. в статье "Рекомендации по мониторингу плоскости управления AKS"
• Чтобы получить список агентов пользователей с наибольшей задержкой, можно использовать журналы уровня управления или параметры диагностики.

Метрики платформы уровня управления ключами

AKS предоставляет следующие метрики платформы в Azure Monitor для мониторинга состояния сервера API и etcd. Эти метрики доступны без включения Управляемого Prometheus и могут просматриваться непосредственно на портале Azure в разделе Метрики для кластера AKS.

Метрики сервера API:

Метрики etcd:

Постоянно отслеживайте apiserver_cpu_usage_percentage и apiserver_memory_usage_percentage, чтобы обнаруживать давление ресурсов на сервере API. Если etcd_database_usage_percentage стабильно превышает 50%, ознакомьтесь с разделом Оптимизация etcd, чтобы уменьшить размер базы данных. Полный список доступных метрик см. в справочнике по данным мониторинга AKS.

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

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

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

  • Руководство по устранению неполадок AKS в масштабе
  • Устранение неполадок уровня управления Kubernetes

  Примечание

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

• Azure Диспетчер политик сети (Azure npm) поддерживает только до 250 узлов.

• Некоторые метрики узлов AKS, включая использование диска узла, использование ЦП/памяти узла и сетевые показатели ин/аут, не будут доступны в платформенных метриках Azure Monitor после масштабирования плоскости управления.

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

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

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

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

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

Управление ограничением скорости в AKS

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

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

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

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

Сетевые технологии

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

• Используйте управляемый NAT для исходящего трафика кластера по крайней мере с двумя общедоступными IP-адресами на шлюзе NAT. Дополнительные сведения см. в статье "Создание управляемого шлюза NAT" для кластера AKS.

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

• Если вы используете Azure Load Balancer (цен. категория "Стандартный"), используйте по крайней мере 2 исходящие общедоступные IP-адреса. Кроме того, при планировании больших кластеров следует учитывать ограничения внутреннего правила серверной части службы LoadBalancer. Azure Подсистемы балансировки нагрузки уровня "Стандартный" поддерживают до 10 000 внутренних IP-конфигураций на интерфейсный IP-адрес. Каждый тип: служба LoadBalancer создает одно правило балансировки нагрузки на предоставленный порт и связывает все узлы кластера с серверным пулом подсистемы балансировки нагрузки. Например, предоставление 5 портов для одного сервиса достигнет этого лимита при 2000 узлах.

  1 service * 5 ports * 2000 nodes = 10000 backend IP configurations
  

• Используйте Azure наложение CNI для масштабирования до 200 000 модулей pod и 5 000 узлов на кластер. Дополнительные сведения см. в разделе Настройка сетей наложения CNI в Azure AKS.

• Если вашему приложению требуется прямое взаимодействие подов между кластерами, используйте Azure CNI с динамическим выделением IP-адресов и масштабируйте до 50 000 подов приложения на кластер с одним маршрутизируемым IP-адресом для каждого пода. Дополнительные сведения см. в разделе Настройка сети Azure CNI для динамического выделения IP-адресов в AKS.

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

• Azure диспетчер сетевых политик (NPM) поддерживает только до 250 узлов. Если вы хотите применить политики сети для больших кластеров, рассмотрите возможность использования Azure CNI на основе Cilium, которая объединяет надежную плоскость управления Azure CNI с плоскостем данных Cilium для обеспечения высокой производительности сети и безопасности.

• Включите LocalDNS в пулах узлов, чтобы уменьшить задержку разрешения DNS и разгрузить централизованные pod CoreDNS. В больших кластерах с большим объемом запросов DNS централизованное разрешение DNS может стать узким местом. LocalDNS развертывает DNS-прокси в качестве systemd службы на каждом узле, разрешая запросы локально, снижая нагрузку на таблицу conntrack и переводя подключения на TCP, чтобы избежать conntrack состояний гонки. LocalDNS также поддерживает обслуживание устаревших кэшированных ответов при недоступности вышестоящего DNS, что повышает устойчивость рабочей нагрузки во время временных сбоев. Для получения дополнительной информации смотрите разрешение DNS в AKS.

Рекомендации по обновлению кластера и лучшие практики

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

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

• Когда кластер достигает ограничения на 5000 узлов, обновления кластера блокируются. Это ограничение предотвращает обновление, так как емкость узла недоступна для выполнения последовательного обновления в пределах максимального предела свойства всплеска. Если у вас есть кластер с таким ограничением, рекомендуется уменьшить масштаб кластера до 3000 узлов перед попыткой обновления кластера. Это обеспечит дополнительную емкость для обработки узлов и минимизации нагрузки на плоскости управления.
• При обновлении кластеров с более чем 500 узлами рекомендуется использовать максимальную конфигурацию всплеска 10–20% емкости пула узлов. AKS настраивает обновления со значением по умолчанию 10% для максимального всплеска. Можно настроить максимальные параметры всплеска на пул узлов, чтобы обеспечить компромисс между скоростью обновления и нарушением рабочей нагрузки. При увеличении максимальных параметров всплеска процесс обновления завершается быстрее, но во время процесса обновления может возникнуть сбои. Для получения дополнительной информации смотрите Настройка обновления узлового скачка.
• Дополнительные сведения об обновлении кластера см. в статье об обновлении кластера AKS.

Связанный контент

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