Заменить на RIFT?

Всем RIFT!

не надо ничего заменять на рифт

нужен еще один калико но с рифтом

И ещё один с Open/R.

привет всем, кто-нибудь читал годные сравнения swarm vs kubernetes?

Ээээ

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

вот по пунктам бы, что именно не работает, что есть в swarm, нет в k8s и наоборот

тема диссертации. могу но дорого написать

Топ10 пунктов и бесплатно?

Можно в 2 слова уложится.

а в этом просто нет смысла. сварм работает ужасно настолько, что нет смысла даже тратить время на попытку переезда. В сварм не верит даже сам докер, обещая нативную поддержку кубернетеса

это мертворожденный проект и был таким он практически с самого начала

у меня сворм на одном проекте. Порядка 60 микросервисов, могу поделиться больюи нерешенными проблемами.

ну или решенными

сравнение с кубом детальное не дам, но если кто из профи куба даст свою точку зрения - будет интересно

жги

Итак, основная беда которая меня подстерегала - отваливание нод при повышенной нагрузке. По-умолчанию ноды создаются в режиме воркер+мастер.
  Кейс: 5 нод сворма, девелоперы свободно выкатывают что им надо на dev и stage и даже prod окружения
Выкатывается сервис, выжирает все ресурсы ЦПУ ноды, нода отваливается от сети(так реализовано VPC у облачного провайдера). Сервис переходит в раскатку на другой ноде. 3 Ноды в down - кластер деградировал. Выставление лимитов вручную на каждый сервис и встраивание в новые пайплайны решает проблему... Но у куба есть такие ресурсы как квоты и лимиты, которые недопускают до такого
Выкатка сервиса с логированием уровня DEBUG или TRACE. За 40 минут 100Гб диска съедено, нода в Down. Но так как swarm упертый и иногда даже не пытается перепланировать ресурсы на другие ноды, то он  просто не может раскатать сервис и есть время это исправить. Не баг, а фича) Опять же лечиться лимитами на логи... Кстати, а как в кубе с логами? Я снимаю logspout -> logstash -> elastic
Мелочи: флаги —dns-add —dns-search-add на одном сервисе работают, а на другом нет. Не могу отловить, что не так. Лечиться - убить сервис и пересоздать. Иногда два раза. Такое же бывает с сетью. Добавляю сервис в несколько сетей, в одной работает - в другой нет.
А еще однажды у меня сервис авторизации стал призраком. 50% 500 ошибок... Я его scale=0, а он отвечает по айпишнику. А по имени нет. Помог только ребут докер-сервиса на каждой ноде. Он отмер окончательно и scale=1 возобновил работу. Потом это повторилось опять с другим сервисом. И опять.
Каскадный отказ.. понятно, что надо реализовывать в самих микросервисах, но я не нашел как описать depends в описании service.
HEALTHCHECK  реализовывается аналогичной директивой в DOCKERFILE. Сворм использует его.
Configs immutable. Т.е. чтобы внести изменения в конфиг - надо создать новый файл, подмонтировать его , а старый убрать с монтирования на этот путь(иначе Эксепшн) Планирую использовать Consul и подхватывать конфиги им, а как это правильно делать в кубе?
Ага вот еще docker stack выкатывает docker-compose. Огоромный минус в том, что он обязательно создаст сеть с именем stack и добавит в них эти сервисы. Не нашел как это обойти, ну или непонял полную логику почему это так. В кубе для этого namespaces.
Могу вспомнить еще что-то..

Плюсы: легко установить. swarm init, swarm connect новых нод и вуаля.  Еще хорошо документированное docker API. Нарастил удобный функционал поверх него, обвязки скриптами.
МЕГАПЛЮС: Разработчики сидят со мной в этой большой куче проблем, понимают важность правильной настройки логирования, лимитирования ресурсов, организации предохранителя от каскадного отказа... В-общем, настоящий девопс =)
Минусы: полнейшее говно с рандомными проблемами и десткими болезнями. 2500+ issues в github этого проекта. Проблемы висят месяцами.

Моё мнение для быстрой раскатке в качестве прототипа и для понимания ЯВНЫХ проблем в архитекутере микросервисов пойдет. Будущего НЕТ.