Обзор автомасштабирования кластера в "Службе Azure Kubernetes" (AKS)

Чтобы обеспечить соответствие требованиям приложений в Служба Azure Kubernetes (AKS), может потребоваться настроить количество узлов, выполняющих рабочие нагрузки. Компонент автомасштабирования кластера следит за pods в вашем кластере, которые не могут быть запланированы из-за ограничений ресурсов кластера. Когда кластерный автомасштабировщик обнаруживает незапланированные pods, он увеличивает количество узлов в пуле узлов в соответствии с требованиями приложения. Он также регулярно проверяет узлы, которые не имеют запланированных pod, и масштабирует количество узлов по мере необходимости.

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

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

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

• Автомасштабирование кластера периодически проверяет наличие подов, которые не могут быть размещены на узлах из-за ограничений ресурсов. При возникновении такой ситуации число узлов в кластере автоматически повышается. При использовании средства автомасштабирования кластера отключается возможность масштабирования вручную. Дополнительные сведения см. в статье о том, как масштабировать работу?.
• Функция горизонтального автомасштабирования pod использует сервер метрик в кластере Kubernetes для мониторинга спроса на ресурсы модулей pod. Если приложению нужно больше ресурсов, количество pod автоматически увеличивается в соответствии с требованиями.
• Средство автомасштабирования вертикального модуля pod автоматически задает запросы ресурсов и ограничения на контейнеры для каждой рабочей нагрузки на основе предыдущего использования, чтобы обеспечить планирование модулей pod на узлах с необходимыми ресурсами ЦП и памяти.

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

Лучшие методики и рекомендации

• При реализации зон доступности с помощью автомасштабирования кластера рекомендуется использовать один пул узлов для каждой зоны. Вы можете задать параметр --balance-similar-node-groups на True в целях поддержания сбалансированного распределения узлов между зонами для ваших рабочих нагрузок во время операций масштабирования. Если этот подход не реализован, операции уменьшения масштаба могут нарушить баланс узлов между зонами.

• Для кластеров с более чем 400 узлами рекомендуется использовать Azure CNI или наложение Azure CNI.

• Чтобы эффективно выполнять рабочие нагрузки одновременно в пулах узлов spot и on-demand, рассмотрите возможность использования расширителей приоритета. Этот подход позволяет масштабировать пулы узлов на основе назначенного приоритета. Следующая конфигурация иллюстрирует эту настройку.

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: cluster-autoscaler-priority-expander
    namespace: kube-system
  data:
    priorities: |-
      10: 
        - .*spotpool1.*
        - .*spotpool2.*
      50: 
        - .*ondemandpool1.*
  

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

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

• Используйте PodDisruptionBudget, чтобы предотвратить ненужные операции освобождения узлов или масштабирования вниз. Указание аннотации cluster-autoscaler.kubernetes.io/safe-to-evict: "false" в спецификации Pod также предотвратит выселение модулей. Используйте эту аннотацию с осторожностью, так как это может привести к тому, что автомасштабировщик кластера столкнется с проблемами при очистке узла с работающим Pod, содержащим эту аннотацию.

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

• Узлы не масштабируются, если значение PriorityClass подов ниже -10. Приоритет -10 зарезервирован для чрезмерной подготовки модулей pod. Дополнительные сведения см. в разделе "Использование автомасштабирования кластера с приоритетами подов и вытеснением".

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

• Автомасштабирование кластера может быть не в состоянии уменьшить масштаб, если модули pod не могут перемещаться, например в следующих ситуациях:

  • Непосредственно созданный модуль pod, не поддерживаемый объектом контроллера, например Deployment или ReplicaSet.
  • Бюджет прерывания pod (PDB), который слишком строгий и не позволяет количеству модулей pod упасть ниже определенного порогового значения.
  • если pod использует селекторы узла или свойства удаления сходства, которые невозможно выполнить, так как они запланированы на другом узле. Дополнительные сведения см. в статье о том, какие типы модулей pod могут запретить автомасштабированию кластера удалять узел?.

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

Профиль автомасштабирования кластера

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

Оптимизация профиля автомасштабирования кластера

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

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

Пример 1. Оптимизация производительности

Для кластеров, обрабатывающих значительные и временные рабочие нагрузки с основным акцентом на производительность, рекомендуется увеличить scan-interval и уменьшить scale-down-utilization-threshold. Эти параметры помогают пакетировать несколько операций масштабирования в один вызов, оптимизируя время масштабирования и использование квот вычислений чтения и записи. Это также помогает снизить риск быстрого масштабирования операций на недоиспользуемых узлах, повышая эффективность планирования подов. Кроме того, увеличьте ok-total-unready-countи max-total-unready-percentage.

Для кластеров с pod daemonset, мы рекомендуем задать значение ignore-daemonsets-utilization на true, что эффективно игнорирует использование узлов pod daemonset и минимизирует ненужные операции по уменьшению масштаба. Смотрите профиль для всплесковых рабочих нагрузок

Пример 2. Оптимизация затрат

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

• Уменьшите scale-down-unneeded-time, что является временем, спустя которое узел считается ненужным, прежде чем он будет уменьшен.
• Уменьшите scale-down-delay-after-add время ожидания, которое необходимо после добавления узла, прежде чем рассматривать его для уменьшения размера.
• Увеличьте значение scale-down-utilization-threshold, которое является пороговым значением использования для удаления узлов.
• Увеличьте max-empty-bulk-deleteмаксимальное количество узлов, которые можно удалить в одном вызове.
• Установите skip-nodes-with-local-storage в значение false.
• Увеличьте ok-total-unready-count и max-total-unready-percentage.

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

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

Не активируя операции масштабирования

Сбои операций масштабирования

Сокращение отказов операций

Другие проблемы

Пул узлов в резервном режиме

Пул узлов в режиме ожидания был введён в версии 0.6.2 и приводит к тому, что автомасштабирование кластера прекращает масштабировать пул узлов после сбоя.

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