Docker и Kubernetes: в чём разница и что выбрать

Сразу снимем главное заблуждение. Docker и Kubernetes решают разные задачи и работают на разных уровнях, поэтому выбор «или-или» между ними некорректен. Docker упаковывает приложение в контейнер — это контейнеризация. Kubernetes управляет множеством контейнеров на кластере серверов — это оркестрация. Первый отвечает на вопрос «как собрать и запустить один контейнер», второй — «где, когда и сколько контейнеров держать запущенными».

Обе технологии выросли из микросервисной архитектуры. Это подход, при котором один крупный сервис (монолит) разбивается на несколько независимых приложений: каждое решает свою задачу — авторизация, платежи, поиск по каталогу — и общается с остальными через API. Монолит нельзя масштабировать по частям, его тяжело обновлять, и падает он целиком. Микросервисы снимают эти ограничения, но взамен приносят новую головную боль: десятки и сотни контейнеров нужно кем-то координировать. Вот здесь и рождается связка «Docker для упаковки, Kubernetes для управления».

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

Ещё один нюанс, который многие упускают. Docker Swarm — встроенный в Docker оркестратор, и именно его, а не сам Docker, корректно сравнивать с Kubernetes. Для нескольких контейнеров одного приложения хватает Docker и Docker Compose. А вот при микросервисной архитектуре с десятками сервисов, автомасштабированием и требованием высокой доступности нужен полноценный оркестратор — здесь Kubernetes стал индустриальным стандартом.

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

По сути Docker закрывает классическую боль «работает у меня, но не работает на сервере». Окружение воспроизводимо, поэтому dev-среда совпадает с prod-средой, риск ошибок при переносе снижается, доставка и откат версий упрощаются. В отличие от виртуальных машин, контейнеры разделяют одно ядро хостовой ОС и не тянут за собой отдельную гостевую систему — отсюда быстрый старт и скромное потребление ресурсов. При этом Docker всё же создаёт дополнительную логическую прослойку и расходует ресурсы хоста. На ограниченном железе это стоит держать в уме.

В DevOps и CI/CD Docker вписывается почти без швов: разработчик описывает сборку в Dockerfile, система собирает образ и отправляет его в реестр, а оттуда образ разворачивается в тестовой и продуктивной средах без ручной настройки окружения. Минимальный Dockerfile для Python-приложения выглядит так:

Собрать образ и запустить контейнер из него можно двумя командами:

В основе всего лежит Docker Engine — клиент-серверное приложение, управляющее контейнерами, образами, сетями и томами. Согласно официальной документации Docker, Engine состоит из трёх частей: CLI-клиента, принимающего команды; демона dockerd, который создаёт объекты Docker и управляет ими; и REST API для программного управления. Глубже во внутренней архитектуре движка работают тот же демон dockerd, служба containerd (запуск и жизненный цикл контейнеров) и утилита runc, создающая изолированные процессы в Linux.

Изоляция контейнеров опирается на возможности ядра Linux. Namespaces определяют, что контейнер видит — изолируют PID, сеть, точки монтирования. Cgroups (control groups) ограничивают, сколько ресурсов он потребляет: CPU, память, дисковый и сетевой ввод-вывод. Механизм cgroups встроен в ядро Linux начиная с версии 2.6.24 (2007 год). При запуске контейнера Docker сам создаёт нужный набор namespaces и отдельную группу cgroups — вручную ничего настраивать не нужно.

Образ и контейнер — разные сущности, и путать их не стоит. Docker Image — это неизменяемый (immutable) шаблон-снимок с кодом, библиотеками и зависимостями. Образ строится из Dockerfile — текстового «рецепта» с инструкциями (FROM, RUN, COPY), которые Docker читает сверху вниз по команде docker build. Образ состоит из слоёв (layers): каждый слой — неизменяемая дельта относительно предыдущего, слои переиспользуются между контейнерами и экономят место. Контейнер добавляет поверх образа записываемый слой, где и живут его изменения.

