Docker Compose окончательно мёртв? Все тащат в Kubernetes даже для трёх контейнеров

[ksenia_data]

У нас стартап, три сервиса плюс postgres и redis. Тимлид давит на то чтобы сразу пилить на k8s, мол потом не переписывать. А я смотрю на docker compose и не понимаю зачем нам этот зоопарк из деплойментов, сервисов и ингрессов на пять контейнеров. Кто прав?

[maria4362]

Преждевременный k8s это классическая ошибка. Compose отлично тянет до того момента пока вам реально не нужен автоскейлинг и self-healing на нескольких нодах. Если у вас один сервер, k8s это чистый оверхед на обслуживание.

[coredata6336]

Поддержу. У меня был проект где из-за хайпа влезли в managed k8s, счёт за кластер прилетел больше чем за сами приложения. Compose плюс systemd прекрасно держал нагрузку год.

[egor_ml13]

Не соглашусь категорично. Если вы заранее знаете что будете расти, переписывать с compose на k8s это боль на ровном месте. Возьмите k3s, он лёгкий, на одной ноде живёт спокойно, и манифесты потом переносятся в большой кластер один в один.

[artem_kernel93]

k3s интересный вариант, про него не думал. А по обслуживанию он реально настолько проще чем полный kubeadm?

[fedor_tcp]

Да, k3s это один бинарь, встроенный traefik и sqlite вместо etcd на старте. Поднимается за пару минут, ест мало памяти. Для маленьких сетапов прям топ.

[nastya5877]

Ещё вариант который часто забывают это Docker Swarm. Хейтят, но для трёх сервисов с compose-подобным синтаксисом он живой и сильно проще k8s. Хотя да, экосистема вокруг него уже почти не развивается.

[tcploop1339]

Главный вопрос не compose vs k8s, а кто это будет потом поддерживать в 3 ночи когда упадёт. Если в команде нет человека который знает кубер на уровне дебага сети и RBAC, то k8s это мина замедленного действия.