Alauda Container Platform
  • Русский

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

    Содержание

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

    Рекомендуемые практики для контрольной плоскости

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

    INFO

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

    Размеры узлов контрольной плоскости

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

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

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

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

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

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

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

    WARNING

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

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

    INFO

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

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

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

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