Alauda Container Platform
  • Русский

    • Оценка ресурсов для рабочей нагрузки кластера

    Содержание

    Рекомендуемые практики для Control Plane

    В этой теме приведены рекомендуемые практики по производительности и масштабируемости для control plane в .

    INFO

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

    Размеры узлов Control Plane

    Требования к размеру control plane зависят от количества узлов в кластере, типов узлов, а также от количества и типа запущенных объектов. Рекомендации ниже основаны на тестах Cluster-density, которые оценивают поведение control plane под нагрузкой. В этих тестах развертываются следующие объекты в заданном наборе namespaces:

    • 6 deployments, поды которых запускают только процесс sleep
    • 6 services
    • 6 ingresses, указывающих на перечисленные сервисы
    • 12 secrets, содержащих 2048 случайных символов
    • 12 config maps, содержащих 2048 случайных символов
    Количество рабочих узловCluster-density (namespaces)CPU ядраПамять (ГБ)
    24500416
    1201000832
    254400024128

    Данные из таблицы основаны на среде , установленной на AWS, с использованием инстансов r5.4xlarge (16 vCPU, 128 ГБ RAM) в качестве узлов control plane и m5.2xlarge (8 vCPU, 32 ГБ RAM) в качестве рабочих узлов.

    В больших, плотных кластерах с тремя узлами control plane отключение одного узла — будь то из-за непредвиденных проблем, таких как сбои питания или сети, инфраструктурных проблем или намеренного выключения для экономии — заставляет оставшиеся два узла обрабатывать дополнительную нагрузку. В таких случаях использование CPU и памяти на оставшихся узлах control plane может значительно возрасти.
    Такую же ситуацию можно наблюдать во время обновлений, поскольку узлы control plane обычно поочерёдно cordon, drain и перезагружаются, пока обновляются операторы control plane. Такая последовательная поддержка концентрирует нагрузку на активных узлах.
    Чтобы снизить риск каскадных сбоев, планируйте достаточный запас ресурсов на серверах control plane: целевой уровень использования CPU и памяти — около 60% или меньше, чтобы кластер мог справляться с временными пиковыми нагрузками. При необходимости увеличьте CPU и RAM control plane, чтобы предотвратить возможные простои из-за исчерпания ресурсов.

    ВАЖНЫЕ ЗАМЕЧАНИЯ

    Размеры узлов варьируются в зависимости от количества узлов и числа объектов в кластере. Также это зависит от того, активно ли создаются объекты в кластере. Во время создания объектов control plane более активно использует ресурсы по сравнению с состоянием, когда объекты находятся в фазе Running.

    Максимальные протестированные значения для основных релизов

    WARNING

    Перераспределение физических ресурсов узла может ослабить гарантии планирования, на которых основан Kubernetes. Применяйте контроль, такой как requests и limits ресурсов, QoS классы и настройку узлов, чтобы минимизировать свопинг памяти и другие конфликты ресурсов.

    Цифры в этом документе основаны на конкретной конфигурации, методологии и настройках Alauda. Вместо фиксированных ограничений ниже приведены максимальные значения, наблюдаемые для в тестируемых условиях.
    Поскольку комбинации версии , нагрузки control plane и сетевого плагина не ограничены, эти значения не гарантируют пределов для всех развертываний и могут быть недостижимы одновременно по всем параметрам.
    Используйте их как ориентир при планировании развертываний с похожими характеристиками.\

    INFO

    При увеличении или уменьшении количества узлов в кластерах рекомендуется:

    • Распределять узлы по всем доступным зонам, если это возможно, что повышает доступность.
    • Масштабировать вверх/вниз не более чем на 25–50 узлов за раз.

    При масштабировании вниз больших, плотно заполненных кластеров операция может занять значительное время, так как рабочие нагрузки на узлах, которые планируется удалить, должны быть перемещены или завершены до выключения этих узлов. Это особенно длительно, если необходимо обработать большое количество ресурсов одновременно.
    Если требуется эвакуация большого числа объектов, клиент API может начать ограничивать количество запросов. Значения по умолчанию для QPS и burst клиента — 50 и 100 соответственно, и эти параметры нельзя изменить в .\

    Тип максимумапротестированный максимум
    Количество узлов500 [1]
    Количество подов [2]100,000
    Количество подов на узел250
    Количество namespaces [3]10,000
    Количество подов на namespace [4]25,000
    Количество secrets40,000
    Количество config maps40,000
    Количество сервисов10,000
    Количество сервисов на namespace5,000
    Количество back-ends на сервис5,000
    Количество deployments на namespace [4]2,000
    Количество custom resource definitions (CRD)1,024 [5]
    1. поддерживает кластеры с более чем 500 узлами, указанное число — рекомендуемый максимум. Если ваши сценарии требуют больших кластеров, пожалуйста, свяжитесь с нашей технической поддержкой.
    2. Число подов указано по результатам тестовой среды. Фактическая ёмкость подов будет варьироваться в зависимости от требований приложений к памяти, CPU и хранилищу.
    3. При большом количестве активных проектов производительность etcd может ухудшаться, если пространство ключей становится слишком большим и превышает квоту. Рекомендуется регулярное обслуживание etcd, например дефрагментация, для освобождения места и предотвращения проблем с производительностью.
    4. Несколько управляющих циклов проходят по всем объектам в namespace при изменениях состояния. Очень большое количество объектов одного типа в одном namespace делает эти циклы дорогими и может замедлять обработку. Указанный лимит предполагает, что система имеет достаточные CPU, память и диск для удовлетворения потребностей приложений.
    5. Тест проводился на кластере из 29 серверов (3 узла control plane, 2 инфраструктурных узла и 24 рабочих узла) с 500 namespaces. ограничивает общее количество custom resource definitions (CRD) до 1,024, включая CRD, предоставленные , CRD интегрированных продуктов и созданные пользователями. Создание более 1,024 CRD может привести к ограничению запросов kubectl.

    Примеры

    В качестве примера были протестированы и поддерживаются 500 рабочих узлов (размер m5.2xlarge, 8 vCPU и 32 ГБ памяти) с использованием 4.1, сетевого плагина Kube-OVN и следующих объектов нагрузки:

    • 200 namespaces, помимо стандартных
    • 60 подов на узел; 30 серверных и 30 клиентских подов (всего 30k)
    • 15 сервисов на namespace, поддерживаемых серверными подами (всего 3k)
    • 20 secrets на namespace (всего 4k)
    • 10 config maps на namespace (всего 2k)
    • 6 сетевых политик на namespace, включая deny-all, allow-from ingress и правила внутри namespace

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

    • Количество подов на узел
    • Количество контейнеров в поде
    • Тип используемых проверок (например, liveness/readiness, exec/http)
    • Количество сетевых политик
    • Количество проектов или namespaces
    • Количество сервисов/эндпоинтов и их тип
    • Количество шардов
    • Количество 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]))
    • Потребление CPU ресурсами узлов кластера
    • Потребление памяти ресурсами узлов кластера