Знаете, есть такая болезнь среди бэкендеров: стоило нам завести два сервера, как уже кто-то в команде начал мечтать про Kubernetes. А я-то помню времена, когда мы годами держали прод на Docker Compose, и никто не умирал от простоя. Однажды нас пригнали в проект, где у команды было четыре микросервиса, два билдер-контейнера и один cron на ночной репорт. И знаете, что там стояло? Полный кластер на пяти нодах, с HPA, Ingress, Service Mesh и кучей кастомных манифестов, написанных человеком, который Kubernetes видел только в документации. Прод падал раз в три дня, и никто не понимал почему. Я потратил неделю на разбор — и в итоге вернул всё обратно на Compose. Через месяц команда написала мне спасибо, а мониторинг перестал жужжать.
Мой личный опыт говорит: Kubernetes — это не про масштаб сам по себе, а про масштаб, который вы реально контролируете. Если у вас нет выделенного SRE, нет понимания, как отлаживать CrashLoopBackOff в два часа ночи, нет бюджета на управляемый кластер — вы просто берёте на себя головную боль, которая вам не нужна. Docker Compose отлично решает задачу, когда у вас до десятка сервисов, несколько инстансов каждого и вы не гонитесь за автомасштабированием в реальном времени. Я не говорю, что Compose — это плохо. Я говорю, что это нормальный, рабочий, предсказуемый инструмент для большинства команд до ста человек.
Когда я рекомендую перейти на Kubernetes, это только тогда, когда у вас есть чёткий триггер: вы регулярно упираетесь в потолок железа, вам нужно разворачивать десятки идентичных реплик с перебалансировкой нагрузки, у вас есть команда, которая готова учиться и поддерживать, или вы выходите на уровень, где CI/CD пайплайн не может позволить себе простой на час ради ручного деплоя. Без этих триггеров — это просто хвастовство в резюме.
Ещё один момент, который часто упускают. Сложность эксплуатации. Я видел команды, которые перешли на K8s ради «гибкости», а потом выяснилось, что они не знают, как читать логи через kubectl, как диагностировать сетевые политики, как разбираться с пробелами в правах сервисных аккаунтов. И каждый инцидент превращается в археологические раскопки. Compose же — это прозрачность. Один файл, понятная сеть, понятный volumes, понятный порядок запуска. Для большинства продуктовых команд это не слабость — это сила.
Мой совет простой: не смотрите, что модно. Смотрите на свою команду, на ваш стек, на ваш SLO. Если Compose даёт вам стабильность, быстрое развёртывание и понятную отладку — оставайтесь на нём. Если вы чувствуете, что упираетесь в ограничения, и при этом у вас есть ресурс на освоение нового — тогда осматривайте Kubernetes, но осознанно, а не потому что «так делают в Кремниевой долине». И помните: лучший продакшн-стек — это тот, который ваша команда понимает и может чинить в два часа ночи, а не тот, который красивее выглядит на слайдах.
А у вас были случаи, когда переход на Kubernetes оказался избыточным? Или наоборот — Compose уже не справлялся и пришлось уходить на что-то более серьёзное? Делитесь опытом, мне интересно услышать живые истории.
Мой личный опыт говорит: Kubernetes — это не про масштаб сам по себе, а про масштаб, который вы реально контролируете. Если у вас нет выделенного SRE, нет понимания, как отлаживать CrashLoopBackOff в два часа ночи, нет бюджета на управляемый кластер — вы просто берёте на себя головную боль, которая вам не нужна. Docker Compose отлично решает задачу, когда у вас до десятка сервисов, несколько инстансов каждого и вы не гонитесь за автомасштабированием в реальном времени. Я не говорю, что Compose — это плохо. Я говорю, что это нормальный, рабочий, предсказуемый инструмент для большинства команд до ста человек.
Когда я рекомендую перейти на Kubernetes, это только тогда, когда у вас есть чёткий триггер: вы регулярно упираетесь в потолок железа, вам нужно разворачивать десятки идентичных реплик с перебалансировкой нагрузки, у вас есть команда, которая готова учиться и поддерживать, или вы выходите на уровень, где CI/CD пайплайн не может позволить себе простой на час ради ручного деплоя. Без этих триггеров — это просто хвастовство в резюме.
Ещё один момент, который часто упускают. Сложность эксплуатации. Я видел команды, которые перешли на K8s ради «гибкости», а потом выяснилось, что они не знают, как читать логи через kubectl, как диагностировать сетевые политики, как разбираться с пробелами в правах сервисных аккаунтов. И каждый инцидент превращается в археологические раскопки. Compose же — это прозрачность. Один файл, понятная сеть, понятный volumes, понятный порядок запуска. Для большинства продуктовых команд это не слабость — это сила.
Мой совет простой: не смотрите, что модно. Смотрите на свою команду, на ваш стек, на ваш SLO. Если Compose даёт вам стабильность, быстрое развёртывание и понятную отладку — оставайтесь на нём. Если вы чувствуете, что упираетесь в ограничения, и при этом у вас есть ресурс на освоение нового — тогда осматривайте Kubernetes, но осознанно, а не потому что «так делают в Кремниевой долине». И помните: лучший продакшн-стек — это тот, который ваша команда понимает и может чинить в два часа ночи, а не тот, который красивее выглядит на слайдах.
А у вас были случаи, когда переход на Kubernetes оказался избыточным? Или наоборот — Compose уже не справлялся и пришлось уходить на что-то более серьёзное? Делитесь опытом, мне интересно услышать живые истории.