Наша формула "что-то" "где-то" "как-то" приобретает очертания.
ПОД не проходит проверку лайвнес/рединесс пробы, меняет состояние на нод реди, его IP адрес удаляется из endpoints и ресолв перестаёт работать для ДРУГИХ сервисов по его имени service.
Пилим второй алёрт, чтобы детектировать (ну не буду же я постоянно сидеть с этой проблемой или ждать гневного письма босса).
- alert: DAPR_ibanni_2
expr: |-
kube_pod_status_ready{condition!="true", exported_namespace!="velero"} > 0
and on (pod, exported_namespace, cluster)
kube_pod_annotations{annotation_dapr_io_enabled="true"}
for: 30s
labels:
severity: critical
annotations:
summary: "DAPR. No route to `{{ $labels.cluster }}`/`{{ $labels.exported_namespace }}`/`{{ $labels.pod }}`"
Тут я отсеял велеро, который за каким-то рожном сюда попадал и я просто отфильтровал его, даже не хочу и 0.0001мс тратить на траблшутинг ещё и велеро.
Теперь у нас есть два алёрта, которые как минимум мне просигнализируют раньше пользователей и коллег, что у нас беда.
Уходим на обед.
.
..
...
"
Тревога, тревога, волк унес зайчат!" - кричит мне слак и я бегу с кухни в кабинет.Попался, дапр тебя подери.
Вижу ситуацию, пишу коллегам в слак "
всё под контролём, Алекс всё знает и чинит уже".А проба не проходит, вот да, видимо по ивентам, по дескрайбу, по стейту.
В некоторых случаях есть даже рестарты, exit code НЕ 137/OOM - для ДРУГИХ подов с похожей проблемой.
А что в логах? А в логах у нас ничего.
Лезем к разработчикам, смотрим, что там dotnet и включаем debug левел прям для dev стенда, а что вы мне сделаете.
Уходим допивать чай.
.
..
...
Спустя время снова алёрт.
Методом метрик понимаем, что в целом проблема с 1-2 приложениями в кубере, они как бы core часть и к ним по servicename лезут другие приложения и если этот падает или недоступен - лежит весь продукт.
Уже есть логи и мы видим, что в логах у нас
outofmemory.То есть не на уровне kubelet/кубера, а на уровне приложения внутри.
Смотрим в графане CPU/Memory usage, фильтруем по имени деплоймента и видим исторически, что все без исключения ПОДы текут по памяти как барышни на концерте Энрике Иглесиаса.
Пишем разработке "мы вроде нашли проблему, у нас память течёт".
Они снимают дамп(а я не умею(((( и научится не успел, они сняли раньше) и уходят на перекур.
Спустя пару часов выкатывают фикс, несколько часов тестирования, смотрим по метрикам - всё ок.
Проходит ещё 1-2 дня и жалобы заканчиваются, алёртов тоже нет.
Проблема, при которой не работал ресолв, решилась.
Что было: приложение текло по памяти, ничего не писало в логи, его не убивали по ООМ, он просто переставал работать. Некорректные настройки liveness probes позволяли ему 503-ть при пробах, он переходил в not ready, его IP адрес пропадал из Endpoint k8s, переставал ресолвится по service имени, весь продукт падал.
Сейчас всё ок.
Количество реплик больше 1 на конкретно данном приложении сделать нельзя, оно не масштабируется, и даже стратегия там ReCreate. Ну вот такое приложение. Это не ко мне вопрос. Только 1 реплика.
Касательно "почему на некоторые поды не добавлялся сайдкар" у меня ответа нет, но алерт есть и при случае я потраблшутю и его.
Итоги.
Виноват ли был тут дапр?
Нужно ли мне было лезть в логи оператора или инжектора?
Стоит ли бесится от кастомного ингресса?
А я всё ещё не знаю, мне хватило и того, что саму проблему я починил.
Не знаю и всё. Может дапр и хорош. Может я просто дурак и не так копал изначально.
Может разработчики негодяи.
Может я просто деревня и мог бы сразу догадаться что не так.
Не догадался. Пришлось нырнуть и хорошенько разобраться.
Из плюсов:
- узнал про эту технологию
- написал лонгрид о чём я думаю в такие моменты и как работает моя голова
- очередной раз доказал самому себе, что стартовать траблшутинг с нейронки не стоит, она бы 10000% завела бы меня не туда. Потом пользоваться можно, но не со старта.
- починили приложение и всё начало работать стабильно
Минусы:
- опять потратил куча времени, никто не оценит человеко-часы таких погружений