Kubernetes для небольших команд: стоит ли начинать в 2026

Коротко: команде из 3–10 человек Kubernetes нужен, только если сервисов много, их масштабируют независимо и простой стоит денег. В остальных случаях быстрее и дешевле Docker Compose на одном-двух серверах или Docker Swarm. Если кластер всё-таки нужен — начинайте с managed-сервиса или k3s, а не с ручной сборки через kubeadm.

Kubernetes стал стандартом настолько, что его ставят «на всякий случай»: в вакансиях он есть, в докладах есть, значит, и нам надо. Небольшие команды платят за это неделями настройки, кластером, который потребляет больше ресурсов, чем само приложение, и одним человеком, который единственный понимает, почему под не стартует. Вопрос оркестрации стоит решать вместе с архитектурой продукта: если проект делает внешняя команда, например команда, которая разрабатывает и сопровождает такие продукты на заказ, спросите до старта, на чём будет работать прод и кто его будет поддерживать после сдачи.

Ниже — без евангелизма и без хейта: что Kubernetes реально даёт, во что обходится, какие есть промежуточные варианты и по каким признакам понять, что пора.

Что Kubernetes даёт на самом деле?

Kubernetes — это оркестратор контейнеров: вы описываете желаемое состояние («три реплики сервиса, вот образ, вот лимиты памяти»), а контроллеры постоянно приводят кластер к этому состоянию. Отсюда главные плюсы:

• Самовосстановление. Упал контейнер — его перезапустят. Умер узел — поды пересоздадут на других машинах.
• Декларативные релизы. Rolling update и откат одной командой, без самописных скриптов деплоя.
• Горизонтальное масштабирование. HorizontalPodAutoscaler добавляет реплики по нагрузке, а в облаке cluster autoscaler добавляет и узлы.
• Единый язык описания. Сеть, конфиги, секреты, тома, задания по расписанию — всё в YAML-манифестах, которые лежат в git.
• Экосистема. Helm-чарты, операторы для баз данных и очередей, cert-manager, ingress-контроллеры — многое ставится готовым.

Обратите внимание: почти все эти плюсы проявляются, когда машин несколько и сервисов много. На одном сервере с тремя контейнерами самовосстановление умеет и restart: unless-stopped в Compose, и Restart=always в systemd.

Во что обходится кластер маленькой команде?

Цена Kubernetes — не столько железо, сколько время людей. Разложим по статьям.

Ресурсы

Документация kubeadm требует для каждой машины кластера минимум 2 ГБ памяти и 2 CPU (требования kubeadm). Отказоустойчивый control plane — это три узла с etcd, чтобы кворум пережил потерю одного. Добавьте ingress-контроллер, мониторинг, сборщик логов, cert-manager — и системные компоненты легко съедают несколько гигабайт памяти ещё до первого вашего сервиса. Для приложения, которому хватает одного VPS на 4 ГБ, это кратный рост счёта.

Сопровождение

Проект выпускает три минорных версии в год, каждая получает патчи примерно 14 месяцев (политика релизов Kubernetes). Обновляться можно только последовательно, через одну минорную версию за раз, а вместе с кластером — проверять устаревшие API в манифестах и чартах. Сюда же ротация сертификатов, бэкап etcd, обновление узлов и аддонов.

Знания

Минимальный словарь, без которого кластер не отладить: Pod, Deployment, Service, Ingress, ConfigMap, Secret, PersistentVolumeClaim, requests и limits, probes, RBAC, NetworkPolicy. Плюс Helm, плюс сетевой плагин. Если всё это знает один человек, кластер становится риском: отпуск или увольнение инженера — и команда не может выкатить релиз.

Когда Kubernetes маленькой команде точно не нужен?

Если про ваш проект верно большинство пунктов ниже, кластер принесёт больше работы, чем пользы:

• один-три сервиса, и они выкатываются вместе;
• нагрузку держит один сервер, и запас по ресурсам есть хотя бы двукратный;
• релизы — раз в неделю или реже;
• простой на 15–30 минут неприятен, но не стоит денег и не нарушает договор;
• в команде нет человека, которому интересно и положено заниматься инфраструктурой;
• продукт ещё ищет рынок, и архитектура будет меняться.

Типичный пример — MVP, внутренний сервис компании, сайт с API и админкой. Им нужны нормальный CI, бэкапы, мониторинг и базовая защита сервера, а не оркестратор.

Какие есть альтернативы попроще?

Docker Compose + systemd

Самый короткий путь: сервисы описаны в одном файле, деплой — docker compose pull && docker compose up -d из CI. Для перезапуска при сбоях хватает политики restart, для обновления без простоя — двух экземпляров за nginx и поочерёдного перезапуска. Если с контейнерами вы только знакомитесь, начните с нашего разбора Docker простыми словами.

# docker-compose.yml: приложение, база и обратный прокси
services:
  app:
    image: registry.example.org/team/app:1.4.2
    restart: unless-stopped
    env_file: .env
    depends_on: [db]
  db:
    image: postgres:17
    restart: unless-stopped
    volumes: [pgdata:/var/lib/postgresql/data]
  proxy:
    image: nginx:1.27
    restart: unless-stopped
    ports: ["80:80", "443:443"]