Готовый образ публикуется в реестре. Docker Hub — крупнейший публичный реестр, по сути аналог GitHub для образов, с готовыми образами Ubuntu, nginx, PostgreSQL. По официальным условиям Docker Hub бесплатный аккаунт включает неограниченное число публичных репозиториев и три приватных (для бóльшего числа приватных репозиториев или параллельных сборок нужен платный тариф). Для корпоративного контура применяют приватные реестры: open-source Docker Registry от создателей Docker, а также Harbor, Nexus Repository и Quay.io от Red Hat с ролевым управлением доступом. В российском контуре к ним добавляются облачные реестры образов — GitVerse (СберБанк), Timeweb Cloud Registry и Beget Registry. Это важно держать в голове при планировании импортонезависимого CI/CD.

Kubernetes (K8s) — это система оркестрации контейнеров с открытым исходным кодом, автоматизирующая развёртывание, масштабирование и управление контейнеризированными приложениями. По официальному определению kubernetes.io, это «портативная расширяемая платформа с открытым исходным кодом для управления контейнеризованными рабочими нагрузками и сервисами, облегчающая как декларативную настройку, так и автоматизацию».

Оркестрация нужна там, где ручное управление ломается. Запустить один-два контейнера просто. Но когда в продакшене крутятся сотни и тысячи контейнеров на десятках серверов, вручную следить за их размещением, состоянием, обновлением и восстановлением уже невозможно — рук не хватит. Kubernetes берёт это на себя: вы декларативно описываете желаемое состояние в YAML-манифесте, а контроллеры кластера приводят фактическое состояние к желаемому — перезапускают упавшие поды, поддерживают заданное число реплик, разворачивают новые версии.

Корни у Kubernetes серьёзные. Он вырос из внутренней системы Google Borg, которой компания больше десяти лет управляла контейнерами под миллиарды запросов. Название пришло из греческого «κυβερνήτης» — рулевой, кормчий; сокращение K8s означает «k + 8 букв + s». Google открыла исходники в 2014 году. По данным CNCF (Cloud Native Computing Foundation), Kubernetes стал первым проектом, принятым фондом 10 марта 2016 года, и получил статус Graduated 6 марта 2018 года; сам CNCF работает под управлением Linux Foundation.

И важная деталь, о которую спотыкаются новички. Kubernetes сам не создаёт образы и не привязан к Docker. Он работает с любым контейнерным рантаймом через интерфейс CRI (Container Runtime Interface) — containerd, CRI-O и другими OCI-совместимыми решениями. Прямую интеграцию с Docker через dockershim удалили в версии Kubernetes 1.24 (о прекращении поддержки объявили ещё в 1.20). Начиная с версии 1.26, kubelet требует поддержки CRI v1. При этом Docker-образы в Kubernetes спокойно работают — они соответствуют стандарту OCI.

Кластер Kubernetes делится на управляющую плоскость (control plane) и рабочие узлы (worker nodes). Control plane — «мозг» кластера: он принимает решения и хранит состояние. По документации kubernetes.io, в него входят API-сервер (единая точка входа), распределённое key-value хранилище etcd (все конфигурации и метаданные), планировщик Scheduler (размещение подов) и Controller Manager (контроль соответствия желаемому состоянию). Worker Node — это «мышцы»: узел отдаёт CPU и RAM и запускает контейнеры через kubelet (исполняет инструкции API-сервера), kube-proxy (сетевые правила) и контейнерный рантайм.

Основные объекты кластера отражают логику приложения, а не отдельные контейнеры:

• Pod — минимальная единица развёртывания, один или несколько контейнеров, запускаемых совместно.
• Deployment — управляет репликами подов: держит заданное число экземпляров, выполняет rolling update и откат.
• Service — сетевая абстракция и стабильная точка входа к группе подов; поды эфемерны и при пересоздании меняют IP.
• Ingress — маршрутизация внешнего HTTP/HTTPS-трафика в кластер.
• ConfigMap и Secret — хранение конфигурации и чувствительных данных (ключи, пароли) отдельно от образа.

Возьмём конкретику. Чтобы развернуть собранный образ my-python-app тремя репликами и открыть к ним доступ, описывают два манифеста — Deployment и Service:

Манифесты применяют, а состояние подов проверяют командами:

