Добрый день! Как использовать один и тот же PersistenceVolume для хранения логов нескольких микросервисов? У меня микросервисы начали перезаписывать логи друг у друга, так как PV ссылается на одну папку. А создовать новый PV для каждого микросервиса мне не очень нравится..

Graylog не идёт?

Динамический провизионинг через PVC?

не совсем понимаю что это значит, но PV ссылается только в одну директорию и по моему пониманию для того чтобы изменить это надо создать новый PV. В этом случаел возникает еще вопрос - Для чего тогда нужен PVC?

Graylog не идёт?

не слыхал даже))

я бы все равно перед грейлогом в файл складировал

не совсем понимаю что это значит, но PV ссылается только в одну директорию и по моему пониманию для того чтобы изменить это надо создать новый PV. В этом случаел возникает еще вопрос - Для чего тогда нужен PVC?

Когда админы заколебались создавать сотни PV руками, придумали динамический провизионинг. Но народ тебе намекает что тебе надо в другую сторону. Собирать логи некой системой и хранить в ней

Когда админы заколебались создавать сотни PV руками, придумали динамический провизионинг. Но народ тебе намекает что тебе надо в другую сторону. Собирать логи некой системой и хранить в ней

а как собирать логи? логи у меня создаются микросервисами в докере, написанный на java, в директории томката

вот прям щас храни логи в файлах, которые называются как хостнейм пода.

это костыльный и кривой подход

правильный - это слать их в stdout

и далее уже докер их складывает в файлы или в journald

откуда система твоя централизованная система сбора логов будет их в одно место отправлять

И делать редирек в цент хранилище....

Graylog

ELK - еластик кибана и на выбло fluentbit, filebeat

почитай

правильный - это слать их в stdout

Если не работает - можно сайдкарт

Тот же флюент в под подсадить. Он будет просить лог из файла и отдавать куда надо

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

Господа, кто советует ELK, а вы сравнивали это решение с clickhouse?

Господа, кто советует ELK, а вы сравнивали это решение с clickhouse?

Да

Clickhouse для хранения логов - это сырой полуфабрикат

Почему?

К тому же, ёлка предоставляет все необходимое - репликация, шарды, кибана

В КХ ты будешь это все руками делать

Господа, кто советует ELK, а вы сравнивали это решение с clickhouse?

да, КХ сделан полусырым из говна и палок, но быстрым а елка это ынтырпрайз с тем же привкусом говна )

Почему?

добро пожаловать в срач "нужен ли FTS в логах"!

коллеги. а кто сталкивался с проблемами при разворачивании через кубадм ? Если дать кластеру имя domain.ru, а в зоне есть вайлд-кард запись *.domain.ru - то kubeadm join не работает, кубадм за каким-то шлет запросы на адрес из этой вайлдкард записи, и игнорит все что прописано в /etc/hosts

почитай

спасибо почитаю. значит PV, PVC не для хранения логов микросервисов предназначены значит?

спасибо почитаю. значит PV, PVC не для хранения логов микросервисов предназначены значит?

Абсолютно точно, что нет

да, КХ сделан полусырым из говна и палок, но быстрым а елка это ынтырпрайз с тем же привкусом говна )

И что из этого следует ?

И что из этого следует ?

что выбирать нужно на свой вкус, кек

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

Т.е. 💩💩💩💩😱

Что нужно сказать связке istio + fluentd + elasticsearch, чтобы в elasticsearch летети не только логи взаимодействия сервисов и подов, но и самих приложений в подах?

Привет, с rbac тут разбираюсь, подскажите, пожалуйста, у меня есть clusterrolebinding: https://i.imgur.com/4K0Zi3R.png Тут кластер роль биндится к какой-то группе - system:masters - что это за группа и как посмотреть кто в этой группе?

Clickhouse для хранения логов - это сырой полуфабрикат

Это LogHouse от Flant? Я смотрл - что-то активности на гитхабе долго нет. Умер похоже

