Для каждого деплоя делать коммит и пуш очень не хочется
Но вам же нужно собрать контейнер, для того чтобы задеплоить. И тут билдсервер может лучше подходить для данной задачи, как минимум из-за доступных ресурсов, и ширины канала. При «правильно» настроенном CICD, коммитнуть и увидеть результат уже задеплоенным, будет быстрее, чем делать это локально с последующим ручным запуском.
что мы в целом настоятельно рекомендуем не перезаписывать историю после пуша без крайней необходимости и уведомления всех.
Тут кажется, что вам нужно сменить ваш gitflow. Изменять историю в «статичных» ветках типа master/develop, нужно запретить, сделав их protected. Разработчикам нужно пользоваться фича ветками. И когда работа готова, менять историю (вероятно речь про склейку коммитов) и делать пул/мерж реквесты в те самые ветки. Так история будет всегда читаемой и не будет конфликтов у разработчиков.
Смысл заведения пользователей каждому разработчику есть когда разработчики работают с кластером самостоятельно напрямую
Тут скорее имелось ввиду, что разработчики иногда пытаются попасть с контейнер, чтобы выполнить там ту или иную консольную команду. Ну и попав в кластер, могут получить некий доступ, который им не был предназначен. Оставить какие либо не «хорошие» артефакты. Вот это и нужно логировать.
64 bytes from 8.8.8.8: icmp_seq=463 ttl=36 time=225748.941 ms
64 bytes from 8.8.8.8: icmp_seq=464 ttl=36 time=225995.845 ms
64 bytes from 8.8.8.8: icmp_seq=465 ttl=36 time=225507.014 ms
64 bytes from 8.8.8.8: icmp_seq=466 ttl=36 time=224767.075 ms
64 bytes from 8.8.8.8: icmp_seq=467 ttl=36 time=225016.392 ms
Ок, допустим мы можем править конфиг каждой OSD, но тогда мы всё равно лишаемся удобства Rook.
Согласен, но теперь вся конфигурация лежит под гитом в yaml файлах. Да, я понимаю, что у вас скорее всего так же, только с использованием ansible(?). Я своим сообщением хотел донести, что конфигурировать можно и это не проблема.
VPA по сути костыль. Концепт «давайте больше ресурсов поду, пока он не начнет влезать» — по сути ничем не отличается от безлимитного пода.
Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.
Допустим у вас одинаковая конфигурация серверов под ceph и под kubernetes + Rook
Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.
У Rook есть и свои проблемы, как например сложности дебага ceph демонов при проблемах.
Да, я немного слукавил, когда сказал, что разницы нет. Конечно же она есть и она не маленькая. В случае с rook, нужно понимать как работает OS и CEPH так в нагрузку еще и Kubernetes + ROOK. Я ни в коем случае не пропогандирую отказ от класического ceph'а и переход на rook. Я говорю, что в ряде случаев, есть смысл его использовать. Да, в первое время может быть больно, просто нужно отдавать отчет в своих действиях.
Пример: 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 кластеров… (тут я умышленно не заканчиваю предложение)
Без опции, трафик будет проксироваться на локальный порт, указанный в deployment или при запуске telepresence. Если запускать telepresence в нескольких экземлярах без опции --docker-run, то нужно следить за пересечением портов
Но вам же нужно собрать контейнер, для того чтобы задеплоить. И тут билдсервер может лучше подходить для данной задачи, как минимум из-за доступных ресурсов, и ширины канала. При «правильно» настроенном CICD, коммитнуть и увидеть результат уже задеплоенным, будет быстрее, чем делать это локально с последующим ручным запуском.
Тут кажется, что вам нужно сменить ваш gitflow. Изменять историю в «статичных» ветках типа master/develop, нужно запретить, сделав их protected. Разработчикам нужно пользоваться фича ветками. И когда работа готова, менять историю (вероятно речь про склейку коммитов) и делать пул/мерж реквесты в те самые ветки. Так история будет всегда читаемой и не будет конфликтов у разработчиков.
Такое лучше совсем не разрешать)
Тут скорее имелось ввиду, что разработчики иногда пытаются попасть с контейнер, чтобы выполнить там ту или иную консольную команду. Ну и попав в кластер, могут получить некий доступ, который им не был предназначен. Оставить какие либо не «хорошие» артефакты. Вот это и нужно логировать.
когда работаешь удалёоонноооо
Согласен, но теперь вся конфигурация лежит под гитом в yaml файлах. Да, я понимаю, что у вас скорее всего так же, только с использованием ansible(?). Я своим сообщением хотел донести, что конфигурировать можно и это не проблема.
Про VPA спорный вопрос. Если у вас выделенный кластер под ceph, то вы вероятно его не ограничиваете. Если кластер для ceph и приложений общий, то VPA и POD PRIORITY могут с играть решающую роль в работе всего кластера.
Обязательно напишем статью, в ближайшее время, на тему возможностей конфигурирования rook.
Да, я немного слукавил, когда сказал, что разницы нет. Конечно же она есть и она не маленькая. В случае с rook, нужно понимать как работает OS и CEPH так в нагрузку еще и Kubernetes + ROOK. Я ни в коем случае не пропогандирую отказ от класического ceph'а и переход на rook. Я говорю, что в ряде случаев, есть смысл его использовать. Да, в первое время может быть больно, просто нужно отдавать отчет в своих действиях.
Так давно переделали на statefulset. Для каждой OSD есть свой configmap и никто не мешает поправить какие то параметры конкретно для той самой OSD. Скейл в ноль любую osd и восстанавливай в ручном режиме.
Любые параметры в rook можно задать через configmap.
А если не использовать rook, ceph у вас на тех же железках, что и kubernetes? Если да, то скорее всего вы имеете те же проблемы. В плане подбора ресурсов в kubernetes, можно и нужно использовать VPA.
Не совсем понятно, почему для кластера ceph и rook по умолчанию рассматриваете разную конфигурацию серверов. Это не проблема rook!
PS: В целом, вы описываете проблемы, которые преследуют rook точно так же как и ceph.
Так же, есть ощущение, что рассматривается одна из старых версий rook.
PPS: С одной стороны, rook упрощает работу с ceph, с другой стороны усложняет. Да, ceph сам по себе не прост в эксплуатации, но если мы (все мы, сообщество) не будем пользоваться подобными инструментами, они не будут развиваться. Возможно, сейчас для многих, rook будет сильно избыточен. Но вы попробуйте поддерживать 3-4 десятка небольших ceph кластеров… (тут я умышленно не заканчиваю предложение)