а лучше еще кого-то позовите

мог бы просто переспросить "скорость удаления?"

мог бы просто переспросить "скорость удаления?"

копирования в /dev/null

Ты раньше упрешься в сеть, диски, проц, чем в replica factor

к чему готовиться?

"ceph гавно" (с) :)

к чему готовиться?

при смерти ноды начинается репликация, а затем у тебя забивается канал, ЦПУ в полку, память начинается потребляться как не в себя

фигасе

канал забивается -рассинхрон между куб-мастерами и воркерами

воу воу ну не также все плохо

и писец

воу воу ну не также все плохо

если применять мозг и вынести ceph на отдельные ноды, то всё не так плохо

а в этом кулюче, тогда да соглашусь

а если вынести на отдельные серваки, то они будут нормально работать?

@vrutkovs @kvaps держите меня!

вы ему ro-mode впаяли?

фигасе

о проблемах rook я писал на хабре в статье он вам не дRook там есть ссылки на посты крока и Артёма с подробными разборами проблема ceph

ну значит я был не прав

фигасе

https://habr.com/ru/post/452174/

но в комментах есть и другое мнение

но в комментах есть и другое мнение

в комментариях обещали полноценный пост

но че-то не видно

но че-то не видно

чинят rook, некогда 😱

в общем. лучше обходить стороной?

в комментариях обещали полноценный пост

слабаки, ога

в общем. лучше обходить стороной?

мы используем на деве

но на проде страшнааааааа

в общем. лучше обходить стороной?

использовать для тех данных, что не жалко потерять

в проде, лучше не гонять. для тестов или того что вообще не жалко потерять никто не запретит

в проде, лучше не гонять. для тестов или того что вообще не жалко потерять никто не запретит

хотя тут другая проблема если есть сторадж, то обычно его используют на полную не смотря на варнинг "оно может поломаться!"

так он и должен сломаться в тестах

так он и должен сломаться в тестах

иногда он живёт дольше

значит хреновые тесты.

использовать для тех данных, что не жалко потерять

Если всё равно ceph держать отдельно для продакшона, тогда зачем в тесты пихать rook?

Если всё равно ceph держать отдельно для продакшона, тогда зачем в тесты пихать rook?

не ко мне вопрос

Ну ты в статье советовал держать ceph голый, нет?

А какие вообще есть рабочие и реальные решения для ReadWriteMany ? Ну кроме NFS )

Я бы не сказал, что nfs очень рабочее решение

Лучше задуматься нужен ли вам на самом деле rwm или это так, на всякий случай

RWM тащит кучу проблем на уровень приложения, так если подумать

RWM тащит кучу проблем на уровень приложения, так если подумать

Так можно было бы сказать, если бы он сокращал количество проблем в инфраструктуре

Так можно было бы сказать, если бы он сокращал количество проблем в инфраструктуре

по-твоему, он их создает еще И НА уровне инфры?

Конечно, написать сетевую фс сложнее чем сетевой блочный девайс

В результате любой rwm работает отвратно. NFS куда не шло, но его отказоустойчивость оставляет желать лучшего

Да странно, что NFS застыл на месте по состоянию прошлого века. Хотя бы не такие сложные распределенные архитектуры реляционных баз могли бы достичь. Хотя бы один мастер, реплики на чтение, прокси по типам запросов, промоутинг мастера из живых реплик.

это как женский футбол

@LuckySB Сергей, а для чего у вас с кубспрее в секции с нодами прописан ингрес? [kube-node] node-1.s000.slurm.io node-2.s000.slurm.io ingress-1.s000.slurm.io в этом случае нода с инресом так же для всех подов используется или для подов настраивается толератность и нода ingress-1 только для ингерсов?

к хайлоаду готовятся )

Кстати, а есть какой-нибудь вариант pv, который просто делает что-нибудь типа rsync по всем нодам и всё?

Кстати, а есть какой-нибудь вариант pv, который просто делает что-нибудь типа rsync по всем нодам и всё?

