CCE Cluster Autoscaler

Дополнение CCE Cluster Autoscaler построено на компоненте Autoscaler сообщества. Оно может автоматически регулировать количество узлов кластера в зависимости от потребностей приложений в ресурсах, оптимизируя использование ресурсов и производительность. Autoscaler является основным контроллером в Kubernetes. Он может автоматически масштабировать узлы вверх или вниз в соответствии с требованиями к ресурсам. Когда ресурсов узлов недостаточно для размещения pod‑ов в кластере, Autoscaler добавляет дополнительные узлы с необходимыми ресурсами для этих pod‑ов. Кроме того, если использование ресурсов добавленных узлов низкое, Autoscaler автоматически удалит их. Для получения подробной информации о реализации автоматического масштабирования узлов см. Creating a Node Auto Scaling Policy.

Сообщество с открытым исходным кодом: https://github.com/kubernetes/autoscaler

CCE Cluster Autoscaler управляет автоматическим масштабированием наружу и внутрь.

• Автоматическое масштабирование наружу

  Вы можете выбрать любой из следующих методов:

  • Если pod не может быть запланирован из‑за недостаточных ресурсов рабочих узлов, CCE добавит в кластер дополнительные узлы. Новые узлы имеют те же квоты ресурсов, что и те, которые настроены для пулов узлов, в которых находятся новые узлы.

    Автоматическое масштабирование наружу будет выполнено, когда:

    • Ресурсы узла недостаточны.
    • В конфигурациях планирования pod не задана политика привязки к узлу. Если для pod настроена привязка к узлу, система не будет автоматически добавлять дополнительные узлы в кластер. Для получения подробной информации о настройке политик привязки к узлам см. Configuring Node Affinity Scheduling (nodeAffinity).

  • Когда кластер соответствует политике масштабирования узлов, также инициируется масштабирование кластера наружу. Для получения подробной информации см. Creating a Node Auto Scaling Policy.
  Note

  Дополнение следует политике «No Less, No More». Например, если для создания pod требуется три ядра, а система поддерживает узлы с четырьмя и восемью ядрами, Autoscaler предпочтительно создаст узел с четырьмя ядрами.

• Автоматическое масштабирование внутрь

  Если предварительно выделенные CPU и память узла остаются ниже порога scale-in в течение продолжительного периода (по умолчанию 10 минут), кластер инициирует операцию scale-in, автоматически удаляя недостаточно используемый узел. Однако узел нельзя удалить из кластера, если существуют следующие pods:

  • Pods, которые не соответствуют конкретным требованиям, установленным в Pod Disruption Budgets (PodDisruptionBudget)
  • Pods, которые не могут быть запланированы на другие узлы из‑за ограничений, таких как политики аффинити и анти‑аффинити
  • Поды, имеющие аннотацию cluster-autoscaler.kubernetes.io/safe-to-evict: 'false'
  • Поды (за исключением тех, которые созданы DaemonSets в пространстве имён kube-system), находящиеся в пространстве имён kube-system
  • Поды, которые не созданы контроллерами (например, Deployments, ReplicaSets, jobs и StatefulSets)
  Note

  • Когда узел удовлетворяет условиям масштабирования‑вниз, CCE Cluster Autoscaler заранее добавит к узлу taint DeletionCandidateOfClusterAutoscaler, чтобы предотвратить планирование подов на этот узел. После удаления дополнения CCE Cluster Autoscaler, если taint всё ещё присутствует на узле, удалите его вручную.
  • Чтобы обеспечить стабильность системы и эффективное использование ресурсов, CCE Cluster Autoscaler использует консервативную политику. Узлы, которые не полностью простаивают, высвобождаются по одному. Когда эти узлы размещают pods, настроенные на graceful termination, процесс высвобождения может быть длительным. В результате общий процесс scale-in может занять больше времени.

• Во время установки дополнения в кластере должно быть достаточно ресурсов.
• Это дополнение поддерживает VM nodes, но не поддерживает PM nodes.
• Пул узлов по умолчанию не поддерживает auto scaling. Подробнее см. Description of DefaultPool.
• При scale-in узла произойдет потеря данных PVC/PV для local PVs, связанных с узлом. Эти PVC и PV нельзя восстановить или использовать повторно. При scale-in узла pod, использующий local PV, будет выгружен с узла. Будет создан новый pod, но он останется в состоянии pending. Это происходит потому, что PVC, используемый pod'ом, имеет метку узла, из‑за чего pod не может быть запланирован.
• При использовании CCE Cluster Autoscaler некоторые taint'ы или аннотации могут влиять на auto scaling. Поэтому не используйте следующие taint'ы или аннотации в кластерах:
  • ignore-taint.cluster-autoscaler.kubernetes.io: Taint применяется к узлам. Autoscaler, основанный на Kubernetes, поддерживает защиту от аномальных scale-out'ов и периодически оценивает долю доступных узлов в кластере. Когда доля неготовых узлов превышает 45 %, защита срабатывает. В этом случае все узлы с taint ignore-taint.cluster-autoscaler.kubernetes.io в кластере исключаются из шаблона Autoscaler и фиксируются как неготовые узлы, что влияет на масштабирование кластера.
  • cluster-autoscaler.kubernetes.io/enable-ds-eviction: Аннотация применяется к pod'ам и определяет, могут ли pod'ы DaemonSet быть вытеснены Autoscaler. Для получения подробной информации см. Well-Known Labels, Annotations and Taints.
