Оценка ресурсов для рабочей нагрузки кластера
Содержание
Рекомендуемые практики для контрольной плоскости
В этой теме приведены рекомендуемые практики по производительности и масштабируемости для контрольных плоскостей в .
Все приведённые ниже требования основаны на минимальной установке , которая представляет собой установку основных пакетов.
На практике фактические требования могут быть выше, пожалуйста, обратитесь к инструкциям по расширениям для получения подробных дополнительных требований к ресурсам.\
Размеры узлов контрольной плоскости
Размеры контрольной плоскости зависят от количества узлов в кластере, типов узлов, а также количества и типа запущенных объектов. Рекомендации ниже основаны на тестах плотности кластера (Cluster-density), которые оценивают поведение контрольной плоскости под нагрузкой. В этих тестах развертываются следующие объекты в указанном наборе пространств имён:
- 6 deployments, в которых поды запускают только процесс sleep
- 6 services
- 6 ingresses, указывающих на предыдущие сервисы
- 12 secrets, содержащих 2048 случайных символов
- 12 config maps, содержащих 2048 случайных символов
| Количество рабочих узлов | Плотность кластера (пространства имён) | CPU ядра | Память (ГБ) |
|---|---|---|---|
| 24 | 500 | 4 | 16 |
| 120 | 1000 | 8 | 32 |
| 254 | 4000 | 24 | 128 |
Данные из таблицы основаны на среде , установленной на AWS, с использованием экземпляров r5.4xlarge (16 vCPU, 128 ГБ RAM) в качестве узлов контрольной плоскости и экземпляров m5.2xlarge (8 vCPU, 32 ГБ RAM) в качестве рабочих узлов.
В больших, плотных кластерах с тремя узлами контрольной плоскости, при отключении одного узла — будь то из-за неожиданных проблем, таких как сбои питания или сети, проблем с инфраструктурой, или намеренного выключения для экономии — оставшиеся два узла вынуждены обрабатывать дополнительную нагрузку. В таких случаях использование CPU и памяти на выживших узлах контрольной плоскости может значительно возрасти.
Такую же ситуацию можно наблюдать во время обновлений, поскольку узлы контрольной плоскости обычно поочерёдно изолируются, опорожняются и перезагружаются, пока обновляются операторы контрольной плоскости. Такая последовательная поддержка концентрирует нагрузку на оставшихся активных узлах.
Чтобы снизить риск каскадных сбоев, планируйте достаточный запас ресурсов на серверах контрольной плоскости: целевой уровень использования CPU и памяти должен быть около 60% или ниже, чтобы кластер мог выдерживать временные всплески нагрузки. При необходимости увеличьте CPU и RAM контрольной плоскости, чтобы предотвратить возможные сбои из-за исчерпания ресурсов.
Размеры узлов варьируются в зависимости от количества узлов и количества объектов в кластере. Также это зависит от того, создаются ли объекты активно в кластере. Во время создания объектов контрольная плоскость более активно использует ресурсы по сравнению с состоянием объектов в фазе Running.
Максимальные значения кластера, протестированные для основных релизов
Перераспределение физических ресурсов узла может ослабить гарантии планирования, на которые опирается Kubernetes. Применяйте контроль, такой как запросы и лимиты ресурсов, классы QoS и настройку узлов, чтобы минимизировать свопинг памяти и другие конфликты ресурсов.
Цифры в этом документе получены на основе конкретной конфигурации, методологии и настройки Alauda. Вместо фиксированных ограничений следующие данные показывают максимальные значения, наблюдаемые для в тестируемых условиях.
Поскольку комбинации версии , нагрузки контрольной плоскости и сетевого плагина не ограничены, эти значения не являются гарантированными пределами для всех развертываний и могут быть недостижимы одновременно по всем параметрам.
Используйте их в качестве ориентира при планировании развертываний с похожими характеристиками.\
При увеличении или уменьшении количества узлов в ваших кластерах рекомендуется:
- Распределять узлы по всем доступным зонам, если они есть, это способствует повышению доступности.
- Масштабировать вверх/вниз не более чем на 25–50 узлов за раз.
При масштабировании вниз больших, плотно заполненных кластеров операция может занять значительное время, так как рабочие нагрузки на узлах, которые планируется удалить, должны быть перемещены или завершены до выключения этих узлов. Это особенно длительно, если необходимо обработать большое количество ресурсов одновременно.
Если требуется эвакуация большого числа объектов, клиент API может начать ограничивать частоту запросов. Значения по умолчанию для QPS и burst клиента — 50 и 100 соответственно, и эти значения нельзя изменить в .\
| Тип максимума | протестированный максимум |
|---|---|
| Количество узлов | 500 [1] |
| Количество подов [2] | 100,000 |
| Количество подов на узел | 250 |
| Количество пространств имён [3] | 10,000 |
| Количество подов на пространство имён [4] | 25,000 |
| Количество secrets | 40,000 |
| Количество config maps | 40,000 |
| Количество сервисов | 10,000 |
| Количество сервисов на пространство имён | 5,000 |
| Количество back-ends на сервис | 5,000 |
| Количество deployments на пространство имён [4] | 2,000 |
| Количество custom resource definitions (CRD) | 1,024 [5] |
- поддерживает кластеры с более чем 500 узлами, указанное число — рекомендуемый максимум. Если ваши сценарии требуют больших кластеров, пожалуйста, свяжитесь с нашей технической поддержкой.
- Количество подов указано по результатам тестовой среды. Фактическая ёмкость подов будет варьироваться в зависимости от требований приложений к памяти, CPU и хранилищу.
- При большом количестве активных проектов производительность etcd может ухудшаться, если пространство ключей становится слишком большим и превышает квоту. Рекомендуется регулярное обслуживание etcd, например дефрагментация, для освобождения места и предотвращения проблем с производительностью.
- Несколько управляющих циклов проходят по всем объектам в пространстве имён в ответ на изменения состояния. Очень большое количество объектов одного типа в одном пространстве имён делает эти циклы дорогими и может замедлять обработку. Указанный предел предполагает, что система имеет достаточные CPU, память и диск для удовлетворения потребностей приложений.
- Тест проводился на кластере из 29 серверов (3 узла контрольной плоскости, 2 инфраструктурных узла и 24 рабочих узла) с 500 пространствами имён. ограничивает общее количество custom resource definitions (CRD) до 1,024, включая CRD, предоставленные , CRD, добавленные интегрированными продуктами, и CRD, созданные пользователями. Создание более 1,024 CRD может привести к ограничению запросов kubectl.
Примеры
В качестве примера были протестированы и поддерживаются 500 рабочих узлов (размер m5.2xlarge, 8 vCPU и 32 ГБ памяти) с использованием 4.1, сетевого плагина Kube-OVN и следующих объектов нагрузки:
- 200 пространств имён, помимо стандартных
- 60 подов на узел; 30 серверных и 30 клиентских подов (всего 30k)
- 15 сервисов на пространство имён, поддерживаемых серверными подами (всего 3k)
- 20 secrets на пространство имён (всего 4k)
- 10 config maps на пространство имён (всего 2k)
- 6 сетевых политик на пространство имён, включая deny-all, allow-from ingress и правила внутри пространства имён
Следующие факторы известны как влияющие на масштабирование нагрузки кластера, положительно или отрицательно, и должны учитываться при планировании развертывания. Для дополнительной информации и рекомендаций обращайтесь в нашу техническую поддержку.
- Количество подов на узел
- Количество контейнеров в поде
- Тип используемых проверок (например, liveness/readiness, exec/http)
- Количество сетевых политик
- Количество проектов или пространств имён
- Количество сервисов/эндпоинтов и их тип
- Количество шардов
- Количество secrets
- Количество config maps
- Частота API вызовов, что является оценкой скорости изменений конфигурации кластера.
- Запрос Prometheus для создания подов в секунду за 5-минутные окна:
sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m])) - Запрос Prometheus для всех API запросов в секунду за 5-минутные окна:
sum(irate(apiserver_request_count{}[5m]))
- Запрос Prometheus для создания подов в секунду за 5-минутные окна:
- Потребление ресурсов CPU узлами кластера
- Потребление ресурсов памяти узлами кластера