CCE Кластер Autoscaler

Введение

Как работает дополнение

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

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

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

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

    • Ресурсы узла недостаточны.
    • Политика привязки к узлам не задана в конфигурациях планирования pod. Если для pod настроена привязка к узлу, система не будет автоматически добавлять дополнительные узлы в кластер. Подробную информацию о том, как настроить политики привязки к узлам, см. Настройка планирования привязки к узлам (nodeAffinity).

  • Когда кластер соответствует политике масштабирования узлов, также инициируется масштабирование кластера. Подробности см. Создание политики автоматического масштабирования узлов.
  Note

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

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

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

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

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

Примечания и ограничения

• Во время установки add-on в кластере должно быть достаточно ресурсов.
• Это add-on поддерживает VM узлы и не поддерживает PM узлы.
• Пул узлов по умолчанию не поддерживает авто масштабирование. Для подробностей см. Описание DefaultPool.
• Снижение масштаба узла может вызвать потерю данных PVC/PV для локальные PV associated with the node. These PVC and PV cannot be restored or used again. In a node scale-in, a pod that uses the local PV will be evicted from the node. A new pod will be created, but it remains in a pending state because the label of the PVC bound to it conflicts with the node label.
• When CCE Cluster Autoscaler is used, some taint'ы or annotations may affect auto scaling. Therefore, do not use the following taint'ы or annotations in clusters:
  • ignore-taint.cluster-autoscaler.kubernetes.io: The taint works on nodes. Kubernetes-native Autoscaler supports protection against abnormal scale-outs and periodically evaluates the proportion of available nodes in the cluster. When the proportion of non-ready nodes exceeds 45%, protection will be triggered. In this case, all nodes with this taint in the cluster are filtered out from the Autoscaler template and recorded as non-ready nodes, which affect cluster scaling.
  • cluster-autoscaler.kubernetes.io/enable-ds-eviction: The annotation works on pods, which determines whether DaemonSet pods can be evicted by Autoscaler. For details, see 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 консоль и нажмите название кластера, чтобы перейти в консоль кластера.
2. В навигационной панели выберите Дополнения. Найдите CCE Cluster Autoscaler справа и нажмите Установить.
3. В Установить дополнение странице, настройте параметры по мере необходимости.

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

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

   • Запрос памяти = Number of pods × Size of the pod YAML files (KB)/10000 × 0.28 GiB + 1 GiB
   • Память ограничение =Запрос памяти + 2 GiB

   Например, если существует 20,000 подов и размер YAML file каждого пода составляет 10 KB, запрос памяти будет 6.6 GiB (2 × 10 × 0.28 GiB + 1 GiB) и ограничение памяти будет 8.6 GiB (6.6 GiB + 2 GiB). (Рассчитанные значения могут отличаться от рекомендаций, указанных в Таблица 1. Вы можете обратиться к этой таблице или использовать эти формулы.)

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

   Количество Под (10 KB для каждого Под YAML)	Рекомендуемый запрос памяти	Рекомендуемый лимит памяти
   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 подов.
   Note

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

   Таблица 2 Конфигурации планирования дополнения

   Параметр	Описание
   Multi-AZ Развертывание	Предпочтительно: Pod'ы развертывания дополнения будут предпочтительно размещаться на узлах в разных AZ. Если все узлы в кластере находятся в одной AZ, pod'ы будут размещаться на разных узлах в этой AZ. Эквивалентный режим: Pod'ы развертывания дополнения равномерно распределяются по узлам кластера в каждой AZ. Если добавлена новая AZ, рекомендуется увеличить количество pod'ов дополнения для HA‑развертывания с перекрёстной AZ. При Эквивалентном multi-AZ развертывании разница в количестве pod'ов дополнения в разных AZ будет не более 1. Если ресурсы в одной из AZ недостаточны, pod'ы не могут быть размещены в этой AZ. Принудительно: Поды развертывания дополнения принудительно планируются на узлы в разных AZ. В каждом AZ может быть не более одного pod. Если узлы кластера находятся не в разных AZ, некоторые pod дополнения могут работать некорректно. Если узел неисправен, pod дополнения на нём могут не быть перенесены.
   Аффинитет узла	Не настроено: Аффинитет узла отключен для дополнения. Указать узел: Укажите узлы, на которых развернуто дополнение. Если узлы не указаны, дополнение будет планироваться случайным образом в соответствии с политикой планирования кластера по умолчанию. Указать пул узлов: Укажите пул узлов, в котором развернуто дополнение. Если пул узлов не указан, дополнение будет планироваться случайным образом в соответствии с политикой планирования кластера по умолчанию. Настроить аффинитет: Введите метки узлов, на которых следует развернуть дополнение, для более гибкой политики планирования. Если метки узлов не указаны, дополнение будет планироваться случайным образом в соответствии с политикой планирования кластера по умолчанию. Если настроено несколько пользовательских политик привязки, убедитесь, что есть узлы, удовлетворяющие всем политикам привязки в кластере. В противном случае дополнение не может работать.
   Toleration	Использование как taints, так и tolerations позволяет (не принудительно) планировать Deployment дополнения на узел с соответствующими taints и управлять политиками вытеснения Deployment после того, как узел, где расположен Deployment, будет помечен taint. Дополнение добавляет политику tolerance по умолчанию для node.kubernetes.io/not-ready и node.kubernetes.io/unreachable taints соответственно. Период времени tolerance составляет 60s. Для получения подробностей см. Configuring Tolerance Policies.

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

Components