volumes:
  pgdata: {}

Docker Swarm

Встроенный в Docker режим кластера. Тот же формат compose-файлов, сервисы с репликами, rolling update, overlay-сеть и секреты. Поднимается двумя командами — docker swarm init на первой машине и docker swarm join на остальных. Экосистема скромнее, но для трёх-пяти серверов и десятка сервисов его возможностей обычно хватает.

HashiCorp Nomad

Оркестратор одним бинарником: умеет контейнеры, обычные процессы и виртуальные машины. Проще Kubernetes в эксплуатации, хорошо дружит с Consul и Vault. Учтите, что с 2023 года Nomad распространяется под лицензией BSL, а не MPL — для внутренних задач это обычно не мешает, но юристам стоит посмотреть.

PaaS и serverless

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

Если кластер всё-таки нужен: k3s, managed или kubeadm?

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

k3s — сертифицированный CNCF дистрибутив Kubernetes (проект в CNCF), собранный в один бинарник: встроенный containerd, ingress Traefik, локальное хранилище, вместо etcd по умолчанию может работать SQLite. Установка — одна команда (документация k3s):

# первый узел (сервер)
curl -sfL https://get.k3s.io | sh -
sudo k3s kubectl get nodes

# токен для подключения рабочих узлов
sudo cat /var/lib/rancher/k3s/server/node-token

# на рабочем узле
curl -sfL https://get.k3s.io | K3S_URL=https://10.0.0.10:6443 K3S_TOKEN=<токен> sh -

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

Managed-кластер у российских и зарубежных облаков снимает с вас control plane: провайдер держит его в нескольких зонах, обновляет и бэкапит. Вам остаются рабочие узлы, манифесты и аддоны. Для команды без DevOps-инженера это самый реалистичный путь в Kubernetes.

Как перейти на Kubernetes без большого взрыва?

1. Наведите порядок до кластера. Образы собираются в CI, конфигурация — в переменных окружения, приложение не хранит состояние на локальном диске. Это полезно при любом варианте, и без этого Kubernetes не поможет. Пайплайн можно собрать по нашему гайду GitLab CI с нуля.
2. Добавьте health-эндпоинты. /healthz и /ready нужны для readiness и liveness probes — без них rolling update выкатит сломанную версию.
3. Поднимите тестовый кластер. k3s на одной ВМ или kind на ноутбуке. Опишите один сервис: Deployment, Service, Ingress.
4. Перенесите один некритичный сервис. Не базу данных и не платёжный шлюз. Базы на первом этапе оставьте на отдельных серверах или в managed-СУБД.
5. Подключите наблюдаемость. Метрики и логи кластера должны появиться до переноса важных сервисов — см. Prometheus и Grafana и логирование в продакшене.
6. Запишите runbook. Как обновить кластер, как откатить релиз, как восстановить etcd. Если это знает только один человек, вы ещё не готовы.

Чек-лист: решение за 5 минут

Поставьте по баллу за каждый пункт, который про вас:

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

0–2 балла — Docker Compose и хороший CI. 3–4 — Docker Swarm, Nomad или пилот на managed Kubernetes с одним сервисом. 5–6 — Kubernetes оправдан; начинайте с managed или k3s и сразу закладывайте мониторинг, бэкапы и runbook.

Частые вопросы

Нужен ли Kubernetes, если у нас один сервер?

Почти никогда. На одном сервере Kubernetes добавляет слой управления, но не даёт главного — переноса нагрузки при отказе машины. Docker Compose и systemd закрывают такой проект проще, а время лучше потратить на бэкапы и мониторинг.

Сколько серверов нужно для минимального кластера?

Для учебного или тестового кластера хватит одной машины с k3s. Для продакшена, который переживает отказ узла, нужно минимум три узла: на них размещают control plane и etcd с кворумом. Managed-кластер снимает с вас control plane, тогда достаточно двух-трёх рабочих узлов.

Что выбрать для старта: k3s или managed Kubernetes?

Если в команде нет человека, готового отвечать за обновления и etcd, — managed: провайдер обновляет control plane и делает его отказоустойчивым. k3s хорош, когда нужен свой кластер на собственных серверах или на краю сети и есть кому его сопровождать.

Сколько времени уходит на сопровождение кластера?

Kubernetes выпускает три минорных версии в год, каждая поддерживается около 14 месяцев. Значит, раз в несколько месяцев нужно обновлять кластер, чарты и манифесты. Плюс мониторинг, сертификаты и бэкап etcd. На маленькую команду это ощутимая доля времени одного инженера.

Чем Docker Swarm хуже Kubernetes?

Экосистемой и гибкостью: у Swarm нет операторов, CRD и такого выбора готовых чартов. Зато он встроен в Docker, поднимается одной командой и использует тот же формат compose-файлов. Для нескольких сервисов на трёх-пяти машинах этого часто достаточно.

Когда пора переходить с Docker Compose на Kubernetes?

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

Можно ли учить Kubernetes без продакшен-кластера?

Да. kind и minikube поднимают кластер на ноутбуке, k3s — на одной виртуальной машине. Этого достаточно, чтобы разобраться с Deployment, Service, Ingress и Helm, прежде чем тащить кластер в прод.

Вернуться в блог