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

[nakamudr]

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

[tomtom11]

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

[pkdunn8]

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

[cudauser]

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

[go_whale]

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

[lorenzinoarq]

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

[Austkin]

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

[debian91]

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

[juniorredteam]

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

[Roost66]

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