PV это всего-лишь абстракция для доступа к некоему хранищу. Какие ты значешь такие хранилища?

Кстати, а есть какой-нибудь вариант pv, который просто делает что-нибудь типа rsync по всем нодам и всё?

"Просто делает" не так уж просто, нужно хранить где именно для каждого pv "мастер", придумать что делать, если оно отвалится и т.д.

Проще написать свою ФС с eventual consistency и RF=количество-нод, чем над rsync'ом скрипты скриптовать

PV это всего-лишь абстракция для доступа к некоему хранищу. Какие ты значешь такие хранилища?

ну под PV как раз имею storage class. Типа мне не надо реалтайм синхронизации на уровне вызовов ФС, а просто, например, монтируется к поду, считает его мастером, и, пусть даже раз в N-секунд синхронизирует содержимое volume со всеми нодами, чтобы можно было переподнять под на любой из них. Без ReadWriteMany и прочей дичи

Грубо говоря что-нибудь их разряда подключения AWS как блочного девайса, только для baremetal и без AWS )

Вместо рсинка есть семейство bittorrent-протоколов и реализаций. Например, syncthing. Но спереди все равно будет нужен какой-нибудь NFS

syncthing можно вторым контейнером в поде поднять

Есть стандартная практика для HA NFS через DRBD и Pacemaker

Есть стандартная практика для HA NFS через DRBD и Pacemaker

делал так, офигенно работает

А для обработки большой нагрузки для NFS что-нибудь появилось?

всем привет. может есть тут кто пользовался rook. Интересует скорость копирования файлов при репликации =2

не быстрее чем в ceph без rook

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

syncthing можно вторым контейнером в поде поднять

хех, кстати да, интересная идея, поднять daemon set с чем-нибудь типа syncthing и сайдкаром подрубать в контейнере клиент )

Привет люди добрые и многочисленные. А подскажите, есть ли канал для совсем начинающих куберистов?

Привет люди добрые и многочисленные. А подскажите, есть ли канал для совсем начинающих куберистов?

дока, там прям очень для начинающих

Привет люди добрые и многочисленные. А подскажите, есть ли канал для совсем начинающих куберистов?

Этот чат для начинающих, если фильтровать нытьё старожилов

Этот чат для начинающих, если фильтровать нытьё старожилов

старожилы причём тоже нубло

Естественно

дока докой.. но вот дока не дает ответа очевидного - что делать если одна из под core-dns в еррор уходит. и приходится на стэк искать костыли

А чо дескрайб говорит?

дока докой.. но вот дока не дает ответа очевидного - что делать если одна из под core-dns в еррор уходит. и приходится на стэк искать костыли

В #kubernetes_ru надо идти с такими вещами.

дока докой.. но вот дока не дает ответа очевидного - что делать если одна из под core-dns в еррор уходит. и приходится на стэк искать костыли

Если она уходит - ее прибьет кубер и запустит новую, стоит ли беспокоится?

дока докой.. но вот дока не дает ответа очевидного - что делать если одна из под core-dns в еррор уходит. и приходится на стэк искать костыли

https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application/

В #kubernetes_ru надо идти с такими вещами.

Это в irc?

Это в irc?

ICQ

В #kubernetes_ru надо идти с такими вещами.

freenode?

а он не убивает её. она в еррор статусе стоит и кубер её безконца рестартует. ну да ладно, я понял)

https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/

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

спасибо!

а он не убивает её. она в еррор статусе стоит и кубер её безконца рестартует. ну да ладно, я понял)

Берешь, открываешь логи контейнера, читаешь, гуглишь, выясняешь что у тебя слишком дофига запросов, выставляешь другие лимиты в деплое core-dns - и живешь дальше

Эм.. а откуда запросы в таком объеме? Кубер "нулевой", сразу после раскатки пода уходит в ошибку

причем одна.. вторая стабильно работает