Поверх этих объектов работают ключевые механизмы оркестрации. Автомасштабирование через Horizontal Pod Autoscaler (HPA) меняет число реплик под нагрузку. Согласно документации Kubernetes, контроллер HPA по умолчанию сверяет метрики каждые 30 секунд, сравнивая текущее значение (например, загрузку CPU) с целевым, и пересчитывает число реплик по формуле, учитывающей отклонение; если метрик несколько, берётся та, что требует больше реплик. Самовосстановление отвечает за отказоустойчивость: упал под — контроллер создаёт новый под с новым IP; вышел из строя узел — поды переезжают на другие ноды. По типовым наблюдениям, пересоздание подов на живых узлах занимает порядка 3–5 минут и зависит от настроек таймаутов, автоскейлера и готовности образов. Liveness Probe проверяет, жив ли контейнер, а Readiness Probe придерживает трафик до готовности пода. Встроенная балансировка реализована на уровне Service и kube-proxy через правила ядра iptables или IPVS с алгоритмом Round Robin (L4); для L7-маршрутизации по хосту и пути уже нужен Ingress Controller (NGINX, Traefik).

Здесь важно понимать границы «голого» Kubernetes. Он оркеструет контейнеры, но не решает задачу межсервисного взаимодействия — маршрутизацию, взаимное шифрование трафика (mTLS), детальную observability между сервисами. Для этого поверх кластера разворачивают service mesh — например, Istio или Linkerd, которые берут на себя коммуникацию между сервисами независимо от языка приложения. В базовую поставку это не входит и добавляет отдельный слой сложности в эксплуатацию. Мелочью такой слой не назовёшь.

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

Вывод практичный. Docker берут за портируемость и скорость сборки, Kubernetes — за автоматизацию эксплуатации в масштабе. Одно не заменяет другое.

Короткий критерий такой. Если сервисов немного и нагрузка предсказуема — хватает Docker и Compose. Если сервисов десять и больше, нужны автомасштабирование и деплой без простоя — пора смотреть в сторону Kubernetes. Разворачивать оркестратор ради небольшого приложения — типичная ошибка, которая добавляет сложность без пользы.

Docker или Docker Compose закрывают задачу, когда:

• идёт локальная разработка, тестирование или MVP;
• в проекте 1–5 сервисов на 1–2 серверах;
• нагрузка предсказуема, до сотен запросов в секунду;
• работает один экземпляр приложения без требования горизонтального масштаба.

Kubernetes оправдан, когда:

• в системе более 10 сервисов, разворачиваемых и масштабируемых независимо;
• нагрузка переменная и критично горизонтальное автомасштабирование;
• нужны zero-downtime деплой и высокий SLA;
• приложение распределяется по многим серверам, а команды деплоят независимо;
• нужны строгие меры безопасности — RBAC и сетевые политики.

Совет из практики: прежде чем поднимать production-кластер, Kubernetes стоит пощупать локально. Для этого есть лёгкие однонодовые дистрибутивы. minikube поднимает кластер в виртуальной машине или контейнере командой minikube start. k3s — компактный дистрибутив, который часто используют на edge и в тестовых стендах. kind — это Kubernetes-in-Docker для CI. Все три дают отработать манифесты и kubectl без затрат на боевую инфраструктуру.

Отдельный разговор — деньги. Стоимость владения (TCO) складывается не только из железа. По рыночным оценкам 2026 года ориентиры такие: минимальная инсталляция Docker Compose — это один сервер или VPS (условно от 10 $/мес), тогда как управляемый Kubernetes-кластер стартует от нескольких нод и порядка 200 $/мес за managed-control plane. Штатный DevOps-инженер для сопровождения кластера обходится в 200–400 тыс. руб./мес, аутсорс-поддержка — от 50 тыс. руб./мес, первоначальная настройка — от 100 тыс. руб. Managed Kubernetes у облачного провайдера снимает с команды ответственность за control plane, но добавляет наценку за услугу поверх стоимости голых виртуальных машин. TCO мы считаем как сумму «инфраструктура (железо или managed-тариф) + ФОТ инженеров + лицензии ПО», сравнивая self-managed и managed сценарии на горизонте 3–5 лет.

Когда же наступает момент миграции с Compose на Kubernetes? Ориентир простой: когда падение быстродействия под пиковой нагрузкой становится бизнес-риском, а ручное управление контейнерами отнимает у команды больше времени, чем экономит. Переход стоит планировать с запасом в 1–3 месяца на обучение команды и с учётом бюджета на инфраструктуру или managed-сервис. Преждевременный переезд на Kubernetes для малого проекта — распространённый и обидный перерасход.

