Миф: Kubernetes нужен любому проекту

MAATRIX

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

Откуда взялся миф про «индустриальный стандарт»

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

Миф подпитывается несколькими вещами одновременно. Во-первых, конференции и вакансии DevOps/SRE почти всегда говорят о Kubernetes — просто потому что там концентрируются компании соответствующего масштаба, и это создаёт иллюзию, будто без него на рынке труда и в резюме «не считово». Во-вторых, managed-предложения от облаков (EKS, GKE, AKS) действительно сняли часть боли с установки кластера, и кажется, что раз это «в один клик», то сложности больше нет. В-третьих, срабатывает обычный страх отстать от индустрии — а это ровно та эмоция, на которой удобно продавать сложность, которая объективно не нужна.

Рациональное зерно в этом есть, и его стоит проговорить честно, прежде чем переходить к цене мифа.

Что Kubernetes правда решает — и на каком масштабе

Kubernetes закрывает четыре класса проблем, которые реальны и дорого стоят там, где они есть:

• Автоматическое масштабирование под нагрузку. Horizontal Pod Autoscaler разворачивает и гасит поды по метрикам (CPU, память, кастомные метрики через Prometheus Adapter), Cluster Autoscaler добавляет и убирает узлы. Это решает задачу «нагрузка прыгает в 10-20 раз между пиком и провалом», а не задачу «сайт иногда тормозит».
• Самовосстановление при отказе узлов. Если физический или виртуальный узел падает, control plane перепланирует поды на живые узлы без участия человека. Это ценно, когда у вас десятки узлов и отказ отдельного узла — статистически регулярное событие, а не форс-мажор раз в полгода.
• Оркестрация множества взаимодействующих сервисов. Service discovery, встроенный DNS, network policies, единый способ описать зависимости между 15-40 микросервисами — там, где сервисов действительно много и они меняются независимо друг от друга, ручное управление этим превращается в отдельную профессию само по себе.
• Стандартизация деплоя между облачными провайдерами. Один и тот же манифест (с поправкой на StorageClass и Ingress-контроллер) едет и на AWS, и на GCP, и на bare-metal. Это снимает часть vendor lock-in для команд, которым реально нужна портируемость между провайдерами.

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

Первая цена мифа: сложность кластера как отдельная профессия

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

Минимум того, что нужно понимать и уметь чинить в 3 часа ночи:

• Сеть внутри кластера. CNI-плагин (Calico, Cilium, Flannel) — это не абстракция, а реальный слой маршрутизации между подами, с собственными таблицами, network policy и режимами (overlay vs. BGP). Когда под не может достучаться до другого пода, разбираться приходится именно на этом уровне, а не через docker network ls.
• Персистентное хранилище. PersistentVolume, PersistentVolumeClaim, StorageClass, CSI-драйверы — стек, который в облаке работает почти прозрачно, а на своих серверах требует отдельной настройки (например, Longhorn или Rook/Ceph) и понимания, что произойдёт с данными пода при его переезде на другой узел.
• RBAC. Role-based access control — собственная модель прав с Role, ClusterRole, RoleBinding, ServiceAccount. Настроить её неправильно значит либо дать поду больше прав, чем нужно (частая причина инцидентов безопасности), либо сломать деплой в самый неподходящий момент.
• Обновления самого кластера. Control plane, kubelet, CNI и CSI обновляются не одновременно и не автоматически — их совместимость по версиям нужно проверять вручную, а мажорное обновление control plane (например, с 1.29 на 1.30) способно сломать API, на который завязаны ваши манифесты и Helm-чарты.

Для команды без выделенного DevOps-инженера это не разовая настройка, а постоянная когнитивная нагрузка: каждый инцидент требует понимания сразу нескольких слоёв абстракции — приложение, под, сервис, ingress, CNI, узел, control plane. Большая часть этих возможностей при этом попросту не используется: HPA настроен «на всякий случай», а нагрузка на самом деле стабильна и меняется на 20-30% в течение суток.

# типичный список того, что нужно держать в голове
# просто чтобы понять, почему сервис недоступен

kubectl get pods -A                  # какие поды упали
kubectl describe pod <pod> -n <ns>   # почему упал: OOMKilled? CrashLoopBackOff?
kubectl get events -A --sort-by=.lastTimestamp
kubectl get pv,pvc -A                # не отвалилось ли хранилище
kubectl get networkpolicy -A         # не режет ли сеть трафик
kubectl top nodes                    # не исчерпаны ли ресурсы узла

