Комментарии 32
Идея выглядит интересно, но какие-то практические кейсы для применения внутри k8s/openshift придумать сложно окромя:
— CI/CD для ceph
— k8s/openshift без персистентного стораджа
Пример: OSD падает сыпя ошибками себе под ноги. Вы подозреваете, что проблема в одном из параметров в конфиге, хотите поменять конфиг для конкретного демона, но не можете, потому что у вас kubernetes и DaemonSet.
Сложность последовательного поднятия OSD
Так давно переделали на statefulset. Для каждой OSD есть свой configmap и никто не мешает поправить какие то параметры конкретно для той самой OSD. Скейл в ноль любую osd и восстанавливай в ручном режиме.
Однако ceph содержит более 1000 параметров для настройки, в тоже время через rook мы можем править лишь меньшую часть из них.
Любые параметры в rook можно задать через configmap.
И тут вам придется попотеть с тестами производительности. В случае занижения лимитов вы получите медленный кластер, в случае выставления unlim вы получите активное использование CPU при ребалансе, что будет плохо влиять на ваши приложения в kubernetes.
А если не использовать rook, ceph у вас на тех же железках, что и kubernetes? Если да, то скорее всего вы имеете те же проблемы. В плане подбора ресурсов в kubernetes, можно и нужно использовать VPA.
Проблемы с сетевым взаимодействием v1
Не совсем понятно, почему для кластера ceph и rook по умолчанию рассматриваете разную конфигурацию серверов. Это не проблема rook!
PS: В целом, вы описываете проблемы, которые преследуют rook точно так же как и ceph.
Так же, есть ощущение, что рассматривается одна из старых версий rook.
PPS: С одной стороны, rook упрощает работу с ceph, с другой стороны усложняет. Да, ceph сам по себе не прост в эксплуатации, но если мы (все мы, сообщество) не будем пользоваться подобными инструментами, они не будут развиваться. Возможно, сейчас для многих, rook будет сильно избыточен. Но вы попробуйте поддерживать 3-4 десятка небольших ceph кластеров… (тут я умышленно не заканчиваю предложение)
* пусть у ceph X параметров, каждый параметр принимает N значений, т.е. кол-во конфигураций X^N
* пусть у k8s Y параметров, у каждого M значения, т.е. кол-во конфигураций Y^M
если это две параллельные системы, то X^N * Y^M
если это одно встроено в другую, то (Y*X^N)^M. т.е. сложность конфигурирования системы будет расти по экспоненете(если точнее то X^M)
Любые параметры в rook можно задать через configmap.
Ок, допустим мы можем править конфиг каждой OSD, но тогда мы всё равно лишаемся удобства Rook.
А если не использовать rook, ceph у вас на тех же железках, что и kubernetes? Если да, то скорее всего вы имеете те же проблемы. В плане подбора ресурсов в kubernetes, можно и нужно использовать VPA.
Если у вас выделенные железки под ceph, то перед их покупкой вы обычно считаете capacity кластера и подбираете железо под нагрузку.
VPA по сути костыль. Концепт «давайте больше ресурсов поду, пока он не начнет влезать» — по сути ничем не отличается от безлимитного пода.
Не совсем понятно, почему для кластера ceph и rook по умолчанию рассматриваете разную конфигурацию серверов. Это не проблема rook!
Допустим у вас одинаковая конфигурация серверов под ceph и под kubernetes + Rook
2х10гб. В случае ceph я просто в конфиге прописываю через какой линк ходит служебный трафик, а через какой клиентский.
А теперь расскажите мне пожалуйста как вы проделаете этот фокус с распределением линков в Rook?
PS: В целом, вы описываете проблемы, которые преследуют rook точно так же как и ceph.
Так же, есть ощущение, что рассматривается одна из старых версий rook.
У Rook есть и свои проблемы, как например сложности дебага ceph демонов при проблемах.
Ок, допустим мы можем править конфиг каждой OSD, но тогда мы всё равно лишаемся удобства Rook.
Согласен, но теперь вся конфигурация лежит под гитом в yaml файлах. Да, я понимаю, что у вас скорее всего так же, только с использованием ansible(?). Я своим сообщением хотел донести, что конфигурировать можно и это не проблема.
VPA по сути костыль. Концепт «давайте больше ресурсов поду, пока он не начнет влезать» — по сути ничем не отличается от безлимитного пода.
Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.
Допустим у вас одинаковая конфигурация серверов под ceph и под kubernetes + Rook
Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.
У Rook есть и свои проблемы, как например сложности дебага ceph демонов при проблемах.
Да, я немного слукавил, когда сказал, что разницы нет. Конечно же она есть и она не маленькая. В случае с rook, нужно понимать как работает OS и CEPH так в нагрузку еще и Kubernetes + ROOK. Я ни в коем случае не пропогандирую отказ от класического ceph'а и переход на rook. Я говорю, что в ряде случаев, есть смысл его использовать. Да, в первое время может быть больно, просто нужно отдавать отчет в своих действиях.
Согласен, но теперь вся конфигурация лежит под гитом в yaml файлах. Да, я понимаю, что у вас скорее всего так же, только с использованием ansible(?). Я своим сообщением хотел донести, что конфигурировать можно и это не проблема.
Без разницы какой системой управления конфигурации я раскатываю ceph — в любом случае это гибче и надежнее, чем Rook.
Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.
VPA и ограничение кластера по ресурсам в зависимости от политики или вынесет вам payload из кластера kubernetes или зарежет ceph, что приведет к его ООМ и опять таки выносу или тормозам вашего payload в кластере kuberentes. Но опять таки это вопрос сложности capacity planing.
Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.
Я с удовольствием почитаю, только пожалуйста не забудьте рассказать о сетевом взаимодействии и разделением по линкам.
Да, в первое время может быть больно, просто нужно отдавать отчет в своих действиях.
Пока я вижу только боль, повышенные риски и никих преимуществ перед классическим ceph.
и удивляются что кто то такое тащит в серьезный продакшин.
А почему вас интересует их мнение? Да и что тут можно сказать еще, сверх многократно сказанного, что ceph — сырой и непригоден в продакшн, и долго еще не будет, не рассчитывайте на бесплатное, дороже выйдет, используйте нормально работающие решения с поддержкой.
Но тогда зачем такой ceph?
Что-нибудь изменилось за последние полгода? Вроде бы rook стал уметь работать с внешним ceph
Расшифруйте, пожалуйста, мысль. Что является неверной идеей? Делать нечто типа hci на базе кубернетеса? Или пытаться управлять внешним стореджем через дRook? Последнее, кстати, не выглядит таким уж и идиотизмом. Люди же пишут операторы, чтобы создавать записи во внешних БД, или взять тот же ингресс — там помимо ограниченного количества ручек для управления через аннотации есть ещё и возможность вставлять полноценные сниппеты кода в формате, котором ожидает сам nginx
поймите почему они впереди всех
поймите почему они не используют внешнее хранилище
почему идея с ceph сырое, и будет сырым еще долго
Это не аргументы, а хвалебная песнь в пользу Нутаникса.
И, да, мне он понравился, но по определенные вещи у них очень даже сырые.
Касательно HCI — это вообще очень интересная история, т.к. "one size doesn't fit all", а попытка всех засунуть в одну платформу (типа Нутаникса) выглядит как натягивание совы на глобус. И сова иногда… рвется.
Интересно, какие?
кубер, терраформовский провайдер (хотя спасибо уже за то, что он есть), там еще штука была для баз данных — забыл как называется. Ну, и вообще там в нутаниксе есть штука, которая позволяет из него сделать такой вот ЦУ для управления разными облаками с каталогом приложений на базе блюпринтов — тоже какая-то очень сомнительная штука, да еще и с баш-портянками внутри.
Я думал вы и правда что-то интересное нашли.
А что я смогу сказать более конкретного и интересного чем то, что Вы уже знаете? Что вычислительная нагрузка бывает разная? И если облако навызявает стандартный набор конфигураций, то в нутаниксе можно творить беспредел и аллоцировать, например, мало процов на много памяти, а потом удивляться почему это часть ресурсов недоиспользуется. Но эта проблема будет характерна для любого пула ресурсов…
И я вполне честно сказал, что определенные вещи у них сырые, а не "платформа дрянная".
Если пользователь хочет выстрелить себе в ногу, то довольно хлопотно помешать ему это сделать. Но я не успеваю за скачками ваших мыслей, какое это имеет отношение к обсуждаемой теме, что ceph как HCI непригоден для продакшна сегодня, в середине осени 2019 года (в отличие от, допустим, большинства коммерческих HCI)?
что ceph как HCI непригоден для продакшна сегодня, в середине осени 2019 года
Так чего это Вы у меня спрашиваете? Вот коллега awsswa59
выше утверждал, что
что может поменяться если изначально стратегия не правильная?
С этого все и началось ) а расшифровать свою мысль он не удосужился. Ну, и вообще — тот же ceph, если взялись за него — нужно правильно варить. Не уверен, что есть подходящие компетенции у малых и средних компаний. Вспомним, сколько факапов было с ceph.
Хорошо. Ваши предложения, если нужно хранилище на от 200ТБ до 20ПБ? Не специализированное вроде HDFS, а более-менее универсальное. OpenStack нет. Чего делать?
К тому же ведь есть возможность использовать его не внутри, как HCI, а вынести наружу, как отдельную сущность — при этом сложность эксплуатации никуда не девается, но по крайней мере глупые ошибки сложнее сделать
Он вам не дRook