Когда Kubernetes уместен, а когда нет
Kubernetes — мощный, но не бесплатный инструмент. У него есть операционная стоимость: control plane требует HA-настройки, обновлений, мониторинга. Кривая обучения у команды занимает месяцы. Прежде чем нести K8s в проект, стоит честно ответить: решает ли он реальную задачу или это карго-культ? Этот урок — про то, когда K8s оправдан, когда нет, и какие альтернативы существуют.
Compose vs Kubernetes: когда переходить к оркестратору
Анти-паттерны: когда K8s не нужен
Есть несколько ситуаций, в которых развёртывание Kubernetes-кластера приносит больше проблем, чем решает:
- Один сервис на одной машине. Если у вас единственный stateless API и не больше пары RPS —
systemd+nginxна одной ВМ решат задачу за день. Никакой оркестрации не нужно. - Маленькая команда без DevOps-компетенции. Kubernetes требует выделенного человека или платформы, чтобы держать кластер живым. Если у команды три разработчика и нет инженера, понимающего networking и Linux на уровне cgroups — K8s превратится в чёрный ящик, который ломается раз в месяц.
- Чистая batch-нагрузка без масштаба. Если у вас раз в сутки выполняется ETL на 30 минут — Airflow + Celery + ВМ или AWS Batch проще, чем CronJob в K8s-кластере.
- Лёгкая нагрузка, нерегулярные deployments. Если деплой происходит раз в квартал и трафик стабилен — выгоды от автоматического rolling update нет, а постоянная операционная нагрузка кластера остаётся.
- Strict latency requirements в микросекундах. K8s networking добавляет несколько хопов (iptables/IPVS, CNI overlay). Если важны субмиллисекундные latency — bare-metal с DPDK или userspace networking, не K8s.
- Полностью stateful монолит с локальными файлами. Перенести Oracle DB или legacy-приложение, которое держит мьютекс в
/var/lock/, в K8s — больно. StatefulSet возможен, но это серьёзная переработка.
«Все так делают» — не повод тащить Kubernetes. Если ваш текущий стек удовлетворяет requirements и команда его понимает, миграция в K8s = месяцы работы + новые классы проблем (networking, storage classes, RBAC). Деньги и время лучше тратить на feature work.
Когда Kubernetes даёт максимум
С другой стороны, есть классы задач, где K8s оправдывает себя в первые недели:
- Множество микросервисов (10+). Service discovery, load balancing, rolling updates без downtime, изоляция через namespaces, единый способ конфигурации (ConfigMaps/Secrets) — всё это в K8s «бесплатно». Альтернатива — велосипед на ansible.
- Multi-team development на общей платформе. Namespaces + RBAC + ResourceQuota дают изоляцию команд в одном кластере. У каждой команды свой
devnamespace, общий staging, prod через GitOps. Это масштабируется на 50+ команд. - Hybrid / multi-cloud. K8s — единая абстракция поверх AWS, GCP, on-prem, edge. Манифесты переносятся между провайдерами с минимальными правками. Альтернатива — Terraform + три набора deployment-скриптов на каждый провайдер.
- Регулярные deployments (несколько раз в день). RollingUpdate, canary, blue-green встроены. Probes гарантируют, что трафик идёт только на здоровые Pod-ы. Это критично для команд, которые катят 50+ deployments в день.
- Горизонтальное масштабирование под нагрузкой. HPA (HorizontalPodAutoscaler) поверх metrics и Cluster Autoscaler на cloud — связка из коробки. Без K8s это собирается полгода.
- Batch + serving в одном кластере. Job/CronJob для batch, Deployment для serving, общий resource pool. Утилизация железа выше, чем в раздельных кластерах.
Сравнение с альтернативами
K8s — не единственный оркестратор. Знание соседей помогает аргументировать выбор:
Docker Swarm
Встроен в Docker Engine, поэтому установка — docker swarm init. Намного проще K8s: один YAML (docker-compose.yml с overlays), общие концепты (services, networks). Но: меньше функций (нет HPA, нет CRDs, очень слабая RBAC), почти заброшен с 2018 года, community вытекло в K8s. Подходит для маленьких homelab и legacy-проектов, не для нового продакшена.
Nomad (HashiCorp)
Лёгкий single-binary оркестратор. Запускает не только контейнеры — Java JAR, VM-задачи через QEMU, exec-задачи. Интегрируется с Consul (service discovery) и Vault (секреты). Проще K8s, не покрывает все use-cases (нет встроенного RBAC, networking слабее). Используется в командах, которые хотят оркестрацию без kubectl explain для каждого нового объекта. Не CKAD scope, но стоит знать как альтернативу.
AWS ECS / Fargate
Полностью managed, AWS-specific. ECS Tasks ~ Pods, Services ~ Deployments. Tightly integrated с ALB, IAM, CloudWatch. Простой и дешевле в эксплуатации, если вы 100% на AWS. Минус: lock-in. Манифесты ECS не переносятся в GCP или on-prem. Если вы знаете, что будете в AWS навсегда — ECS дешевле эксплуатировать.
Apache Mesos / DC/OS
Один из первых production-grade оркестраторов (Mesosphere, Twitter, Apple, Airbnb). Сейчас фактически dead — Twitter мигрировал на K8s в 2020, Mesosphere/D2iQ закрылась в 2023. Исторический интерес: показал, что multi-tenancy для batch + serving работает на масштабе.
Plain Docker Compose
Не оркестратор для production. Для локальной разработки и однонодовых dev/CI-сетапов — отличный инструмент. Без HA, без resilience, без масштабирования. Используется до момента, когда «нужно второе железо» — там либо Swarm, либо K8s.
| Свойство | K8s | Swarm | Nomad | ECS | Mesos |
|---|---|---|---|---|---|
| Активная разработка | Да | Минимальная | Да | Да | Нет |
| Multi-host | Да | Да | Да | Да | Да |
| HPA / autoscaling | Да | Нет | Через Consul | Да | Через Marathon |
| RBAC | Богатый | Базовый | Через ACL | IAM | Базовый |
| CRDs / extensibility | Богатый | Нет | Plugins | Limited | Frameworks |
| Кривая обучения | Высокая | Низкая | Средняя | Низкая | Высокая |
| Multi-cloud | Да | Да | Да | Нет | Да |
Managed vs self-hosted
После выбора Kubernetes возникает второй вопрос: брать managed-сервис или поднимать кластер самим?
Managed Kubernetes — облачный провайдер берёт на себя control plane: kube-apiserver, etcd, scheduler, controller-manager. Вы платите за это (обычно $0.10/час за кластер) и за worker-узлы. Не возитесь с обновлениями control plane, бэкапами etcd, ротацией сертификатов. Версии немного отстают от upstream — типичный лаг 1-2 минорных релиза.
Топ managed K8s на май 2026:
- AWS EKS — Elastic Kubernetes Service. Глубокая интеграция с IAM, ALB, EBS, EFS. Поддерживаемые версии обычно N-2 (на май 2026: v1.31-1.33). Pod density ниже из-за ограничения IP-адресов на ENI.
- GCP GKE — Google Kubernetes Engine. Самый «upstream»-близкий managed K8s. Поддерживает rapid channel с свежими версиями. Autopilot — полностью managed nodes (без
kubectl execна узлы), Standard — традиционный. - Azure AKS — самая дешёвая control plane (free tier). Глубокая интеграция с Azure AD, Application Gateway.
- DigitalOcean Kubernetes — простая UI, дешевле hyperscalers. Подходит для стартапов и pet-проектов.
- Yandex Managed Kubernetes — Российский managed K8s в Yandex Cloud. Поддерживает версии до 3 минорных релизов назад. Базовый control plane бесплатный, HA — платный.
Self-hosted Kubernetes — вы поднимаете control plane сами: kubeadm init или с помощью operators типа Cluster API. Все апдейты — на вас. Полная гибкость: можете включить любой alpha-feature, использовать любой CNI, настроить любой scheduler. Используется когда: on-prem (нет облака), очень специфические требования к networking, compliance требует физического контроля над данными.
Для прохождения CKAD не нужно поднимать продакшен-кластер. Достаточно kind (Kubernetes in Docker) на лаптопе — он стартует за 30 секунд, поддерживает multi-node, и поведение совпадает с production K8s на уровне API.
Distributions Kubernetes
«Vanilla» Kubernetes — это исходный код из github.com/kubernetes/kubernetes. На его основе строятся distributions — пред-собранные пакеты с дополнениями:
- Vanilla K8s — то, что вы получаете через kubeadm. Без addons (CNI, CoreDNS, storage classes — отдельно). Используется как база остальных distributions.
- OpenShift (Red Hat OKD/OCP) — корпоративный K8s от Red Hat. Жёсткие defaults безопасности (SecurityContextConstraints вместо PSA), встроенный image registry, Source-to-Image build, web console. Лицензия платная (RHEL ecosystem). Используется в больших энтерпрайзах.
- Rancher / RKE2 — управление множеством кластеров через единую UI. Хорош для гибридных и edge-сценариев.
- k3s — lightweight distribution от Rancher. Single binary, использует SQLite или etcd. Идеально для edge, IoT, dev-environment. Полностью CNCF-conformant, что значит — те же API, что и в production K8s.
- kind (Kubernetes in Docker) — runs K8s nodes как Docker containers. Идеален для CI и локальной разработки. Используется в курсе для labs.
- minikube — single-node K8s в VM (или Docker). Старше kind, чуть медленнее, но больше addons. Используется в туториалах.
- microk8s (Canonical) — single-binary K8s через snap. Часто используется на Ubuntu-серверах.
Все CNCF-conformant distributions проходят одни и те же CKAD-задачи одинаково. Манифесты переносятся. Различия — в addons, observability, security defaults. Если вы умеете писать манифесты на kind, вы сдадите экзамен и сможете работать с GKE/EKS/OpenShift.
Итоги
Решение «K8s или нет» — не техническое, а инженерно-экономическое. Если он закрывает реальные боли (масштаб, multi-team, multi-cloud, частые деплои), стоимость освоения окупается. Если эти боли не ваши — K8s принесёт операционную нагрузку без выгоды.
Для прохождения CKAD-курса вам понадобится kind или minikube локально. В production — managed K8s в одном из больших облаков, чтобы не возиться с control plane.
В следующем уроке — формат CKAD-экзамена, что именно проверяется и как готовиться.