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

я подумал что графана тупит, пошел в promql, взял метрику по памяти, и там нет в лейблах пода который существовал ранее
делаю вывод что метрики старых подов не сохраняются\удаляются

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

Ну у каждого докер контейнера в кубе автоматически проставляется метадата типа названия пода, неймспейса и т.д. В лейблах контейнера кажется.

если его сейчас нет, то он не отдаст по лейблу, надо на график в прометее пеереключится, или через апи запрашивать рейндж дат

Если уже тру, значит можно из journald забрать rsyslog-ом и отправить на внешний rsyslog-сервер

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

Ну докеру всё равно нужно явно указать какие конкретно лейблы нужно добавлять логи, а они могут быть очень разные

у кого-то лейбл app, у кого-то лейбл name, например, нужно перечислить все возможные

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

в графане они точно должно отображаться, если там нормальный тайм рейндж

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

графана просто отображает то что ей дают, и она как и прометей не видит удаленные поды

если это не трабла кубера пойду тогда в церковь чтоли

эт не кубер

Привет всем! Не могу найти никаких конкретных аргументов против развертывания SQL серверов в statefulset. Однако нахожу множество каких-то предостережений без упоминания конкретных причин сбоев. У кого был какой-то опыт неудачного использования в statefulset (или наоборот удачного) или есть информация о том где конкретно получается слабое звено в этом случае отпишитесь плиз. Спасибо.

в самой идее ничего плохого нет, проблема в том что оно трогает кучу вещей - и все они должны быть настроены. В https://github.com/hjacobs/kubernetes-failure-stories есть куча историй, когда мелкая деталь всё ломает, например endpoints не обновляются во время

Коллеги, столкнулись тут с одной хренью, может кто-то уже решал.

Есть приложение в 16 кубике, приложенеи стейтлесс из 24 подов (это SPA фронт, с SSR, если кому интересно будет). Хрень проявляется во время деплоя новой версии: пока идет деплой, пользуны регулярно получают всяие 500, Плохие ворота, таймауты и прочий треш. Покопались, по всему получается, что когда под из старого релиза начинает убиваться, то он не сразу вылетает из сервиса, и ингресс какое-то время еще пихает ему запросы, хотя внутри уже шатдаун во всю и запросы эти новые никто не обрабатывает.

Что можно с этим сделать?

Привет) переводили серию статей на эту тему. статья, которая тебя заинтересует - https://habr.com/ru/company/nixys/blog/490380/

спс, сейчас покурим