С Kubernetes честно сравнивать не сам Docker, а Docker Swarm и Docker Compose — именно они закрывают оркестрацию и многоконтейнерный запуск. Docker Compose описывает набор взаимосвязанных контейнеров на одном сервере в файле docker-compose.yml и поднимает весь стек командой docker compose up. Веб-приложение с кэшем Redis, к примеру, описывается так:

Compose создан для локальной разработки, тестирования и демо-сред. Распределённые кластеры, автомасштабирование и высокую доступность он не поддерживает. На проектах в 50–100 сервисов Compose перестаёт справляться — и это ожидаемо.

Docker Swarm — встроенный в Docker Engine оркестратор с низким порогом входа. Он подходит малым и средним командам с 10–20 сервисами, но с оговорками. По отраслевым оценкам 2026 года, активная разработка новых функций Swarm фактически остановилась после 2022 года: Docker Inc. сосредоточилась на Docker Desktop, Docker Hub и интеграции с Kubernetes, а Swarm получает в основном обновления безопасности. При этом Mirantis, владелец Docker Enterprise, заявляет, что поддержка Docker Swarm гарантирована минимум на три года вперёд с обновлениями безопасности каждые шесть недель. Согласно документированным пределам масштабируемости Kubernetes, кластер поддерживает до 5000 узлов, тогда как Swarm на практике ограничен сотнями узлов; Swarm также не имеет аналогов Network Policies и RBAC на уровне отдельных ресурсов и, по отраслевым оценкам, занимает около 5% рынка оркестрации. Балансировка в Swarm встроена через ingress network на уровне L4.

Итог по выбору. Для одной машины и разработки достаточно Compose. Для небольшого продакшена без жёстких требований к масштабу подойдёт Swarm. Для крупных распределённых систем с автомасштабированием и высоким SLA — Kubernetes.

Docker и Kubernetes работают в связке: Docker отвечает за «как собрать и запустить контейнер», Kubernetes — за «где, когда и сколько контейнеров крутить». Ложная дилемма «или-или» возникает лишь потому, что оба слова стоят рядом. А относятся они к разным этапам жизненного цикла приложения.

Типовой пайплайн выглядит так. Разработчик пишет Dockerfile и на этапе CI собирает образ — часто через многоэтапную (multi-stage) сборку, которая разделяет среду сборки и среду выполнения. Образ отправляется (push) в реестр: публичный Docker Hub или приватный корпоративный registry. На этапе CD обновляется декларативное описание ресурсов Kubernetes (deployment.yaml или Helm chart), и кластер подтягивает (pull) новый образ из реестра при запуске подов через kubectl apply или helm upgrade. Реестр здесь обязателен: кластер не знает про исходный код и получает готовые образы только из registry.

Совместимость обеспечивает стандарт OCI (Open Container Initiative). По данным Linux Foundation, рабочая группа Open Container Initiative создана в июне 2015 года при участии Docker и CoreOS для стандартизации форматов и рантаймов контейнеров. Docker-образы фактически являются OCI-образами, поэтому Kubernetes запускает их через CRI и рантаймы containerd или CRI-O даже после отказа от dockershim. Для продакшена мы рекомендуем приватный реестр, ограничение прав push/pull и сканирование образов на уязвимости.

Практический вопрос «как перейти» распадается на управляемую последовательность шагов:

1.Аудит текущих сервисов. Составьте карту контейнеров, их зависимостей, портов, томов и переменных окружения из docker-compose.yml.

2.Выбор дистрибутива и модели. Определитесь: self-managed (свой control plane) или managed Kubernetes у провайдера, а также целевая платформа (в РФ — отечественная сертифицированная платформа, если это КИИ или ГИС).

3.Первичная конвертация. Преобразуйте Compose-файлы в манифесты утилитой kompose — она генерирует черновые Deployment/Service, которые дальше доводятся вручную (probes, ресурсы, ConfigMap/Secret, PVC).

4.Тестовый namespace. Разверните приложение в изолированном namespace тестового кластера, отладьте сеть, хранилище и доступы.

