Когда Kubernetes НЕ нужен
Предыдущие шаги показали Kubernetes с сильной стороны: он сам раскладывает контейнеры по серверам, перезапускает упавшее, масштабирует приложение по нагрузке и выкатывает новые версии без остановки сервиса. На этом фоне легко решить, что инструмент такой мощности нужен везде. Это не так, и честный разговор про Kubernetes обязан включать обратную сторону: у всей этой мощи есть цена, и в большинстве небольших проектов цена перевешивает пользу. Этот шаг про то, как понять, что Kubernetes вам пока не нужен, и почему в этом нет ничего стыдного.
Цена называется сложностью
За автоматику Kubernetes расплачиваются сложностью. Это большая система: контейнеры заворачиваются в поды, поды держит Deployment через ReplicaSet, доступ дает Service, настройки приходят из ConfigMap, секреты из Secret, все это разложено по namespace, а под ними работает сеть из CNI-плагинов, kube-proxy и собственного DNS. Каждый из этих объектов вы прошли на предыдущих шагах, и вместе они складываются в систему, которую нужно учить, обслуживать и мониторить.
Эта сложность не разовая. Кластер живет, ломается своими способами, требует обновлений и присмотра. Если у компании нет ни кластера, ни человека, который умеет с ним обращаться, то Kubernetes добавляет к приложению целый второй слой проблем, которого до него просто не было. Поэтому первый честный вопрос звучит не «выиграю ли я от Kubernetes», а «потяну ли я его обслуживание».
Когда хватает Docker Compose
Тот самый Docker Compose из модуля про Docker никуда не делся и для множества задач остается правильным выбором. Если все ваше приложение это несколько контейнеров на одном сервере, Compose опишет их в одном файле и поднимет одной командой, без кластера, без манифестов, без отдельного слоя для обслуживания.
Признаки, по которым видно, что Kubernetes пока избыточен, простые. Сервис помещается на один сервер, и запаса по мощности хватает. Трафик ровный, без резких всплесков, под которые нужно срочно добавлять копии. Выкаты редкие, и короткая пауза на обновление никого не пугает. Команда небольшая, и держать кластер некому. Пет-проект, внутренняя утилита, лендинг, небольшой сервис с предсказуемой нагрузкой живут на Docker Compose годами и чувствуют себя прекрасно. Поднимать ради них кластер это стрельба из пушки по воробьям.
Где Kubernetes начинает окупаться
Зеркально выглядит и обратная картина, тот порог, за которым сложность кластера наконец оправдывается. Окупается Kubernetes там, где сходятся три вещи: масштаб, отказоустойчивость и частые выкаты.
Масштаб это когда контейнеров и серверов столько, что раскладывать их руками уже невозможно, ровно те задачи оркестрации, с которых начинался модуль. Отказоустойчивость это требование, чтобы сервис продолжал работать при падении отдельных машин, а не ждал, пока дежурный поднимет его вручную. Частые выкаты это поток новых версий, который без автоматического rolling update превращается в день монотонной ручной работы на каждый релиз. Когда эти три фактора совпадают, ручное управление перестает справляться, и сложность кластера окупается с лихвой. Когда не совпадают ни один, кластер это лишний вес.
Это общее правило, а не частный случай
Та же логика работает шире самого Kubernetes. Инструмент берут под задачу, а не потому, что он на слуху или есть у всех. Сложный инструмент, поднятый без нужды, не дает преимущества, а отнимает время на обслуживание и добавляет способов сломаться. Это правило достаточного инструмента: для каждой задачи берется самое простое решение, которое ее закрывает, и усложняют только тогда, когда простое перестало справляться.
Факт. Если кластер все-таки нужен, его необязательно собирать и обслуживать самому. В облаках есть managed Kubernetes, где control plane целиком берет на себя провайдер. Это снимает большую часть забот по эксплуатации, но не отменяет сложности самого Kubernetes: манифесты, объекты и сеть остаются на вас, и учить их все равно придется.
Причем здесь DevOps
Выбрать подходящий инструмент это тоже инженерное решение, и для девопса оно такое же рабочее, как написать манифест. Уметь развернуть Kubernetes ценно, но не менее ценно вовремя сказать, что в этом проекте он не нужен и хватит Docker Compose. За лишним кластером стоят реальные деньги и реальное время людей, которые его поддерживают, и решение «обойдемся без него» экономит и то, и другое. Здравый ответ на собеседовании про Kubernetes это не «я подниму его везде», а «я подниму его там, где он окупается, и не стану городить кластер вокруг сервиса, которому хватает одного сервера».
Словарик
| Термин | Что означает |
|---|---|
| Docker Compose | Запуск нескольких контейнеров на одном сервере из одного файла, без кластера |
| Правило достаточного инструмента | Брать самое простое решение, которое закрывает задачу |
| Оркестрация | Управление множеством контейнеров на множестве серверов |
| Отказоустойчивость | Способность сервиса работать при падении отдельных машин |
| Managed Kubernetes | Кластер от облака: control plane обслуживает провайдер |