свиньон это а не савиньон =)

вот кстати,  а кто как относится к идее менять архитектуру оркестраторов?
что мне не нравится в текущем kubernetes

большие накладные расходы на apiserver
etcd и raft протокол не дающий нормально жить в  geo-distirbuted

мнимая декларативность разбивающаяся о конфликтующие statefull изменения реального мира

хочется взять redpanda вместо etcd
убрать централизованный api-server
вместо него оставить только kubelet с какой то одной CRI и CSI
и который просто будет вычитывать события из redpanda
и писать события в него же

на выходе имеем 100% observability и еще и наверное какую нибудь стратегию "одно изменение за раз" можно реализовать

что думаете на счет идеи?

" redpanda вместо etcd" это не Calvin?

А можешь подробнее описать кейс, где нужно оркестировать две локации одним оркестатором?

redpanda это C++ быстрая имплементация kafka

да как бы в любой гео-распределенной системе хочется иметь общий control plane
ну хотя бы центральный, но с федерацией

хотя бы чтобы для canary deployment не приходилось городить отдельные инструменты типа https://github.com/bookingcom/shipper

и без постоянного поллинга который ничего кроме повышения rps не делает

то есть текущий кубер "как то работает"
но блин ценой 5-7% ресурсов cluster wide это получается достичь

я cкорее про то, что redpanda вместо etcd это выглядит как sequencer в Calvin. мне показалось, что у вас идея не использовать raft нежду DC http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf

а блин, я тупанул да =( redpanda тоже с raft

=( короче нужен какой то механизм "записал и забыл"->"читаю из места где жду результат"
и "прочитал" -> "записал результат и породил другие события" ->"сдвинул offset в топике"

как то так

С новым годом, распределенные инженеры!

бан просит

2

2

2

2