Почему не использовали Kubernetes для контейнеризации?

Что проверяют

Умеете ли вы считать стоимость эксплуатации и отличать задачи, которым нужен оркестратор, от задач, которым он не нужен. Заодно проверяют аккуратность в терминах.

Как отвечать

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

Аргументы против Kubernetes в конкретном проекте:

• один или два сервиса на одной машине: docker compose плюс systemd и обратный прокси закрывают запуск, автоперезапуск и TLS;
• кластер это отдельный продукт в эксплуатации. Сеть, ingress, хранилища, сертификаты, обновления версий, RBAC, мониторинг самого кластера. Без выделенного человека это технический долг;
• самостоятельно поднятый кластер для отказоустойчивости требует нескольких узлов управления, и на маленьком проекте инфраструктура стоит дороже приложения;
• порог входа команды: разбор падения пода через события, логи и ресурсные лимиты сложнее, чем docker logs;
• часть задач дешевле закрывают managed-сервисы контейнеров у облака, PaaS или Nomad.

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

Где спотыкаются

Отвечают «проект маленький» и замолкают. Нужен критерий, а не размер: какие именно возможности оркестратора не требовались и чем их заменили.

Приписывают Docker Compose отказоустойчивость. Он поднимает контейнеры на одной машине. Машина выпала, сервис лежит, и обновление без простоя тоже придётся делать руками.

Называют Kubernetes средством контейнеризации, повторяя формулировку вопроса. Контейнеризация это рантайм вроде Docker, а Kubernetes про оркестрацию: планирование по узлам, обнаружение сервисов, перезапуск упавшего. Подмену терминов слышно сразу, и уточняющий вопрос прилетит именно сюда.