5.Перенос по одному сервису. Мигрируйте сервисы поэтапно, а не «большим взрывом», начиная с наименее критичных (stateless).

6.Мониторинг и откат. Подключите наблюдаемость (Prometheus/Grafana) и заранее продумайте план отката на Compose или Swarm на случай проблем.

Отказоустойчивый production-кластер Kubernetes требует минимум 3 узлов control plane и 3 worker-нод, желательно в разных зонах доступности. Согласно официальной документации Kubernetes, для отказоустойчивого production-кластера рекомендуется минимум 3 узла control plane: etcd требует кворума (n/2)+1 голосов по протоколу Raft, а при двух узлах кворум недостижим. Технический минимум для запуска — 1 master и 1 worker, но для продакшена такая схема не годится из-за отсутствия отказоустойчивости.

Теперь про ресурсы. Согласно официальной документации kubeadm, минимальные требования к любому узлу кластера — 2 ядра CPU и 2 ГБ RAM. Для production control plane нужно от 4 vCPU, 8 ГБ RAM и SSD/NVMe от 100 ГБ под etcd: задержки записи выше 10–20 мс ведут к потере кворума, поэтому сетевой том или RAID 5 под etcd не годятся. Worker-ноды закладывают с запасом 20–30% по CPU и памяти на перенос подов при отказе узла. Для веб-нагрузки и микросервисов ориентир — 8–16 vCPU, 32–64 ГБ RAM и NVMe 500 ГБ–1 ТБ; для СУБД и Java-нагрузок в подах — 16–32 vCPU, 64–128 ГБ RAM и NVMe от 1 ТБ.

Не менее важна сеть между узлами — про неё часто забывают. Control plane чувствителен к задержкам и джиттеру: репликация etcd по протоколу Raft требует стабильного канала 1–10 Гбит/с с низкой и предсказуемой задержкой, иначе растёт риск потери кворума. Для трафика worker-нод и доступа к сетевым СХД закладывают 10/25 Гбит/с на порт, а на уровне ЦОД — предсказуемую фабрику Spine-Leaf с Top-of-Rack коммутаторами, которая держит равномерную задержку между стойками. По опыту наших инженеров, именно сеть и дисковая подсистема под etcd чаще становятся узким местом кластера, чем нехватка CPU.

Отдельный вопрос — постоянное хранилище (persistent storage), которого у одиночного Docker-хоста попросту нет. В Kubernetes оно организуется через CSI-драйверы статически (ручное создание PV) или динамически (StorageClass + PVC создают PV автоматически). Для on-premise типичны сетевые СХД (SAN, NVMe-oF, NFS) и распределённые файловые системы (CephFS): блочное хранилище оптимально для транзакционных БД, файловое — для сценариев ReadWriteMany. Заодно решается и модель эксплуатации: self-managed — компания сама отвечает за control plane и мастер-ноды; managed Kubernetes — провайдер берёт на себя доступность control plane, а клиент управляет worker-нодами и приложениями.

Требования к «железу» под кластер — профильная зона Work System. В наших проектах мы подбираем серверные платформы Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem и Huawei FusionServer под роль ноды: под control plane и etcd — компактные узлы с быстрыми NVMe и низкой задержкой, под worker-ноды — плотные по CPU и памяти двухсокетные платформы уровня Dell PowerEdge R750xa, HPE ProLiant DL380 Gen11 или Lenovo ThinkSystem SR650 V3, с закладкой запаса на отказоустойчивость. Опыт построения отказоустойчивых серверных решений под кластерные нагрузки у нас есть, хоть и в смежных доменах. Например, для логистического провайдера КазКонтракт мы за месяц собрали отказоустойчивый кластер 1С и СУБД на оборудовании Dell, а для промышленного кластера «Косино» построили кластер виртуализации и резервного копирования на решении Huawei. Это не проекты по контейнерной оркестрации, но принципы отказоустойчивости, кворума и подбора железа под кластер переносятся на инфраструктуру Kubernetes напрямую. Конкретную конфигурацию мы всегда считаем от профиля нагрузки и планов роста, а капитальные затраты при необходимости закрываем через лизинг оборудования.

