LINUX.ORG.RU
решено ФорумAdmin

Storage solution for kubernetes

 ,


0

2

Изучая k8s возник вопрос, как делать storage для работы с данными, которые должны сохраняться, а не исчезать после завершения работы pods.

Сам кубик ничего не предлагает, а именно предлагает подключаться к сторонним ресурсам или облачным хранилищам или к всяким NFS/iSCSI и т.п. Мой кластер стоит на голом железе и варианты с использованием облачных хранилищ отпадают из-за скорости доступа к ним.

В идеале я бы хотел некое решение, которое я могу поставить как k8s приложение, прямо на кластер и использовать жесткие диски нод, как сетевой рейд. Хочется гибкости, такой же как у кубика, чтобы можно было легко создавать разделы, цеплять их к pods и потом удалять если они не нужны. Мне очень нравится фишка от VM как thin provisioning. Ес-но решение должно быть надежное и проверенное. Подскажите, кто что использует?

Я бегло погуглил и нашел пару вариантов: Rook и StorageOS, но я не знаю как они в работе и может есть что получше?

Имхо, это самое слабое место кубернетеса. Он спроектирован под stateless, то есть под уничтожается, и все его файлы тоже уничтожаются, а все решения - по сути сетевые файловые системы, либо пространства S3 like поверх NOSQL хранилищ. Это удручает, так как задержки.

https://datamattsson.tumblr.com/post/182297931146/highly-available-stateful-workloads-on-kubernetes

menangen ★★★★★
()
Ответ на: комментарий от Samamy

В том-то и дело, что непонятно как выбирать, хотелось бы воспользоваться опытом людей, которые столкнулись с примерной задачей и успешно ее решили.

Может вы посоветуете что? Или расскажете что сами используете?

samson_b
() автор топика

Ты запутался

K8s целесообразно использовать под приложения которые только логику содержат. Смысл в том, что нет нужды заботится о инстансе твоего приложения, если он не содержит данные; ты его без задней мысли сносишь при первых же симптомах, и разворачиваешь новый инстанс. Это позволяет минимизировать трудозатраты на поддержку и простои. Специально для такого режима эксплуатации, данные выносят на отдельные, совершенно, хосты, для которых k8s не нужен.
Thin provisioning - вообще слова из другой песни

redwagon
()
Ответ на: Ты запутался от redwagon

K8s целесообразно использовать под приложения которые только логику содержат.

Т.е. по твоему, приложения, которые позволяют построить storage на базе k8s кластера, чтобы потом его использовать внутри этого кластера - не годные?

samson_b
() автор топика

https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner

Вот эта фигня + хранилище которое умеет в redundancy само = достойное решение без всяких лишних оверхедов.

А так то конечно rook, но это сеф, а он не очень быстр даже на супер железе

Ну и конечно нужно быть готовым к вечной альфе в самом кубе и всём вокруг него.

redixin ★★★★
()
Ответ на: комментарий от samson_b

Т.е. по твоему, приложения, которые ..

Следует разделять «приложения» и «хранимые данные».
Зачем тебе данные внутри pods, которые должны пересоздаваться by design?

redwagon
()
Ответ на: комментарий от redwagon

Следует разделять «приложения» и «хранимые данные».

Под приложениями я имел ввиду storage solutions, а не приложения, которые я собираюсь гонять на кубике.

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

samson_b
() автор топика
Последнее исправление: samson_b (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

Почему? Он просто хочет на тех же мощностях еще один сервис для хранения. По-моему, кубернетес как таковой тут побоку, надо выбрать и поднять что-то отдельное, доступ к чему поддерживается из коробки.

Лол, написал, и потом понял, что пересказал твое «кубернетес не нужен» в этом контексте. Ок, да, если ты это имел ввиду :)

zendrz ★★
()
Последнее исправление: zendrz (всего исправлений: 1)
Ответ на: комментарий от samson_b

Ты можешь конечно так делать, но вообще это колхоз и возможно когда ресурсов сервера хватит для одновременной работы на нем и того и этого.
Общепринятой практикой является разделение серверов по выполняемым задачам - одни для данных, другие для приложений.
Бывает так, что для полноценной работы сервиса целиком нужны мощности целой, или даже нескольких нод, тогда становится ясно, что хранилище на отдельных серверах - это то что и должно быть.

redwagon
()

Энтерпрайз не опен-сорсный подойдет?
MapR-FS. Правда не уверенн, как бесплатная версия будет с этим всем работать, и будет ли просто это всё скрутить вместе.

Ну или у HDFS есть какие-то способы её монтировать, как локальную файловую систему, а не использовать только через API.

Ты можешь использовать диски самих нод кластера, и вероятно если очень прям постараться, можно это всё в Кубер завернуть, но скорости сравнимой с обычной локальной файловой системой скорее всего и близко не будет.

