а в чем именно?

Тупо по сложности по
lvm + iscsi
Vs
ceph + rdb

Как то первая связка на порядок проще

Управлялка targetd там вообще питон

Я ceph в проде не юзал особо( опыт ограничен)
Но есть отзывы по опыту  использования на примере крупных контор
В общем я пока не готов заводить себе человека отдельно под цеф

А вариант тупо воткнуть не катит, я не на работе, у меня клиенты.
Либоя я или мои люди понимают, либо не используем

Только тесты если, но там опять же клиент в курсе +- и сам может выбрать

Ну и до 40- 60 терабайт как минимум ceph вообще избыточен

Личное мнение

Да

Но все визуализаторы нормальные только в платном будут

hubl не дотягивает до таких? Выглядит симпатично
я даже на минуточку собрался накатить силиум на тесте, но ядро версии 3.10 не подходит(

Ессно, там даже в доке говорится, что силиум поддерживается с ядра 4.9

1.9.1 с ядра 4.9.17

А с учетом того, что cfs bug пофиксили в 4.18, хз зачем ниже 4.18 версию ядра испольщовать в кубе

хаббл очень простая визуализация

условно на уровне weave scope

по большому счету веб морда бесполезна, и довольно простенькая. Вряд-ли ты будешь ее юзать. Еще не нравится что нет способа нормально связывать информацию из hubble и cilium monitor. Чтобы например банально пробить identity по политикам. hubbe эти самые identity не показывает, а просто например пишет DROP. А вот почему drop не напишет, и приходится идти на определенный агент cilium (на ноде где крутится нужный тебе pod), смотреть cilium monitor и выцеплять запросы на нужный тебе pod, смотреть какой все таки там identity и уже только потом ты можешь пробить этот запрос на предмет того, запрещен он политиками cilium'а или нет.

сыроват на мой взгляд. Сталкиваюсь с проблемами периодически, обкладываю костылями

тестишь из сугубо спортивного интереса, или есть какие-то причины перейти на него?
в проде калику юзаешь?

в проде kube-router. Есть желание на cilium перейти, нравится что не iptables, нравится конецпт с identity. То есть он назначает уникальный идентификатор на приложения, и он не меняется, если не меняются те части, которые его уникально идентифицируют. И когда например реплика в деплойменте увеличивается и поднимается новый pod на какой-то ноде, нет никаких задержек пока cni приведет правила iptables на этой ноде в соотвествии с политиками, cilium уже знает под какие правила подпадает этот pod благодаря уже известеному уникальному идентификатору и правила уже сразу работают. Также ebpf по шустрее робит