Для корпоративной РФ-аудитории 2026 года есть ещё один ключевой вопрос — чем заменять зарубежные решения. Red Hat прекратила продажи и поддержку в России 8 марта 2022 года, и Red Hat OpenShift официально недоступен российским клиентам, хотя по отчёту Gartner Magic Quadrant 2025 остаётся мировым лидером управления контейнерами. Для объектов КИИ и государственных информационных систем это делает переход на отечественные платформы фактической необходимостью. После ухода OpenShift, по некоторым отраслевым оценкам, самым распространённым решением стал self-hosted open-source Kubernetes on-premise — по ряду опросов около 44% организаций.

На базе Kubernetes построены российские платформы, входящие в Единый реестр российского ПО Минцифры. По данным реестра: Deckhouse Kubernetes Platform от компании «Флант» (запись №12338 от 21.12.2021, сертификат ФСТЭК №4860 от 04.10.2024); «Боцман» от «Платформа Боцман», входящей в «Группу Астра» (реестр №18277 от 12.07.2023, сертификат ФСТЭК №4943 от 17.06.2025); Basis Digital Energy от компании «Базис» (реестр №19659 от 01.11.2023); «Штурвал» от «Лаборатории Числитель»; Nova Container Platform от Orion soft. Managed Kubernetes у российских облачных провайдеров предлагают Yandex Cloud, VK Cloud, Timeweb Cloud, Selectel, Cloud.ru, Nubes и Инферит Облако.

Выбирать платформу стоит не по одному «рейтингу», а по набору критериев: наличие управляемого (managed) варианта у провайдера, действующий сертификат ФСТЭК под ваш класс объектов, масштаб и модель поддержки вендора, совместимость с уже используемым стеком. Публичные рейтинги при этом расходятся между собой — разные обзоры 2025 года ставят на первое место разные платформы. Единого «лучшего» решения нет, и сравнивать нужно под конкретную задачу.

Сам Docker остаётся открытой технологией, но доступ к образам и реестрам стоит продумать заранее: для устойчивости в корпоративном контуре разворачивают приватный реестр (Docker Registry, Harbor, Nexus) либо используют российские облачные реестры (GitVerse, Timeweb Cloud Registry, Beget Registry) и зеркалируют нужные базовые образы.

Небольшой дисклеймер. Статус конкретной платформы в реестре, актуальность сертификатов ФСТЭК и применимость решения к вашему классу объектов (КИИ по 187-ФЗ, ГИС, обработка персональных данных по 152-ФЗ) нужно проверять по первичным источникам — Единому реестру российского ПО и действующим требованиям регуляторов на момент закупки. Приведённые записи реестра и сертификаты даны для ориентира, а не как юридическая рекомендация.

Самая частая ошибка — воспринимать Docker и Kubernetes как конкурентов и выбирать «что-то одно». Это разные уровни стека: Docker упаковывает и запускает контейнеры, Kubernetes оркеструет их множество. В типичной инфраструктуре работают оба.

Остальные характерные промахи:

• Преждевременный переход на Kubernetes. Для проекта из 1–5 сервисов оркестратор избыточен: он добавляет сложность эксплуатации, но не приносит выгоды при предсказуемой нагрузке. По нашему опыту, в этот капкан чаще всего попадают команды, которые берут Kubernetes «на вырост» под небольшой продукт и месяцами тратят время инженеров на обслуживание кластера вместо разработки — деньги на инфраструктуру и обучение уходят, а окупаемости нет.

• Недооценка стоимости и компетенций. Kubernetes требует DevOps-экспертизы. По нашим наблюдениям и рыночным оценкам, поддержка Docker и Compose нередко закрывается силами 0,5–1 администратора, а полноценный кластер Kubernetes требует 1–3 инженеров и увеличивает трудозатраты на эксплуатацию примерно в 2–3 раза; в деньгах это 200–400 тыс. руб./мес за штатного DevOps-инженера либо от 50 тыс. руб./мес за аутсорс-сопровождение.

• Сравнение Docker напрямую с Kubernetes. Корректно сопоставлять с Kubernetes именно Docker Swarm или Compose, а не базовый Docker.

• Игнорирование требований к инфраструктуре под кластер. Кворум etcd, быстрые диски под control plane, стабильная низколатентная сеть, запас ресурсов на worker-нодах и persistent storage — это не опции, а условия работоспособности отказоустойчивого кластера.