Pull to refresh

Comments 13

Спасибо за гайд. Заинтересовала функциональность мониторинга:
1) идет ли он по умолчанию или это дополнительная услуга?
2) правильно ли я понимаю что все дашборды для мониторинга k8s уже настроены?
3) как долго храняться метрики?

Мониторинг входит и в Commuinty Edition и в данном руководстве модули мониторинга также включены по умолчанию (сравнение редакций по модулям). Все дашборды уже тоже настроены, да. Но можете докинуть своих.

Настройка retention в модуле prometheus:

Prometheus Stack ставиться через helm одной командой и включает в себя Grafana. Мониторинг из коробки для ванильного кубера.

Что такое "мгновенное автомасштабирование" у Deckhouse? Horizontal Pod Autoscaler?

Ingress у Deckhouse работает через HostNetwork?

Есть такое понятие - цельность инструмента. Тут именно про это история. Есть центральный модуль для входа, автопровизионинг dashboards. Соответственно модули установлены с определённым списком настроек, которые спускаются сверху-вниз.

То, что это реально сделать самому - спору нет. Однако зачем, если есть готовое?

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

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

Возможно у вас был какой-то неудачный опыт? Поделитесь?

А можете подробнее про проблемы с идемпотентностью в Deckhousе? В каком-то случае вам ее не хватило? Сейчас (начиная с версии 1.41) даже конфигурация вся может лежать в гите в виде ресурсов.

По поводу установки - установка возможна не обязательно на чистую машину. Можно установить также в существующем кластере какого-либо managed-решения или обычном существующем кластере. В managed-кластерах буду некоторые ограничения, т.к. не доступно управление control-plane, но в остальном никаких отличий. Вы можете довольно легко перебраться с Deckhouse из managed-решения к другому провайдеру или вообще на bare metal с air gap-окружением.

тестировал в июле. выбирал какой из вариантов управления кластера развивать далее в закрытых инфраструктурах.

по итогам - на машину которую ранее использовал в кластере(сделал reset node и все) ничего не встало. человек который общался с представителями deckhouse и собственно предложил его использование сказал что необходима чистая виртуалка...

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

еще один огромный минус - бывает часто необходимо поменять конфигурацию кластера(с лету два простейших примера - cni и его настройки, путь к файловой системе docker и настройки docker), а как это сделать с deckhouse не всегда понятно - все под капотом и не все документировано. ждать ответа от разработчиков? - зачастую нет времени на это.

это пожалуй два основных фактора - не идемпотентен + не прозрачен. на данный момент раскатываю кластер ansible скриптами - тоже не идеально, но там я хотя бы пожертвовав бессонной ночью могу все запустить(а вот вы сказали что REDOS не поддерживаете, а мне понадобилось и поставил поправив пару скриптов).

Спасибо за резвернутый ответ.
Deckhouse постоянно развивается. Например сейчас поддерживается работа с РЭД ОС, AlterOS и Астрой, и список будет пополняться.
Будем рады если как-нибудь попробуете еще разок.

По поводу глубокого тюнинга настроек можно сказать, что некоторые штуки Deckhouse намеренно не дает крутить, некоторыми рулит сам. Таким образом заложена частичка опыта работы на большом количестве инсталляций и в разных окружениях. Это балансирование между стабильностью работы и допустимой глубиной конфигурирования всегда будет кого-нибудь ограничивать :)

Спасибо за фидбэк!

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

если это соответствует действительности - нет, не попробую еще раз...

Это требование актуально для установки Deckhouse на bare metal. Сервер (ВМ) не нужно как-то особенно настраивать — Deckhouse развернет кластер и все настроит сам (в том числе узлы), в соответствии с конфигурацией. Добавление узла сейчас происходит через сгенерированный скрипт, который настраивает узел. В будущем процесс добавления узла в такой инсталляции будет еще проще.

Если устанавливать Deckhousе в существующий кластер, то такого требования конечно нет. К установке в облаках это конечно тоже не относится.

простая ситуация - при первой установке(bare metal) что-то пошло не так(да хоть машину кто-то по случайности ребутнул) и придется накатывать чистую ВМ(а это от 3х дней может занять пока до поставленной задачи доберется отдел выделяющий ВМ)? ведь неизвестно что конкретно настраивает Deckhouse, что надо удалить чтобы повторить процедуру установки? хотя бы в части docker(хотя непонятно что еще помимо docker). а если уже после настройки кластера придется изменить какие-либо параметры - получается он не сможет просто поставить поверх старого новый. а что будет если мы вдруг потеряем всех мастеров - все ВМ кластера выделять и настраивать с 0?

огромное значение имеет ias - т.е. возможность восстановить кластер из любого состояния за 5-10 мин. что пока что выглядит невозможным.

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

Sign up to leave a comment.