GlusterFS как внешнее хранилище для Kubernetes

Сколько gluster ни собирал, ломаться там особо не чему, потому что он просто файлики из локальной папочки по сети отдает, кроме distributed транслятора конечно. А вот производительность всегда была и остается говном, хоть какой простой сетап не запиливай.

Ceph пробовал последний раз в далеком 2013-м, тогда он делал kernel panic и убивал машину. Думаю с тех пор все сильно лучше стало.

Разумеется, возможно использовать репликацию данных и другими способами, сверху обвесив тем же NFS и keepalived и получить по сути аналогичную систему. Но сейчас очень пользуется популярностью GlusterFS и предлагает легкое развертывание в режиме мультимастеров и простую поддержку, поэтому надо было испробовать данное решение на совместимость, а то, с чем мы столкнулись описано выше. Конечная схема с велосипедами — не идеальное решение, но большая часть людей остановится на варианте работы с гластером через их протокол и в данных велосипедах не будут нуждаться, ну, а если нет, то любые средства хороши, главное получить желаемый результат.

GlusterFS для Kubernetes разворачивается очень просто. Можно даже в контейнеры (1, 2) запихнуть (но лучше на выделенных серверах/ВМ, конечно). А вот в статье да, костыли с велосипедами, еще и не доделали толком.

Много систем отпадало по причине недостаточной документации или избыточности, как Ceph.
Сравнение делалось только с Ceph, который разумеется, производительнее, но и значительно сложнее.
Такую FS даже не встречал. Жаль, что не написали пост о ней, было бы интересно ознакомиться. Но к малоизвестным системам тяги нет, в случае нештатных ситуаций легко можно оказаться без помощи или ждать исправления проблемы долгое время, а в случае FS еще и потерять данные.

1. Да, пожалуй на отказоустойчивость heketi можно забить, т.к. если PVC был создан, то при последующем запуске пода heketi не нужен. Но, если вы внимательно читали пост, а не мимо строк дабы высказать свое мнение, то вы наверняка заметили, что основной проблемой является mount через gluster, которого у нас нет, как и нет возможности его нормально поставить. Вариант в Endpoint наиболее удобный, если нет нужды динамического создания Volume, и я могу сказать, что довольно часто это не нужно. Таким образом человек, который будет это использовать, избавится от кучи лишних прослоек и будет сам управлять своим стораджем. Я не говорю что heketi — то хорошо или плохо, но я считаю что вполне можно обойтись и без него.
2. Разумеется пробовал. И смысл того, что данный вариант не подходит в том, что база heketi должна быть на диске, а значит либо городить еще одно хранилище, или держать его на одной ноде (возможно в рамках одного ДЦ) и это не дает нужной отказоустойчивости. Плюс, хочу заметить, что я не писал что это не возможно, мысль скорее в том, что смысла тащить в кубер его нет.
3. Так отрабатывает таймаут у маунта. Минутный простой в случае падения одной из нод — это не критично. Как я уже говорил, это далеко не эталонное решение, но кто столкнется с проблемой, может использовать и его.
4. Не так как ожидалось, но цель достигнута.

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