Это LogHouse от Flant? Я смотрл - что-то активности на гитхабе долго нет. Умер похоже

Для быстрого старта - норм, сами использовали первое время loghouse. Но не очень удобный, с efk не сравнится, алертов нет.

Кто-нибудь знает способ смены ip у сервиса kubernetes (ну который для доступа к api внутри кластера)? Хочу, чтобы поды стучались сразу на нормальный ip мастера, но не понимаю, можно ли вообще где-то это настроить

а что такое "нормальный ip мастера"?

Кто-нибудь знает способ смены ip у сервиса kubernetes (ну который для доступа к api внутри кластера)? Хочу, чтобы поды стучались сразу на нормальный ip мастера, но не понимаю, можно ли вообще где-то это настроить

Можно руками его вписать, выбрав любой из clusterCIDR.

--kubernetes-service-node-port походу флаг мне нужен. Короче говоря простой кластер, 1 мастер. Clusterip для сервисов моих не используется вообще, итого у меня щас 2 сервиса в кластере - апи и днс. Ну и хочу попробовать и их победить :)

--kubernetes-service-node-port походу флаг мне нужен. Короче говоря простой кластер, 1 мастер. Clusterip для сервисов моих не используется вообще, итого у меня щас 2 сервиса в кластере - апи и днс. Ну и хочу попробовать и их победить :)

Осторожно! Не победи здравый смысл в своих походах.

опять переизобретают k3s, чтобы принципиально распределенную систему сделать принципиально локальной

Когда 1 мастер распределять-то нечего, отсюда и интерес. Или ты про то, что для сервисов clusterip: none? Эт потому что envoy тестирую как lb для сервисов

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

Не понял, но попробую объяснить. Хочу изучить балансировку, нашел envoy, выглядит интересно. Прикрутил как-то, изучаю, удобно или нет его использовать в моих кейсах. Попутно вышло, что если сделать kubectl get service -A - там с ip висит всего 2 сервиса. Стало интересно, можно ли и их перестроить. В процессе возник вопрос, я его тут озвучил, т.к сходу не нагуглил. По-моему изучать поведение системы вот так намного полезнее, чем сидеть на попе ровно, дожидаясь аварий, а потом впопыхах че-то читать и крутить. Поэтому параллельно работе придумываешь какие-то такие задачки себе, пробуешь решить и попутно узнаешь о внутренностях больше

Начните с чтения документации.

Аварий можно не дожидаться. Chaos engineering

и работать станет веселее

для начала стоит разобраться чем ingress от service отличается. и понять что это совершенно разные вещи.

https://kubernetes.io/docs/concepts/services-networking/service/

для начала стоит разобраться чем ingress от service отличается. и понять что это совершенно разные вещи.

Я знаю, что разные, причем тут вообще ingress?

> Хочу изучить балансировку, нашел envoy, выглядит интересно. вот при чем.

> Хочу изучить балансировку, нашел envoy, выглядит интересно. вот при чем.

Я ж не говорил, что я его как ингресс использую

а как что ?

Как loadbalancer для своего приложения. Короче с точки зрения куба он просто еще одно приложение. Как ингресс его использовать как-то чересчур. Заманчиво задействовать его как сущность куба loadbalancer, но я так понял что это нифига непросто, готового решения не вижу

Велосипедостроение, велосипедостроение всюду.

Я видел что есть ингресс ambassador на базе envoy, может быть в итоге я к нему приду. Но мне кажется странным гонять трафик от всех приложений через ингресс и назад в кластер

Как loadbalancer для своего приложения. Короче с точки зрения куба он просто еще одно приложение. Как ингресс его использовать как-то чересчур. Заманчиво задействовать его как сущность куба loadbalancer, но я так понял что это нифига непросто, готового решения не вижу

а почему обычные service не хочешь использовать ??

А хочешь вывернуть их наизнанку ?

