Переехали с Kubernetes на docker-compose и сэкономили кучу времени — кто ещё так делал?

[vlad_rust]

У нас команда из 6 человек, держали EKS. Тратили примерно половину спринта на обслуживание кластера вместо фич. Снесли, переехали на docker compose на двух виртуалках, деплой через ssh + reload nginx. Третий месяц полёт нормальный.

[ruslan_ml61]

А что будете делать когда одна вируталка ляжет в 3 ночи? compose сам никуда не переедет и приложение просто умрёт.

[vera1098]

healthcheck + systemd restart на каждом хосте, и второй сервер как горячий резерв за nginx upstream. За три месяца ни одного инцидента, чего, кстати, и EKS нам не гарантировал.

[grigory2566]

Поддерживаю. 90% контор тащат k8s ради строчки в резюме, а не ради нагрузки. У нас пик 200 rps, какой к чёрту кластер на 80 нод.

[tanya_go]

Пока вас шестеро — да, согласен. Когда станет 30 микросервисов и 5 команд, ваш ssh-деплой превратится в ад с человеческими ошибками. k8s это про организацию людей, а не про rps.

[dnscache8196]

За вас control plane обслуживает Amazon за условные $0.10/час. Что именно вы там полспринта обслуживали? Похоже на skill issue если честно.

[roman_sigma]

CNI периодически глючил, cert-manager протухал на ровном месте, ingress-nginx ломался на каждом втором апгрейде, cluster-autoscaler крутил ноды как ему вздумается. $0.10/час за control plane это далеко не вся история расходов.

[svetlana_js]

"k8s простой" говорили они. У меня на ОДИН сервис четыре ямла: deployment, service, ingress, hpa. На compose это 8 строк и всё понятно с первого взгляда.

[kira_api82]

Мы замеряли: холодный старт пода в EKS ~40-90 сек с подтягиванием образа и прогревом. На compose-хосте образ уже локально, 3 сек до готовности. Для нашего CI с частыми деплоями это критично.

[anton_linux]

А как же rolling update без даунтайма на голом compose? Вот это реально неудобно решать руками каждый раз.