Ответ
Работать без Kubernetes абсолютно нормально и часто оптимально для определенных сценариев. Критичность его отсутствия зависит исключительно от требований проекта и зрелости команды.
Когда можно и нужно обходиться без K8s (на моем опыте):
- Монолитное или простое приложение: Для классического монолита, развернутого на нескольких виртуальных машинах, оркестрация через Ansible, Chef или даже простые bash-скрипты может быть надежнее и понятнее.
- Небольшие команды и проекты: Если у вас 1-5 сервисов и небольшая DevOps-команда, сложность администрирования K8s-кластера (обновления, отладка сетевых политик, troubleshooting) может перевесить преимущества. Решения вроде Docker Compose для разработки или managed-сервисов (AWS ECS, Google Cloud Run) для продакшена часто быстрее выходят в production.
- Специфичные рабочие нагрузки: Для stateful-приложений с высокими требованиями к вводу-выводу или legacy-систем иногда виртуальные машины — более предсказуемая и подходящая среда.
Когда Kubernetes становится критически важным в моей работе:
- Высокая плотность и эффективность использования ресурсов: Когда нужно запускать сотни разнородных сервисов на ограниченном пуле железа, планировщик K8s незаменим.
- Стандартизация деплоя и операций: K8s предоставляет единый API для деплоя, что позволяет построить унифицированный CI/CD пайплайн для десятков команд.
- Сложные требования к доступности и масштабированию: Встроенные механизмы самовосстановления (liveness/readiness probes), горизонтальное автомасштабирование подов (HPA) и продвинутые стратегии rollout (canary, blue-green через Istio/Argo Rollouts) сложно реализовать с тем же уровнем абстракции на других платформах.
Вывод: Kubernetes — мощный, но сложный инструмент. Его внедрение должно быть обосновано реальными потребностями в оркестрации, а не трендом. Я выбираю технологию исходя из задачи.