• CCE Cluster Autoscaler версии ранее 1.27.205, 1.28.172, 1.29.134, 1.30.100, 1.32.38, 1.33.31 и 1.31.62 не поддерживает развертывание одновременно Snt9 и CPU узлов в одном кластере. Если оба типа узлов работают в одном кластере, узлы Snt9 будут рассматриваться как неготовые узлы. Когда доля неготовых узлов превышает 45 % от общего количества, срабатывает система защиты. Это повлияет на масштабирование пулов CPU узлов в кластере.

1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Add-ons. Найдите CCE Cluster Autoscaler справа и нажмите Install.
3. На странице Install Add-on настройте спецификации по необходимости.

   Существует три типа preset specifications в зависимости от масштаба кластера. Вы можете выбрать один по требованию. Система настроит количество pod'ов и квоты ресурсов для add-on на основе выбранных preset specifications. Вы можете просмотреть конфигурации в консоли.

   Если ваш кластер большой и preset specifications не удовлетворяют вашим требованиям, вы можете настроить спецификации ресурсов и оценить количество pod'ов в кластере, чтобы точнее определить использование памяти add-on. Рекомендуемые запрос и лимит памяти в типичных крупных кластерах можно вычислить следующим образом:

   • Запрос памяти = Количество pod'ов × Размер YAML‑файлов pod'ов (KB)/10000 × 0.28 GiB + 1 GiB
   • Лимит памяти = Запрос памяти + 2 GiB

   Например, при 20 000 pod'ов и размере YAML‑файла каждого pod'а 10 KB запрос памяти составит 6,6 GiB (2 × 10 × 0.28 GiB + 1 GiB), а лимит памяти — 8,6 GiB (6.6 GiB + 2 GiB). (Вычисленные значения могут отличаться от рекомендаций, указанных в Table 1. Вы можете обратиться к этой таблице или использовать эти формулы.)

   Table 1 Рекомендуемый размер памяти add-on в сценариях крупномасштабных развертываний

   Количество pod'ов (10 KB для каждого YAML‑файла pod'а)	Рекомендуемый запрос памяти	Рекомендуемый лимит памяти
   10000	4 GiB	6 GiB
   30000	8 GiB	10 GiB
   50000	16 GiB	18 GiB
   80000	24 GiB	26 GiB
   100000	28 GiB	30 GiB

4. Настройте политики развертывания для add-on pods.
   Note

   • Политики планирования не применяются к pod‑ам DaemonSet add-on.
   • При настройке развертывания multi-AZ или привязки к узлам убедитесь, что существуют узлы, соответствующие политике планирования, и что ресурсы в кластере достаточны. В противном случае pod‑ы add-on не смогут запуститься.

   Table 2 Конфигурации планирования add-on

   Параметр	Описание
   Multi-AZ Deployment	Preferred: pods развертывания дополнения будут предпочтительно планироваться на узлы в разных AZ. Если все узлы кластера развернуты в одной AZ, поды будут планироваться на разные узлы в этой AZ. Equivalent mode: pods развертывания дополнения равномерно планируются на узлы кластера в каждой AZ. Если добавлена новая AZ, рекомендуется увеличить количество pods дополнения для развертывания HA с перекрестным AZ. При Equivalent multi-AZ deployment разница в количестве pods дополнения в разных AZ будет не более 1. Если ресурсы в одной из AZ недостаточны, pods не могут быть запланированы в эту AZ. Forcible: pods развертывания дополнения принудительно планируются на узлы в разных AZ. В каждой AZ может быть не более одного pod. Если узлы кластера не находятся в разных AZ, некоторые pods дополнения могут работать некорректно. Если узел неисправен, pods дополнения на нём могут не быть перенесены.
   Node Affinity	Not configured: Node affinity отключена для pods дополнения. Specify node: Укажите узлы, на которых развертываются pods дополнения. Если узлы не указаны, pods дополнения будут случайным образом планироваться в соответствии с политикой планирования кластера по умолчанию. Specify node pool: Укажите пул узлов, в котором развертываются pods дополнения. Если пул узлов не указан, pods дополнения будут случайным образом планироваться в соответствии с политикой планирования кластера по умолчанию. Customize affinity: Введите метки узлов, на которых должны быть развернуты pods дополнения, для более гибкой политики планирования. Если метки узлов не указаны, pods дополнения будут случайным образом планироваться в соответствии с политикой планирования кластера по умолчанию. Если настроено несколько пользовательских политик affinity, убедитесь, что в кластере есть узлы, соответствующие всем политикам affinity. В противном случае pods дополнения не смогут работать.
   Toleration	Использование как taints, так и tolerations позволяет (но не требует) планировать pods Deployment дополнения на узлы с соответствующими taints и дает возможность управлять политиками выселения pod'ов, когда узлы‑хосты помечены taints. Дополнение применяет tolerations по умолчанию для taint node.kubernetes.io/not-ready и taint node.kubernetes.io/unreachable. Временное окно toleration составляет 60 секунд. Для получения подробной информации см. Configuring Tolerance Policies.

5. После завершения настройки нажмите Install.