kubectl exec -n test zookeeper-0 -- cat /proc/1/io | grep -E "^(read|write)"

read_bytes: 30744576
write_bytes: 25563136

Я в баше не силен, я б попробовал это загнать в прометей и потом им просто посмотреть

гарантии что люди которые это увидят умеют в прометеус нет ;)
там по идее человек должен тупо сделать copy\paste ;)

ладно пока оставлю так
потом посмотрим
watch -n 1 -d -x bash -c 'kubectl exec -n test zookeeper-0 -- cat /proc/1/io | grep -E "^(read|write)"'

kubectl exec -n test zookeeper-0 -- sh -c 'while sleep 1; do cat /proc/1/io | grep -E "^(read|write)" | paste - -; done'

берегите kubeapi смолоду)

ну вообще да, кубелет нативные метрики по утилизации io предоставлять умеет

если показать им красивый график в графане будет ещё лучше

но это если есть графана :)

ненене, никто это ЧАСТО запускать не будет ;)
ну ок, в общем и целом понятно что делать

Всем привет! Ребята, подскажите, пожалуйста, следующий момент. На сколько правильно использовать кубер для развёртывания базы данных (например postgresql) и kafka?
Есть ли опыт эксплуатации таких решений? В инете много статей о том, что кубер можно использовать только для развёртывания компонентов, которые не хранят состояния. Однако, есть статьи где рассказывается как к контейнерам можно подключать разделы хост-машины, чтобы обойти эти ограничения. Однако, многие devops считают эти решения костылями.
Действительно ли это костыли?

А ты что предпочитаешь?

Как разработчик или как пользователь?)

helm-чарты операторов как ответить?)

Если можно: сразу два

Там можно несколько вариантов ответов выбрать

ой)

Если вы сами готовы тащить такое решение, и при этом сможете его поддерживать и чинить в случае поломок, то это не костыли, это уровень вашей компетенции.

Как пользователь я предпочитаю Helm-чарты т.к.:
1) Я всегда могу видеть что происходит внутри
2) Если мне нужно что-то добавить или изменить, я могу легко этого сделать без пересборки docker-образа и прочей лабуды
3) Если разработчик чарта забухал, я или кто угодно может продолжить его разработку
(т.к. это всего-лишь пачка манифестов)
4) Большинство операторов расчитанно на деплой 1-3 копий приложения, когда таких копий становится сотни или даже тысячи операторы показывают себя далеко не с самой лудшей стороны.
5) CRD требуют cluster-admin прав
6) Со временем кластер оказывается под чистую засран всевозможными CRD и контроллерами для них. Тратится больше ресурсов, и этим зоопарком сложно управлять.

Как разработчик я предпочитаю Helm-чарты т.к.:
1) Наиболее простой инструмент, который есть у всех
2) Пользователи всегда могут видеть что применяется внутри (т.к. это всего-лишь пачка манифестов)
3) Если я условно забухаю, кто угодно сможет продолжить разработку

Эти бы слова, да год назад,..  :)