и в итоге как всегда будет виновата лопата )

С одной стороны да, с другой стороны сейчас по таким конфигурациям уже полным-полно документации, stack overflow, slack и тд и ceph очень распространён и много где работает в кубере.

Недавно видел очень четко работающую связку Velero Ceph, порадовался :)

а в чём вопрос ?

Всем привет.

Есть docker-compose в котором одному из контейнеров нужно уметь в multicast.

Все контейнеры были изначально в bridged network, чтобы общаться друг с другом по именам.

Из коробки multicast можно только есть выставить контейнер в host network, но тогда теряется возможность обращаться к другим контейнерам по имени.

Накостыляли rabbitmq и через него перекидываем что нужно, но хотелось бы функционала описанного выше, который по-моему поддерживает weave cni в кубере.

Возможно ли поднять weave или что-то, что поддерживает multicast + чтобы контейнеры смогли общаться друг с другом по именам?

https://www.weave.works/blog/docker-container-networking-multicast-fast

https://programmaticponderings.com/2015/09/17/using-weave-to-network-a-dockerized-java-spring-we-application/amp/

Если таки смогу перенести это всё достаточно быстро в кубер (K3s), то там это проще решить и каким решением лучше всего воспользоваться?

а это нормально, что в одном решении слова  multicast и MQ рядом ?
какая реальная задача ?
зачем нужен multicast ?

Вопрос: как реализовать возможность multicast в docker-compose и не потерять возможность контейнерам общаться между собой по именам.

Зачем, почему, не вопрос.

Коллеги, прошу помощи сообщества.

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

После добавления мастер ноды в кластер произошла ошибка, в результате которой инстанс etcd получил мембера с адресом localhost.
После чего etcd отказался запускаться ввиду того, что на локальном хосте мембера нет.
etcdctl не работает.

Нужно удалить ошибочного мембера.

Есть у кого опыт подобный (можно в ЛС)?

такая ошибка при подключенрие через thunderbird к почтовому серваку

запусти одну ноду etcd с флагом --force-new-cluster

Сочувствую. Пятничный деплой. Хоть не прод?

прод

после того как запустишь однонодовый etcd можешь удалять ненужного мембера и добавлять новых

только --force-new-cluster надо запускать именно на той ноде, у которой последние данные

Поддерживаю
https://etcd.io/docs/v3.4/op-guide/recovery/

Какой же кайф работать в облаках и не копаться в этих etcd, сложных апдейтах и т.п. я вам скажу :)

особенно когда тебе говорят ”хлчешь в облако инфру перевести? Ок. но если счета будут выше чем сейчас. то вычтем из зарплаты твоей”

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

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