и то там были костыли на костылях потому что докер-композ тупой как валенок

У меня команда микросервисы в compose разрабатывает и в проде они именно в нём работают.

docker-compose для одной ноды, как там масштабировать?

Очень небольшой стек микросервисов, штук 10-15. В планах переход на кубер, там можно будет другими вещами этим управлять.

Никак. Это решение для standalone

это именно compose, не swarm и тп

кубер будет k3s

docker run  обычно рекомендуется для IaC. Что в ansbile что в puppet. Но модуль с багами, что тут поделать - печаль

да там баги в докер-композе, который сомнительную полезность имеет вообще

В чистом докере без compose обвязки и его yaml'ов  ребятам не удобно работать, да и мне было бы тоже. У них там и билд команды есть и использование fluentd драйвера и bridge сети, в общем есть уже наработки, которые они боятся пока трогать.

Когда мигрируем на k3s, что для меня не долго, всё эти микро кластеры будем управлять одним большим кластером в eks с помощью rancher fleet. Классная штука. А пока что puppet, видимо.

так локально compose использовать. Я возможно разочарую, но в кубе вряд-ли вы будете деплоить свои микросеврисы в minkube локальный. compose остаенется. Поэтому у вас в любом случае локальные и продовые среды будут разные

нет вы не совсем понимаете архитектуру, да и с кубером невпервой. k3s у них полностью заменит compose

прод для них это куча небольших машин разбросанных по миру

одиночных

ясно, путь боли.

вы то с кубером не в первой. А вот хз как вы будете объяснять, как 200 строчек ямла compose превратились в тысячи строк ямла да еще с go-template (там скорее всего будет helm).
Да еще почему-то в локальном k3s все завелось, а в продовом нет или наоборот. Политки какие-нибудь другие, psp включен, веб-хуки есть, лимиты на namespace, какие-нибудь операторы установлены/не установлены,  fetureGates какие-то другие и т.д.. В итоге смысла в локальном кубе особо то и нет, поскольку трудно его делать таким как в проде, а если локальный куб делать как продовый, то им неудобно пользоваться с целью локальной разработки.

Так у них локальный и прод одно и то же, кроме того, что они датчики от некоторой аппаратуры эмулируют, но это так и останется. А куберу да, нужно будет обучаться. Но helm и т.д. это я им напишу и буду учить. У них там с  compose есть определённые трудности и ограничения, которые они решают костылями, а в кубере оно работает из коробки, поэтому в том числе мигрируем.

В общем не заморачивайтесь насчёт куба, не переубедите :)

А чем кстати  rancher fleet лучше чем банальный CD, который деплоет в несколько кластеров? Ну например argocd или на крайняк из CI это делать. Ну или прозрачно федерацию юзать по типу https://admiralty.io/

А k3s чем лучше обычного куба? Это тот что вместо etcd использует sqlite?

Чет к продуктам rancher есть недоверие. rke был, потом сделали совсем другой rke2 который никак с ним не совместим. Помню что-то у них уже для деплоя приложений в куб было - тоже закопали. Да и в целом странные у них решения.