Может быть. А как красиво и без велосипедов сделать, чтобы вот есть у меня 3 приложения-api, ну и там сайт, еще мобильные всякие клиенты у этих апи. И надо вполне типичные вещи: если умер инстанс приложения (авария или деплой новой версии не суть) - чтоб балансер сам переотправил запрос, дабы клиенты не видели никаких 500ых вообще, чтобы балансировать при необходимости с весами можно было... сущность сервиса сама по себе так круто не умеет. А использовать ингресс для взаимодействия приложений внутри кластера выглядит странным, имхо тоже велосипедный костыль. Но может я неправ?

Может быть. А как красиво и без велосипедов сделать, чтобы вот есть у меня 3 приложения-api, ну и там сайт, еще мобильные всякие клиенты у этих апи. И надо вполне типичные вещи: если умер инстанс приложения (авария или деплой новой версии не суть) - чтоб балансер сам переотправил запрос, дабы клиенты не видели никаких 500ых вообще, чтобы балансировать при необходимости с весами можно было... сущность сервиса сама по себе так круто не умеет. А использовать ингресс для взаимодействия приложений внутри кластера выглядит странным, имхо тоже велосипедный костыль. Но может я неправ?

Взаимодействия внутри через сервисы

Может быть. А как красиво и без велосипедов сделать, чтобы вот есть у меня 3 приложения-api, ну и там сайт, еще мобильные всякие клиенты у этих апи. И надо вполне типичные вещи: если умер инстанс приложения (авария или деплой новой версии не суть) - чтоб балансер сам переотправил запрос, дабы клиенты не видели никаких 500ых вообще, чтобы балансировать при необходимости с весами можно было... сущность сервиса сама по себе так круто не умеет. А использовать ингресс для взаимодействия приложений внутри кластера выглядит странным, имхо тоже велосипедный костыль. Но может я неправ?

Ты 500-ки ловил при отваливании подов, балансируемых сервисами, или это просто предположение?

Я попадал на поды, которых уже нет

Iptables ж не мгновенный

Да, 99.9 запросов ок, но хочется все 100. Опять же iptables как сделает circut breaking?

Может быть. А как красиво и без велосипедов сделать, чтобы вот есть у меня 3 приложения-api, ну и там сайт, еще мобильные всякие клиенты у этих апи. И надо вполне типичные вещи: если умер инстанс приложения (авария или деплой новой версии не суть) - чтоб балансер сам переотправил запрос, дабы клиенты не видели никаких 500ых вообще, чтобы балансировать при необходимости с весами можно было... сущность сервиса сама по себе так круто не умеет. А использовать ингресс для взаимодействия приложений внутри кластера выглядит странным, имхо тоже велосипедный костыль. Но может я неправ?

Я думал сервис отправляет запрос в деплоймент который жив

Oh, shi...

Но readyness пробу с какой-то переодичностью дергают

Я думал сервис отправляет запрос в деплоймент который жив

Деплой-то жив, в нем поды обновляются на новую версию по одному. А правила iptables обновляются не предварительно ведь, а запаздывая слегка

Но readyness пробу с какой-то переодичностью дергают

вот-вот, только ретраи

Деплой-то жив, в нем поды обновляются на новую версию по одному. А правила iptables обновляются не предварительно ведь, а запаздывая слегка

Не обязательно же по 1

Можно политику обновлений описать самому

И это обсуждали кстати

Не обязательно же по 1

Какая разница по сколько? Суть ведь в том, что сначала что-то изменится, а потом iptables правила новые заедут

И мы не получаем 100% доступность

А зачем учить ретраям все мои приложения, если можно научить какое-то приложение-балансировщик и пускать все через него?

Какая разница по сколько? Суть ведь в том, что сначала что-то изменится, а потом iptables правила новые заедут

Если вначале поднимать новый под, разве не будет ок?

Или канарейка какая нибудь

Если вначале поднимать новый под, разве не будет ок?

Наверное. Ну куб поднимает поды... ну, как умеет. На это как-то можно влиять?