Container Calculator v1.0

Калькулятор контейнеров

Рассчитайте ресурсы Docker-контейнеров, оптимизируйте образы, спланируйте Docker Compose, оцените реестр, сравните оркестраторы и посчитайте стоимость.

Калькулятор контейнеров (Docker)

Ресурсы, образы, Compose, реестр, оркестрация и стоимость контейнеризации

Ресурсы контейнера (CPU / Memory)

CPU Request (m)

CPU Limit (m)

Memory Request (Mi)

Memory Limit (Mi)

Реплики

CPU хоста (m)

RAM хоста (Mi)

CPU Request / Limit

25.0%

Гарантированная доля CPU

Mem Request / Limit

50.0%

Гарантированная доля памяти

Риск OOM Kill

Средний

256Mi / 512Mi

QoS класс

Burstable

Kubernetes QoS

Суммарный CPU Request

750m

3 реплик(и)

Суммарный Mem Request

768 Mi

3 реплик(и)

Макс. контейнеров на хосте

при 4000m / 8192Mi

Утилизация хоста

18.8% CPU

9.4% RAM

Загрузка калькулятора контейнеров...

Модулей расчёта

87%

Компаний используют Docker

Плотность vs VM

K8s

Оркестрация

Зачем считать ресурсы контейнеров?

Неправильно настроенные requests и limits — причина OOM Kill, throttling и перерасхода ресурсов. Правильный сайзинг контейнеров экономит до 40% облачного бюджета и повышает стабильность приложений.

Docker и контейнеризация

Docker — стандарт де-факто для упаковки и запуска приложений. Контейнеры изолируют процесс, его зависимости и конфигурацию в воспроизводимую единицу развёртывания. Это ускоряет CI/CD, упрощает масштабирование и снижает стоимость инфраструктуры.

docker run -d --cpus="0.5" --memory="256m" app:latest

Requests, Limits и QoS

Kubernetes использует requests для планирования Pod-ов на ноды, а limits — для принудительного ограничения. Если memory request слишком мал относительно limit, контейнер рискует получить OOM Kill при нехватке памяти на ноде. CPU throttling замедляет приложение, но не убивает его.

resources: requests: cpu: 250m, memory: 256Mi

Контейнеризация в России

Контейнерные технологии активно внедряются в российских компаниях. По данным исследований, более 60% крупных IT-компаний в России уже используют Docker в production.Kubernetes — основной оркестратор, его используют банки, телеком, e-commerce и госструктуры.

Российские облачные провайдеры предоставляют managed Kubernetes: Yandex Managed K8s, VK Cloud Kubernetes, Selectel MKS. Для хранения образов используют локальные реестры (Harbor, Nexus) или облачные решения (Yandex Container Registry, VK Cloud Registry).

DOC

Docker

Контейнерная платформа. Стандарт OCI для образов и рантайма.

K8s

Kubernetes

Оркестратор контейнеров от Google. Автоскейлинг, self-healing, rolling updates.

Docker Compose

Локальная оркестрация. Идеален для разработки и небольших проектов.

HBR

Harbor

Приватный container registry с RBAC, сканированием уязвимостей и репликацией.

Возможности калькулятора

CPU

Ресурсы контейнера

Расчёт CPU requests/limits, memory, QoS класс (Guaranteed/Burstable/BestEffort), риск OOM Kill и утилизация хоста.

IMG

Оптимизация образов

Multi-stage build, Alpine base, анализ слоёв, cache hit rate и время pull. Сокращение размера образа до 90%.

Docker Compose

Планирование сервисов, volumes, networks. Минимальные требования к хосту и оценка сложности.

REG

Container Registry

Оценка хранилища, пропускная способность, retention policy, дедупликация слоёв. Harbor, Nexus, GitLab.

K8s

Оркестрация

Сравнение Kubernetes, Docker Swarm и Nomad. Overhead, HA, master-ноды, оптимальное количество worker-нод.

₽

Стоимость

Контейнеры vs VM: плотность размещения, утилизация ресурсов, месячные и годовые расходы на инфраструктуру.

Часто задаваемые вопросы

Docker — это платформа контейнеризации, которая позволяет упаковать приложение вместе со всеми зависимостями в изолированный контейнер. Контейнеры легче виртуальных машин (используют ядро хост-ОС), быстрее запускаются (секунды вместо минут) и обеспечивают воспроизводимость: «работает на моей машине» больше не проблема. Docker используют 87% компаний, практикующих DevOps.

