конфигурации: в нашем случае флюссоника, в вашем наверное чего-то типа кролика?
Т.е. у нас конфиг то он лишь частично статичный и кладется в гит, а так в нём описывается контент, который кастомеры льют.
Да кто вам запретит-то.
я вот сейчас работаю с кодом где etcd используется как распределенный mutex, хорошо это или плохо - не могу сказать
естественные ограничения etcd, практика использования
а тебе для того, чтобы синхронизировался конфиг прозрачно между нодами?
угу. Скорее что бы он там оказался силами кубернетеса, а не процесса при котором кто-то отслеживает, что нода ожила и тащит туда какой-то конфиг и следит, чтобы он применился
Да нет, там в общем сделано всё именно для этого и достаточно стабильно.
А вот с этим всё сильно сложнее. Точнее, ну зачем вам лезть напрямую в чужой etcd? Если нужэн конфиг из куба -- так и берите средствами куба.
представь себе массовый виртуальный хостинг. Ты каждый vhost будешь коммитить в гит и разливать конфигурацию кластера, или всё таки запишешь его в какую-то БД?
То есть, я хочу сказать -- развернуть несколько нод etcd с одним ключом кластера и сертификатами -- выглядит нормально. А если "средствами куба" -- значит подрубиться к etcd куба -- ну, как-то это странно выглядит. Да и небезопасно.
а, ну вот пользоваться кубовским etcd или не пользоваться — это я изучу.
Звучит как использовать etcd по прямому назначению
А почему именно etcd? Если у вас уже есть распределённая по всем нодам бд, можете использовать её.
Обсуждают сегодня