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 управляет auto scale-out и scale-in.

• Auto scale-out

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

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

    Auto scale-out будет выполнено, когда:

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

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

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

• Auto scale-in

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

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

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

• Во время установки дополнения в кластере должно быть достаточно ресурсов.
• Это дополнение поддерживает VM nodes и не поддерживает PM nodes.
• Пул узлов по умолчанию не поддерживает авто масштабирование. Подробнее см. 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'ы или аннотации могут влиять на авто масштабирование. Поэтому не используйте в кластерах следующие taint'ы или аннотации:
  • ignore-taint.cluster-autoscaler.kubernetes.io: Taint применяется к узлам. Автоскейлер, нативный для 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'ов и квоты ресурсов для дополнения на основе выбранных preset specifications. Вы можете просмотреть конфигурации в консоли.

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

   • Memory request = Number of pods × Size of the pod YAML files (KB)/10000 × 0.28 GiB + 1 GiB
   • Memory limit =Memory request + 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 Рекомендуемый размер памяти дополнения в сценариях крупномасштабных развертываний

   Количество 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 pod‑ов.
   Note

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

   Таблица 2 Конфигурации планирования add‑on

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

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