Requests — это гарантированный минимум ресурсов, который Pod получит на ноде. Kubernetes использует requests для планирования (scheduling). Limits — это максимум, который Pod может использовать. Если Pod превышает CPU limit, он получает throttling (замедление). Если превышает memory limit — OOM Kill. Оптимальное соотношение: requests = 50–80% от limits для Burstable QoS.

Основные методы: 1) Используйте Alpine или distroless базовые образы (5–15 МБ вместо 800+ МБ Ubuntu). 2) Multi-stage build — собирайте в одном контейнере, копируйте артефакт в минимальный runtime-образ. 3) Минимизируйте слои: объединяйте RUN-команды через &&. 4) Используйте .dockerignore для исключения ненужных файлов. 5) Кэшируйте зависимости в отдельных слоях. Это может сократить размер образа с 1 ГБ до 50–100 МБ.

Docker Compose подходит для локальной разработки, тестирования и небольших production-окружений (до 10 сервисов на одном хосте). Kubernetes нужен, когда: более 10 сервисов, требуется автоскейлинг, нужна высокая доступность (HA), необходимо распределение по нескольким нодам, есть требования к self-healing и rolling updates. Промежуточный вариант — Docker Swarm для кластеров средней сложности.

Для self-hosted решений: Harbor — CNCF-проект с RBAC, сканированием уязвимостей (Trivy), репликацией и подписью образов; Nexus — универсальный менеджер артефактов (Docker, Maven, npm); GitLab Registry — интегрирован в GitLab CI/CD. Облачные варианты: Yandex Container Registry, VK Cloud Container Registry. Для соответствия 152-ФЗ рекомендуется self-hosted Harbor в российском дата-центре.

В Yandex Cloud managed Kubernetes кластер (3 worker-ноды по 4 vCPU / 16 GB RAM) обойдётся примерно в 25–35 тыс. рублей в месяц. Container Registry: ~1.5 ₽/GB хранения. Контейнерная инфраструктура обычно на 30–50% дешевле аналогичной на VM за счёт более высокой плотности размещения (утилизация 60–70% vs 10–15% у VM).

OOM Kill (Out of Memory Kill) — это принудительное завершение процесса ядром Linux при нехватке памяти. В Kubernetes контейнер получает OOM Kill, когда его потребление памяти превышает memory limit. Чтобы избежать: 1) Устанавливайте memory request близко к limit (70–90%). 2) Профилируйте реальное потребление памяти. 3) Учитывайте утечки памяти в долгоживущих сервисах. 4) Используйте QoS класс Guaranteed (request = limit) для критичных сервисов.

Docker-образы состоят из слоёв (layers). Если несколько образов используют один и тот же базовый образ (например, python:3.11-slim), общие слои хранятся в registry только один раз. При 20 образах на одном базовом образе дедупликация может сэкономить 30–60% хранилища. Эффективность зависит от стандартизации базовых образов в команде. Рекомендуется использовать единый набор базовых образов для всех сервисов.

Полезные ресурсы

DOC

Документация Docker

Официальная документация Docker: Dockerfile, Compose, networking, volumes и best practices.

K8s

Kubernetes.io

Руководство по Kubernetes: Pod-ы, Deployment, Service, Ingress, requests/limits и QoS.

HBR

Harbor Registry

Приватный container registry от CNCF. Установка, RBAC, сканирование Trivy и репликация.

Создатель

Лиана Арифметова

Миссия: Демократизировать сложные расчеты. Превратить страх перед числами в ясность и контроль. Девиз: «Любая повторяющаяся задача заслуживает своего калькулятора».

⚖️

Отказ от ответственности

Только для информационных целей. Все расчёты, результаты и данные, предоставляемые данным инструментом, носят исключительно ознакомительный и справочный характер. Они не являются профессиональной консультацией — медицинской, юридической, финансовой, инженерной или иной.

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

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

Ограничение ответственности. Авторы и разработчики сервиса не несут никакой ответственности за прямой или косвенный ущерб, возникший в результате использования данных расчётов. Пользователь принимает на себя всю ответственность за интерпретацию и применение полученных результатов.

Калькулятор контейнеров