Ну точно так же из строя может выйти облачный managed сервис. Или если развернуть кубер руками, взять 3 ноды, то и все 3 могут сгореть, в одном большом пожаре.

По факту, современные сервера очень надежные, и просто так из строя не выходят, возможно в очень редких случаях.

Ключевое же в такой ситуации сохранить именно данные (бд и файлы), но это уже другая большая тема. К тому же куберу обычно базу разворачивают отдельно. Точно так же можно сделать и для компоуза.

Как и написано в статье, кубер поднимался через microk8s. Для дева можно было бы перейти на managed, но это дополнительные деньги. А клиенты многие приходят с требованиями по хостингу/ос . Там нет возможности взять managed решение.

По поводу ресурсов. После перехода с кубера нагрузка упала в 2 раза. Может дело в microk8s, а может в самом кубере.

вы не поверите, для надежной работы любого кластера нужно больше одной ноды

Дело в том, что для 95% клиентов кластер то и не нужен, 4/8 сервер справляется с нагрузкой. И на одной ноде компоуз работает без проблем, с кубером постоянно проблемы были. То крон зависнет намертво, то еще что-то.

ну никто же не заставляет

А потом выясняется, что есть проблемы с безопасностью. Например, по такому пути :10255/pods кубер светил env переменные и другие данные подов. Да и в целом, вносятся изменения, которые облегчают жизнь.

И да, docker compose ни разу не альтернатива kubernetes.

Согласен, но базовая задача управление контейнерами докера, чем оба инструмента и занимаются. Конечно, кубер это комбайн с кучей функций, которых лишен компоуз. Но не всем они нужны. Ну и в целом, чем система проще, тем она надежнее)

Но делать законченное продакшн решение это проект и это дорого,

Да, согласен. Но у нас решение получилось чисто под наши задачи, и только для тестового окружения. Работает уже 9 месяцев, без проблем) периодически что-то туда дописываем.

в десяток строчек на bash

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

А так у нас супер легкий клиент, который почти ничего не делает, и сервер который все умеет, собранный в один бинарник. Внутри него и крон и работа с бд. Не вижу никакого преимущества в скриптах перед этим...

Вообще, за идею я взял кубер как раз. Где есть клиент (kubectl), который по http доставляет конфигурацию на сервер, а он уже с ней работает

Только с v2, но он же устаревший

а зачем нужно было использовать два бинарника на гоу, если тоже самое вроде как можно сделать внутри gitlab-ci.yml без использования утилиты taskfile.dev

Каким образом?

И второй вопрос с миграциями БД: как решено то, что некоторые миграции могут сломать работающее приложение?

Ну это не проблема инструмента деплоя. А вообще если миграция развернулась на деве, то развернется и на проде. Схема базы одинаковая. Не помню с этим никаких проблем

Хотя если процесс деплоя на дев и на прод сильно различаются (например, используют разные инструменты), то это тоже не хорошо.

Инструменты действительно разные, но в целом суть похожа. На проде первичная настройка идет в ручном режиме. Далее уже рабочее приложение обновляется через ci/cd . Это не занимает на самом деле много времени, при этом дает гибкость.

Это не работает без swarm

Да, у нас сейчас и есть wildcard, от letsencrypt. Но кроме выдачи сертефиката, traefik еще и динамический роутинг дает, смотрит на labels контейнеров и направляет на них трафик.

Ну и еще вот в одном проекте стояла задача, когда нужно было выделить разные поддомены, например by.myfeature.test.company.com . wildcard бы отвалился, но traefik самостоятельно выдал обычный letsencrypt сертефикат

Кубер хорошо работает если брать его в облаках, самому же поднимать на голом железе то еще удовольствие, да и стабильность куда ниже.

А вот использовать облака не всегда есть возможность, некоторые клиенты приходят с запросом на определенный хостинг или даже ОС