При планировании размещения и запуска на одном узле более 100 подов к его конфигурации предъявляются дополнительные требования. Наиболее критичные требования затрагивают диск (распаковка и монтирование слоёв образа), ядро и оперативную память узла. Соблюдение приведённых в этом руководстве рекомендаций поможет сократить время запуска подов и сделать его более предсказуемым.

Для узлов с высокой плотностью размещения подов:

  • заранее спланируйте размер подсети узла (параметр podSubnetNodeCIDRPrefix) — лимит подов на узел подстроится автоматически;
  • используйте ядро Linux версии 6.12 или новее;
  • используйте быстрый локальный диск (NVMe или SSD) и не используйте сетевую файловую систему;
  • используйте лёгкие образы приложений с минимальным количеством слоёв (например, distroless).

Компоненты control plane для подобных сценариев Deckhouse Kubernetes Platform (DKP) настраивает автоматически — дополнительная ручная настройка не требуется.

Лимит подов на узел

Лимит подов на узел в DKP вычисляется на основе размера подсети узла, задаваемого параметром podSubnetNodeCIDRPrefix. Чтобы узел вмещал до 1000 подов, при развёртывании кластера задайте значение ≤ 21.

Размер подсети, выделяемой узлу, определяет максимальное количество подов, которые могут быть на нём размещены:

Значение podSubnetNodeCIDRPrefix Количество подов на узел (по умолчанию)
≥ 24 120
23 250
22 500
≤ 21 1000

Параметр podSubnetNodeCIDRPrefix задаётся при развёртывании кластера. Если вам заранее известно, что на узлах потребуется размещать большое количество подов, рекомендуется выбрать подходящее значение на этапе создания кластера.

Ядро узла

Для узлов с высоким количеством подов рекомендуется использовать ядро Linux версии 6.12 или новее с поддержкой модуля erofs.

Начиная с версии 2.x, containerd поддерживает использование функциональности EROFS, зависящей от опции ядра CONFIG_EROFS_FS_BACKED_BY_FILE. Эта опция включена по умолчанию в Linux, начиная с версии 6.12, и позволяет напрямую монтировать слои образов, представленные обычными файлами, без создания отдельного loop-устройства для каждого слоя или контейнера.

При отсутствии этой опции запуск большого количества контейнеров может приводить к созданию большого числа loop-устройств. На узлах с сотнями или тысячами подов это увеличивает нагрузку на систему и может существенно замедлять запуск контейнеров.

Поэтому для узлов, на которых планируется размещать большое количество подов, рекомендуется использовать операционную систему с ядром Linux версии 6.12 или новее.

Диск узла

Используйте быстрый локальный диск (NVMe или SSD). Не размещайте файлы контейнерной среды и kubelet на сетевой файловой системе.

При запуске каждого пода выполняются дискозависимые операции распаковки и работы со слоями образа. При массовом запуске эти операции умножаются на количество подов, поэтому производительность диска напрямую влияет на время старта.

Рекомендации:

  • Используйте быстрые диски с производительностью не менее 400 IOPS (подробнее — в разделе «Требования к ресурсам»). Для узлов с высокой плотностью размещения подов предпочтительны локальные NVMe-диски.
  • Не размещайте каталоги контейнерной среды и kubelet на сетевой или распределённой файловой системе. Сетевые задержки при операциях монтирования умножаются на количество запускаемых подов и делают время старта непредсказуемым.

Образы приложений

Чем компактнее и проще образ приложения, тем быстрее запускается под. Используйте минимальные образы (например, distroless) и сокращайте количество слоёв.

Размер и структура образа влияют на время его загрузки и подготовки к запуску. При большом количестве одновременно запускаемых подов это может привести к проблемам.

Рекомендации:

  • используйте минимальные базовые образы (например, distroless, *-slim или alpine), без лишних пакетов и инструментов;
  • сокращайте количество слоёв образа и при возможности объединяйте их, чтобы уменьшить объём распаковки и монтирования;
  • поддерживайте компактность образов — удаляйте кеши пакетных менеджеров, артефакты сборки и временные файлы;
  • используйте многоэтапную сборку, чтобы уменьшить размер и количество слоёв финального образа.

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

Рекомендации:

  • размещайте хранилище образов контейнеров в сетевой близости к кластеру и обеспечьте достаточную пропускную способность канала до него;
  • для образов из внешних (в том числе публичных) хранилищ образов используйте локальное зеркало или кеш с автоматической подгрузкой рядом с кластером.

Ресурсы узла

Помимо диска и ядра, плотность размещения подов ограничена процессором и объёмом оперативной памяти на узле. Ниже приведены результаты тестирования с использованием статического NGINX:

  • узел с 4 vCPU, 8 ГБ оперативной памяти и SSD обеспечивает одновременный запуск 150 подов;
  • узел с 32 vCPU, 64 ГБ оперативной памяти, локальным NVMe и версией ядра Linux ≥ 6.12 запускает порядка 1000 подов за несколько минут.

Фактические значения зависят от характеристик приложений, поэтому перед использованием подобных конфигураций в production-окружении рекомендуется провести нагрузочное тестирование.