Каждая из этих команд — вход в отдельный домен знаний. В docker-compose эквивалент диагностики — это docker compose logs и docker compose ps, и почти всегда этого достаточно.

Вторая цена мифа: ресурсы, которые вы платите за оркестрацию, а не за продукт

Даже managed Kubernetes не бесплатен по накладным расходам, и это отдельная статья затрат, которая не связана напрямую с тем, что видит пользователь вашего продукта.

Минимальный работоспособный кластер обычно выглядит так:

Даже если ваш продукт умещается в один контейнер с 1 vCPU и 2 ГБ RAM, «обвязка» вокруг него в Kubernetes — control plane, минимум два-три узла для отказоустойчивости, системные поды на каждом узле, отдельный мониторинг — легко удваивает или утраивает счёт за инфраструктуру просто на управление, а не на обслуживание пользователей. Точные цифры зависят от провайдера и тарифов, поэтому здесь стоит держать в голове именно порядок эффекта, а не абсолютные цены: для проекта с одним-двумя серверами накладная стоимость управления кластером почти всегда превышает выгоду от его возможностей.

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

Что вместо этого: docker-compose на одном-двух серверах

Для типичного небольшого или среднего проекта — сайт с бэкендом, API, база данных, кэш, может быть очередь — практически всегда достаточно docker-compose.yml на одном сервере, при необходимости с простым балансировщиком перед парой серверов.

# docker-compose.yml — минимальный прод-стек
services:
  app:
    image: myapp:2026.08
    restart: unless-stopped
    env_file: .env
    depends_on:
      - db
      - redis
    deploy:
      resources:
        limits:
          cpus: "2"
          memory: 2g

  db:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    env_file: .env.db

  redis:
    image: redis:7
    restart: unless-stopped

  nginx:
    image: nginx:1.27
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro

volumes:
  pgdata:

Этого набора хватает на самовосстановление на уровне контейнера (restart: unless-stopped плюс healthcheck перезапускает упавший процесс), на резервное копирование volume штатными средствами, на обновление приложения через docker compose pull && docker compose up -d без простоя дольше нескольких секунд. Если нужна отказоустойчивость на уровне сервера, а не только контейнера — добавляется второй сервер и HAProxy или Nginx в роли балансировщика перед ними, что закрывает подавляющее большинство сценариев «а что если сервер упадёт» без единой строчки YAML про поды.

Как именно развернуть такой стек по шагам, включая типичные грабли с правами на volume и порядком старта сервисов, разобрано в статье про docker-compose для прод-окружения на Ubuntu 24.04. Если стек уже на проде и раз в пару недель что-то отваливается — стоит свериться со списком частых ошибок в отдельном разборе граблей docker-compose в проде. А если решаете, HAProxy или Nginx ставить перед парой серверов — там же есть прямое сравнение в статье HAProxy или Nginx для балансировки.

Разница в эксплуатационной сложности не количественная, а качественная: docker-compose требует понимания одного файла и одного хоста. Kubernetes требует понимания распределённой системы. Если ваш продукт не порождает задач, которые эта распределённость решает, вы платите её цену без её выгоды.

Когда Kubernetes реально оправдан

Есть конкретные признаки, по которым можно проверить себя честно, а не по ощущению «пора взрослеть»:

• Много независимых сервисов, которые деплоятся отдельно. Не 3-4 контейнера одного приложения, а 15+ микросервисов с разными командами-владельцами, разными циклами релизов и реальной необходимостью в service mesh и независимом масштабировании каждого.
• Резко переменная нагрузка, которую нужно гасить автоматически. Не «вечером трафика чуть больше», а кратные скачки за минуты — сезонные распродажи, вирусный трафик, пакетная обработка с нерегулярным объёмом, где вручную поднимать и гасить серверы физически не успеть.
• Команда с выделенным DevOps/SRE. Тем, кто способен закрывать инциденты на уровне control plane, CNI и хранилища, а не только на уровне приложения — то есть Kubernetes не единственная их обязанность, а часть профильной экспертизы.
• Реальная необходимость в мультиоблачности или переносимости. Требование контракта или регулятора работать одновременно в нескольких облаках/регионах с единым способом деплоя — здесь стандартизация манифестов окупает сложность.
• Уже есть боль, которую вы пытаетесь решить, а не гипотетическая. Если вы можете назвать конкретный инцидент за последние полгода, который Kubernetes бы предотвратил или упростил — это сигнал. Если единственный аргумент «все так делают» — это не сигнал, это статус.

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

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

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