- «Нам, наверное, уже нужен Kubernetes?»
- «Почему вы так решили?»
- «Потому что релизы стали нервными: один контейнер не поднялся, staging отличается от prod, а серверы у нас держатся на памяти одного человека».
Я слышал этот разговор много раз. Обычно он начинается не на миллионах запросов, а в тот момент, когда изменения уже нельзя надежно проводить руками. Ниже - короткая рамка, по которой я сам принимаю решение: оставаться на Docker + CI/CD или идти в Kubernetes.
Docker решает упаковку, Kubernetes - жизнь сервиса в проде
Docker хорош тем, что убирает разницу между «у меня на машине работает» и сервером. Вы собираете образ, кладете его в Docker Hub или GHCR, потом поднимаете контейнер в предсказуемой среде. Для небольшого продукта это уже большой шаг вперед.
Проблема появляется позже. Docker сам по себе не отвечает на вопросы, которые бизнес чувствует деньгами: кто перезапустит упавший сервис, как обновить версию без простоя, как удерживать staging и prod в одном состоянии. В этот момент и появляется Kubernetes - как способ управлять контейнерами в проде, а не просто запускать их.
У нас был проект на Laravel 11, PostgreSQL 16 и Redis - 6 сервисов, 2 окружения, релизы 3-4 раза в неделю. Пока все жило на одной VM, Docker Compose выглядел нормально. Когда добавились фоновые воркеры и пара веток для тестирования, поползли расхождения: где-то забыли переменную окружения, где-то остался старый worker, и команда теряла полдня на поиск причины.
| Инструмент | За что отвечает | Чего не решает |
|---|---|---|
| Docker | Упаковка приложения | Отказоустойчивость и rollout |
| CI/CD | Сборка, тесты, деплой | Само восстановление сервисов |
| Docker Hub / GHCR | Хранение образов | Контроль состояния окружений |
| Kubernetes | Оркестрация контейнеров | Не чинит слабый процесс сам по себе |
Чаще сначала нужен порядок в релизах, а не оркестратор
Если у вас 1-3 сервиса, один прод-сервер и релизы раз в неделю, Kubernetes обычно рано. На практике болит не платформа, а ручная работа: кто-то заходит по SSH, делает pull, перезапускает контейнеры, потом еще вручную проверяет, поднялось ли все после выкладки.
Мы часто закрываем это более простой связкой: Docker Compose, GitHub Actions или GitLab CI/CD, registry и аккуратный сценарий деплоя на VM. У одного B2B-сервиса было 2 приложения и worker на Node.js 20 + NestJS. Релиз занимал 40 минут; после сборки pipeline, выноса секретов и healthcheck он стал занимать 7 минут.
Нужен ли Kubernetes, если Docker уже есть?
Нет. Docker отвечает за упаковку, а не за оркестрацию. Для небольшого продукта нормальный CI/CD часто дает больше пользы, чем ранний переход в кластер.
До и после здесь выглядят довольно прозаично:
- До: сообщение в чате, ручной pull образа, ручной restart контейнера
- После: pipeline собирает образ, публикует его и запускает deploy, rollback занимает 5-10 минут
- Результат: меньше ночных релизов и меньше зависимости от одного инженера
Kubernetes окупается на цене координации
Я бы смотрел не на трафик, а на стоимость ручного управления изменениями. Когда у вас уже 8-10+ сервисов, релизы идут каждый день, а простой бьет по выручке или поддержке, ручная координация становится дороже самой разработки.
У одного SaaS-проекта под NDA было 12-15 сервисов на PHP 8.3, Laravel 11, PostgreSQL 16 и Redis. Все жило на VM, выкладки шли почти ежедневно, и команда тратила 8-10 часов в неделю только на синхронизацию релизов и разбор расхождений между окружениями. После перехода на managed Kubernetes операционка сократилась до 2-3 часов в неделю: появились rolling updates, readiness probes и предсказуемый deploy.
Kubernetes начинает окупаться в тот момент, когда люди уже не успевают надежно проводить изменения руками.
Обычно я вижу одни и те же сигналы:
- окружения расходятся, и это всплывает только на релизе
- rollback формально есть, но в стрессе он слишком медленный
- масштабирование делается вручную
- нужен zero-downtime, а выкладки все еще нервные
- инфраструктура держится на одном инженере
Самая дорогая ошибка - взять Kubernetes «на вырост»
Неудачные внедрения у нас тоже были. В прошлом году команда с 3 сервисами и редкими релизами решила сразу поднять self-hosted Kubernetes. Через 8 недель стало ясно, что релизы не ускорились: CI/CD усложнился, логи собраны кое-как, секреты разложены по разным местам, а инциденты разбираются дольше, чем раньше на обычных VM.
Я и сам однажды недооценил объем скрытой работы в таком переходе. Вместе с кластером к вам приходят ingress, сертификаты, storage, backup, обновления control plane, метрики, логи и доступы. Если в команде нет сильного DevOps-инженера, хаос просто переезжает на более дорогой уровень.
Managed Kubernetes - это компромисс?
Для малого и среднего бизнеса чаще это нормальный путь. Yandex Managed Kubernetes, Selectel Managed Kubernetes, AWS EKS, GKE, AKS снимают часть низкоуровневой эксплуатации, но архитектуру, безопасность и CI/CD все равно надо держать в порядке.
Простая матрица решения
Я обычно раскладываю выбор в три состояния:
- Пока рано - 1-3 сервиса, один сервер, релизы раз в неделю, ручной rollback быстрый
- Уже пора считать - 8+ сервисов, 2+ окружения, ежедневные релизы, требования к доступности заметно выросли
- Пора делать - деплой регулярно бьет по деньгам, срокам и фокусу команды
Если сомневаетесь, не считайте поды и ноды. Посчитайте, сколько стоит один ручной релиз, один откат и одна неделя зависимости от памяти конкретного человека. По моему опыту, именно эти цифры лучше всего показывают, нужен ли бизнесу Kubernetes сейчас или порядок в релизах еще можно навести более простой связкой.
