Без правильного расчёта железа Docker-нода уходит в OOM или упирается в IOPS под нагрузкой. Вопрос: какое железо взять, чтобы прод выдержал пиковую нагрузку, а админ не воевал с OOM-killer по ночам. Разберём, как платформа нагружает CPU, RAM, диски и сеть, и какие конфигурации подойдут под dev-стенд, продакшен на 30 контейнеров и узел Kubernetes-кластера. С реальными цифрами по overhead, IOPS под СУБД-контейнеры и типовым лимитам cgroups v2.
Что Docker делает с ресурсами хоста
Чтобы правильно посчитать железо, надо сначала понять, как именно работают контейнеры на уровне ядра ОС.
Это процессы Linux с изоляцией через namespaces и cgroups
Это не виртуальная машина с собственным ядром, а обычный процесс хостовой Linux-системы, помещенный в две клетки. Когда контейнеров много, появляется задача оркестрации — кто-то должен запускать, перезапускать и балансировать их между серверами (этим занимаются docker-compose для одиночных хостов, Docker Swarm для пары узлов и Kubernetes для серьезных кластеров). Первая клетка — namespaces, которые изолируют ему файловую систему, сеть, PID и пользователей. Вторая — cgroups, которые ограничивают потребление CPU, RAM, диска и сети. Если использовать аналогию: инстансы — как студенческие комнаты в общежитии, где общая кухня (ядро ОС) одна на всех, но у каждой комнаты свой замок (namespace) и индивидуальный счетчик электричества (cgroup).
Чем нагрузка контейнерного движка отличается от классических ВМ
Главная разница — в overhead. Виртуальная машина под гипервизором тащит за собой полное гостевое ядро, эмуляцию железа и драйверы — это легко 5–10% CPU и сотни мегабайт RAM на каждый инстанс. Контейнерный движок этого избегает: контейнер использует ядро хоста напрямую, без виртуализации. Типовой оверхед составляет 1–3% CPU и 0–2% RAM по сравнению с нативным процессом. То есть из 32 ядер и 128 ГБ RAM сервера почти все идет в полезную работу.
Когда нативный сервер выгоднее виртуализации
Если задача — поднять плотный контейнерный стек, разворачивать контейнерный движок поверх VMware или KVM смысла мало: вы платите overhead дважды. Bare-metal движок на физическом хосте хосте дает больше плотности (контейнеров на ядро) и стабильнее по latency. Виртуализация остается оправданной, когда на одном сервере живут разные классы нагрузок (движок + legacy-приложение в Windows ВМ), или когда нужна жесткая изоляция между арендаторами.
CPU: сколько ядер закладывать на контейнеры
С процессором два главных вопроса: сколько ядер брать и какой частоты. Ответ зависит от профиля нагрузки.
Тактовая частота против числа ядер
Контейнеры с однопоточными приложениями (Node.js, Python без gunicorn-воркеров, классический PHP-FPM) упираются в частоту: чем выше boost-clock, тем лучше latency. Под такие нагрузки разумны Xeon Gold с частотой 3.0+ ГГц или EPYC Genoa F-серии. А вот сборки CI/CD, тестовые контуры и микросервисы хорошо параллелятся — здесь рулит число ядер: Xeon Silver 4-5 поколения или Xeon Gold 6/8-серии с 20–40 ядрами в сокете. Платформу под нужный профиль удобно подбирать сразу — серверзилла предлагает серверы с разной плотностью ядер и частотным запасом.
cgroups v2: квоты и лимиты на контейнер
В современном Linux (ядро 5.x+) по умолчанию работает cgroups v2 — единая иерархия с гранулярным контролем. На уровне движка квоты задаются простыми флагами: --cpus="2.5" фиксирует контейнеру 2.5 ядра, --memory="4g" — 4 ГБ RAM с жестким OOM при превышении. Без явных лимитов любое приложение может съесть всю машину при утечке памяти или CPU-loop — это самая частая причина инцидентов на dev-стендах.
Расчет на типовые сервисы: web, БД, очередь, AI-инференс
Под web-сервис (Nginx + PHP-FPM или Node.js) хватает 0.5–2 ядер и 512 МБ — 2 ГБ RAM. Инстанс с PostgreSQL или MySQL потребляет 2–8 ядер и 4–32 ГБ в зависимости от размера базы. RabbitMQ или Kafka берут 2–4 ядра и 4–8 ГБ под брокер. А AI-инференс на CPU без GPU прожорлив: модель уровня BERT-large отъедает 4–8 ядер и 8–16 ГБ. Сумму нагрузок умножайте на коэффициент 1.3–1.5 — это запас на пиковые нагрузки и регламентные операции.
RAM: сколько памяти нужно под контейнеры
После CPU память — главный лимитирующий ресурс. Здесь экономить нельзя.
Память контейнера = память приложения + накладные расходы
Внутри живут само приложение, runtime (Node.js, JVM, Python interpreter), кеши и временные структуры. Реальное потребление почти всегда выше декларированного: Java-приложение, написанное «под 2 ГБ heap», запросит у системы 3–4 ГБ. Поэтому при расчете лимита memory лучше брать с запасом 30–50%. Сумма лимитов всех контейнеров плюс 8–16 ГБ под хостовую ОС и фоновый демон дает требуемый объем RAM на сервере.
Swap и memory pressure в контейнерах
Swap в продакшен-контейнерах включать не стоит. Если инстанс свопится, latency приложения становится непредсказуемым — лучше получить честный OOM-kill и автоматический рестарт, чем медленный сервис, который никто не сможет диагностировать. Cgroups v2 умеет работать с memory pressure через PSI (Pressure Stall Information) — мониторьте этот показатель в Prometheus, он показывает реальную нехватку памяти раньше, чем срабатывает OOM.
ECC-память для продакшен-нагрузок
Для серверов под продакшен берется только ECC RAM. Приложения без ECC переживают bit-flip как полноценные ВМ — это битые байты в логах, упавшие транзакции БД, тихие сбои в кешах. На сервере с 256 ГБ обычной памяти статистически ошибка случается раз в недели, на ECC — раз в годы и автоматически корректируется.
Диски и файловая система
С дисками инфраструктура жестче, чем классическая ВМ-ферма. Любая запись внутри инстанса — это запись через storage driver, и его выбор влияет на производительность.
Overlay2 как стандартный storage driver
Начиная с Docker Engine 18.06, overlay2 — рекомендуемый storage driver для всех типовых дистрибутивов. Он использует overlay union FS и работает поверх ext4 или xfs. Производительность отличная, поддерживается из коробки, шансов сломаться при апдейте — минимум. Альтернативы (btrfs, zfs) дают плюшки вроде снапшотов и компрессии, но требуют опытного DBA для нормальной эксплуатации. Девайс-маппер и aufs устарели — их использовать не стоит.
NVMe enterprise для контейнеров с интенсивной записью
Инстанс с базой данных создает большой поток случайных операций: 30 000+ IOPS даже на средней нагрузке. SATA SSD сюда не подойдет — упрется в очередь команд и латентность 1–2 мс на хвост распределения. NVMe enterprise PCIe 4.0 с power-loss protection дает 500 000+ IOPS и latency ниже 0.1 мс. Если планируется крутить там PostgreSQL, MySQL, MongoDB или Redis с диском — берите только NVMe enterprise класса.
Volumes vs bind mounts vs tmpfs
Платформа предлагает три способа подключить данные снаружи. Volumes — managed-объекты движка, лучшая практика для продакшена, переживают пересборку и легко бэкапятся. Bind mounts напрямую монтируют папку хоста — удобно для dev-стендов, опасно в проде (инстанс видит файловую систему хоста). Tmpfs — данные в RAM, для кешей и временных файлов с быстрым доступом и без записи на диск. Под прод-сервисы выбирайте volumes, под dev — bind mounts, под кеши — tmpfs.
Отдельный том под /var/lib/docker
Образы, инстансы и слои overlay2 живут в /var/lib/docker. На активном сервере папка раздувается до 100–500 ГБ за пару месяцев. Если она лежит на корневом разделе, переполнение положит всю машину. Поэтому правило простое: при установке движка всегда выделять отдельный том под /var/lib/docker — например, NVMe-раздел на 500 ГБ — 2 ТБ с автоматической ротацией старых образов через docker system prune.
Сеть контейнерного движка: bridge, host, overlay
Сетевой стек движка — это отдельная инженерная дисциплина. От правильного выбора режима зависит и пропускная способность, и latency, и безопасность.
Bridge для одиночного хоста
Bridge-сеть — стандартный режим. Движок создает виртуальный мост docker0 и подключает к нему контейнеры через veth-пары. Это просто, работает из коробки и достаточно для одиночного хоста с десятком инстансов. Минус — лишний хоп через NAT, который добавляет 5–10 мкс latency и срезает пиковую пропускную способность.
Host-сеть для production web-сервисов
Если приложению нужен максимум сети — например, под высоконагруженный API или прокси на 100k+ RPS — используется host network. Оно получает прямой доступ к сетевому стеку хоста, без NAT и без оверхеда мостов. Минус — пропадает изоляция портов, поэтому два контейнера не запустить на одном порту. Под классический web 99% случаев bridge достаточно, host используется точечно под топовые нагрузки.
Overlay для кластера: Swarm и Kubernetes
Когда контейнеры разъезжаются по нескольким хостам, нужен overlay-сеть. В Docker Swarm это встроенный VXLAN-overlay, в Kubernetes — Calico, Cilium или Flannel поверх того же VXLAN или eBPF. Сеть прозрачна: контейнеры на разных нодах видят друг друга по IP, как в одной локалке. Цена — те же 5–15% оверхеда CPU на сетевой стек.
Сетевые карты 10/25 Gb для нагруженных нод
На ноде Kubernetes с десятками микросервисов 1 Gbps уходит за минуты пиковой нагрузки. Для продакшен-кластеров минимум — 10 Gbps на ноду, для нагруженных (например, реальная видеоаналитика или ML-инференс) — 25 или 100 Gbps. Подобрать сетевое оборудование с MLAG и LACP под такие нагрузки — отдельная задача, которую стоит решать одновременно с подбором серверов.
Конфигурация под типовые сценарии
Перейдем от теории к практике. Вот четыре типовых сценария с конкретными цифрами.
Dev/CI: 8 ядер, 32 ГБ RAM, NVMe 1 ТБ
Под dev-стенд или CI-хост с GitLab Runner и десятком контейнеров достаточно одного 8-ядерного CPU (Xeon Silver или EPYC 9004 младшей серии), 32 ГБ ECC RAM и одного NVMe на 1 ТБ. Сеть — 1 Gbps. Бюджет минимальный, эксплуатация простая.
Прод 10-30 инстансов: 16-32 ядра, 64-128 ГБ RAM
Продакшен на 10–30 микросервисов с БД, кешами и фронтом требует 16–32 физических ядра, 64–128 ГБ ECC RAM, два NVMe в зеркале (один под систему и /var/lib/docker, второй под data-volumes) и сеть 10 Gbps. Типовая платформа — двухсокетный сервер на Xeon Gold или EPYC Genoa. Под такую плотность разумно использовать подбор сервера под задачу с расчетом ECC-памяти и BMC.
Узел Kubernetes-кластера: 32-64 ядра, 128-256 ГБ RAM
Для production-узла Kubernetes на 50–100 подов берется 32–64 ядра, 128–256 ГБ ECC RAM, два-четыре NVMe и 25 Gbps на сетевую карту. Лимит по умолчанию у kubelet — 110 подов на ноду, после этого нагрузка на API-сервер растет нелинейно. Кластер из 3–5 таких нод с witness в отдельной стойке — рабочая конфигурация под средний бизнес.
AI-инференс в контейнерах: GPU NVIDIA + соответствующая шина
Для ML-инференса в контейнерах нужен NVIDIA Container Toolkit (бывший NVIDIA Docker) и драйвер NVIDIA на хосте. Сами модели запускаются в контейнере с проброшенным GPU. Под современные LLM или нейросети уровня компьютерного зрения берется GPU-сервер с двумя-четырьмя GPU и PCIe 4.0/5.0 для нормальной пропускной способности между картой и хостом.
Хранилище образов и реестры
Каждый запуск — это образ, образы где-то хранятся. От выбора реестра зависит скорость деплоя и независимость от внешних сервисов.
Локальный кеш образов: 100-500 ГБ под /var/lib/docker
Каждый pull образа кладет слои в локальный кеш Docker. Типовой проект (web + БД + кеш + brokers) — это 5–20 образов по 200 МБ — 2 ГБ. На машине с активной CI/CD кеш быстро вырастает до сотен гигабайт. Чистка через docker image prune раз в неделю — обязательный регламент.
Корпоративный registry: Harbor, Nexus, Artifactory
Для корпоративной разработки локального реестра недостаточно. Стандартные решения — Harbor (open-source, поддержка ролевой модели и сканирования уязвимостей), Sonatype Nexus Repository и JFrog Artifactory. Harbor разворачивается за день, дает приватный реестр с авторизацией и хорошо интегрируется с Kubernetes и CI/CD.
Российские реестры: rdocker, Yandex Container Registry
После ухода Docker Hub из РФ и регулярных проблем с pull-rate-limit стало нормой держать локальный или российский реестр. Из доступных — rdocker (зеркало Docker Hub для российских клиентов), Yandex Container Registry в Яндекс.Облаке и SberCloud Container Registry. У всех есть поддержка авторизации, сканирования образов и интеграция с CI/CD-системами.
Эксплуатация: мониторинг и тонкая настройка
После развертывания начинается главная работа — поддерживать кластер живым и понимать, что происходит внутри контейнеров.
Метрики cAdvisor, Prometheus, Grafana
Стандартный стек мониторинга контейнеров — cAdvisor для сбора метрик с уровня контейнера, Prometheus как time-series база и Grafana для дашбордов. cAdvisor показывает CPU, RAM, диск, сеть по каждому инстансу с гранулярностью в секунды. Prometheus хранит метрики 15–30 дней, Loki или ELK — логи. Без такого стека выявление утечек памяти или CPU-loop превращается в гадание.
Healthcheck и автоматический рестарт
У движка есть встроенный healthcheck — простая команда внутри контейнера, которая проверяет живость приложения. С политикой restart: unless-stopped упавший контейнер автоматически поднимается. В Kubernetes за это отвечают liveness и readiness пробы. Без healthcheck OOM-killed процесс может месяцами лежать в статусе exited, и никто этого не заметит.
Логирование: json-file, journald, syslog, отдельный лог-агрегатор
По умолчанию движок пишет логи в json-file внутри /var/lib/docker/containers/{id}/. На активном проде эти файлы быстро растают до десятков гигабайт. Решений два: либо настроить ротацию (max-size, max-file в daemon.json), либо переключить драйвер на journald или syslog и отправлять логи в централизованный агрегатор — ELK, Loki, Vector. Второй вариант обязателен для продакшена.
Типовые ошибки при подборе сервера под контейнеры
Опыт показывает: одни и те же ошибки повторяются у большинства команд при первом развертывании.
Игнорирование IOPS: HDD под контейнеры с СУБД
Самая частая ошибка — запустить инстанс PostgreSQL на HDD или SATA SSD «потому что и так сойдет». Через неделю latency запросов вырастает в 10–20 раз, приложение начинает тормозить, и команда долго ищет причину в коде. NVMe enterprise — обязательное условие для любой СУБД в контейнере.
Недооценка RAM: OOM-killer и перезапуски
Вторая частая ошибка — рассчитать память «впритык» по сумме лимитов, без запаса на хостовую ОС и пиковую нагрузку. Через несколько дней OOM-killer начинает прибивать самый прожорливый контейнер. Правило: к сумме лимитов памяти добавляем 30% запаса и 8–16 ГБ под хост.
Слабая сеть на ноде Kubernetes
Третья ошибка — поставить ноду Kubernetes на 1 Gbps. Между подами с микросервисами идут постоянные RPC-вызовы, и канал быстро становится узким горлышком. Под продакшен-кластер всегда минимум 10 Gbps, под нагруженные сценарии (AI-инференс, видеоаналитика, real-time) — 25 Gbps и выше.
Подбираете сервер под контейнерную платформу, Docker Swarm или Kubernetes? Наши инженеры рассчитают CPU, RAM, NVMe и сетевую обвязку под ваше число контейнеров и тип нагрузок, подберут платформу с ECC-памятью и BMC. Закажите аудит ИТ-инфраструктуры — на выходе получите готовую спецификацию железа и регламент эксплуатации.
Сравнительная таблица сценариев
Часто задаваемые вопросы (FAQ)
Сколько инстансов тянет машина с 32 ядрами и 128 ГБ RAM?
Зависит от типа нагрузки. Под легкие микросервисы (Node.js, Go) — 80–150 инстансов с лимитами по 0.5 ядра и 1 ГБ. Под смесь web и БД — 30–50 штук с лимитами 1–4 ядра и 4–16 ГБ. Под тяжелые СУБД и брокеры — 10–15 штук с лимитами 4–8 ядер и 16–32 ГБ. Считается всегда от суммы лимитов плюс 30% запаса.
Нужен ли отдельный диск под /var/lib/docker?
Да, обязательно. Иначе при разрастании кеша образов и слоев overlay2 переполняется корневой раздел и сервер падает. Под /var/lib/docker выделяется отдельный том NVMe на 500 ГБ — 2 ТБ. Чистка через docker system prune раз в неделю — обязательный регламент.
Подойдут ли SATA SSD под Docker в проде?
Для контейнеров без БД и без интенсивной записи — да, SATA SSD enterprise класса справляется. Под контейнеры с PostgreSQL, MySQL, MongoDB, ClickHouse — только NVMe enterprise. Разница в latency и IOPS критична: SATA SSD дает 50–80k IOPS на random write, NVMe — 500k+.
Чем bridge-сеть отличается от overlay в кластере?
Bridge — это локальный сетевой мост в пределах одного хоста: контейнеры на разных серверах через bridge не видят друг друга. Overlay — это виртуальная сеть поверх физической, которая объединяет контейнеры с разных хостов в общую L2-сеть через VXLAN. Bridge — для одиночного сервера, overlay — для Swarm и Kubernetes.
Какие лимиты на CPU и RAM ставить контейнерам?
Лимит CPU ставится через --cpus или Kubernetes resources.limits.cpu и должен превышать средний расход в 1.5–2 раза. Memory-лимит ставится по пиковому потреблению с запасом 30%. Без явных лимитов утечка памяти в одном контейнере положит весь сервер.
Можно ли поднять контейнерную платформу на сервере с консьюмерским CPU?
Технически — да, но в проде не стоит. Консьюмерские CPU (Core i9, Ryzen 9) не поддерживают ECC и большой объем RAM, имеют меньше PCIe-линий и не рассчитаны на 24/7 нагрузку с термоудержанием 80%+. Под продакшен берется серверный Xeon или EPYC.
Нужен ли GPU в контейнерах для ML-инференса?
Если модель тяжелее, чем classic ML (логистическая регрессия, простой градиентный бустинг) — да. CNN, трансформеры, LLM на CPU работают в десятки и сотни раз медленнее, чем на GPU. NVIDIA Container Toolkit пробрасывает GPU в контейнер с минимальным оверхедом.
Что выбрать: bare-metal движок или контейнеры в ВМ?
Под однотипный контейнерный стек — bare-metal: меньше overhead, выше плотность, проще эксплуатация. Под смешанные нагрузки (Docker + legacy Windows-приложение, разные арендаторы) — Docker в ВМ под Proxmox или KVM. На продакшен-Kubernetes-кластере большинство команд выбирает bare-metal.
Итоги
Расчет железа под контейнеры сводится к простой формуле: считаем сумму лимитов CPU и RAM по всем контейнерам, прибавляем 30% запаса, выбираем NVMe enterprise под любую запись с БД, кладем отдельный том под /var/lib/docker, берем минимум 10 Gbps на сетевую карту в продакшене. Хостовая ОС и Docker daemon съедают 1–3% CPU и 8–16 ГБ RAM сверху. ECC-память — обязательное условие для прода. Под Kubernetes планируется кластер из 3–5 узлов с управляющей плоскостью и witne