sphericalhorse ★★★★★
()
Ответ на: комментарий от redwagon

но вообще это колхоз и возможно когда ресурсов сервера хватит для одновременной работы на нем и того и этого.

Т.е. правильная стратегия - это иметь два кластера, один для выполнения задач, а второй для хранения? А не переусложнение ли это системы?

вероятно если очень прям постараться, можно это всё в Кубер завернуть

Такое не пойдет. Нужна система, в которой разработчики (а не я) заморочились и проработали ее для Kubernetes, чтобы я мог использовать всю гибкость кубика создавая на лету разделы, подключая их к подам и т.п.

Я нашел несколько коммерческих систем, но с возможностью использовать их бесплатно (всякие developer и community версии) Например Robin https://robin.io/

samson_b
() автор топика

CEPH — самое прямое и правильное решение в данном случае.

ugoday ★★★★★
()
Ответ на: комментарий от samson_b

Тебе стоит почитать для начала, зачем нужен докер контейнер.

создавая на лету разделы, подключая их к подам

Зачем тебе разделы в подах? Это нездоровое желание.

redwagon
()
Ответ на: комментарий от anonymous

Зачем тебе разделы в подах? Это нездоровое желание.

Контейнеры в подах, в процессе работы генерируют данные, которые желательно сохранить.

samson_b
() автор топика
Ответ на: комментарий от samson_b

Написал письмо в Robin с просьбой предоставить мне их community версию, если дадут - буду ставить ее, если нет, то буду смотреть в сторону Rook.

Изучи для начала русский язык.

К слову, говоря о рунете, я не нашел там какой-то полезной информации по выбору решения, а вот в англоязычных постах есть интересная статья о человеке, кто находился примерно такой же ситуации и перепробовал много чего. Я буду отталкиваться от этой статьи. https://vitobotta.com/2019/08/06/kubernetes-storage-openebs-rook-longhorn-sto...

samson_b
() автор топика
Ответ на: комментарий от samson_b

Ставлю точку в этом топике

В итоге, я установил linstor (на базе DRBD). Были некоторые подводные камни и с бубном поплясать пришлось, но в итоге я получил то что надо.

А именно, сетевой рейд из 3-х зеркалирующих друг друга диска, расположенных соответственно на 3-х k8s нодах. Также важный момент, что можно делать thin provisioning, т.е. выделяя раздел для pod'а, свободное место в общем пуле уменьшается только на фактически используемое место, а не на величину раздела.

На моей виртуалке с ssd, работает вполне быстро:

==================
= Dbench Summary =
==================
Random Read/Write IOPS: 27.5k/5097. BW: 238MiB/s / 89.9MiB/s
Average Latency (usec) Read/Write: 290.40/1454.19
Sequential Read/Write: 437MiB/s / 112MiB/s
Mixed Random Read/Write IOPS: 7584/2489

samson_b
() автор топика
Ответ на: комментарий от anonymous

В моем конкретном случае да. Это esxi хост с тремя виртуалками. Но это не продакшн, я использую это чтобы освоить Kubernetes.

samson_b
() автор топика
Ответ на: комментарий от filosofia

Я вдохновился на такое решение после просмотра этого видео https://youtu.be/ZY0yJqLa1vY

Я согласен с автором, что делать отдельный storage cluster для имеющегося application cluster- это чрезмерное усложнение системы, которое само по себе делает систему менее надёжной.

За основу я взял вот это https://vitobotta.com/2019/08/07/linstor-storage-with-kubernetes/ и мануал с сайта linbit

Но там есть неточности и некоторое команды нужно осмыслить и подкорректировать, а не просто копировать. Основные проблемы были:

1. Найти все необходимые rpm чтобы установить систему. Разработчик linbit, хоть и заявляет про open source, бинарники предоставляет только клиентам кто платит. Для энтузиастов - сырцы, которые названы не совсем так как бинарники, что вызывает непонятки и не сказано, что нужно, чтобы их правильно собрать. В итоге, я нагуглил сторонний repo с бинарниками почти последних версий и поставил с него.

2. С установкой модуля ядра drbd, он оказался без подписи и требовал отключить secure boot в bios.

3. Настраивая «сетевой рейд», нужно было назвать ноды в нем точно также, как они названы в k8s, иначе не заработает.

Я ставил все на Centos 8 и Kubernetes 1.16.3.

samson_b
() автор топика
Последнее исправление: samson_b (всего исправлений: 3)
Ответ на: комментарий от zendrz

Спасибо!

Да, реально спасибо

Я всегда рад поделиться опытом. Если будет свободное время - напишу полный гайд, как и что делать по шагам, чтобы все взлетело на CentOS 8. У меня все шаги записаны в конспекте :)

samson_b
() автор топика
Последнее исправление: samson_b (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.