Тупости и лени пост.
Иногда бывает такое, что кластер обновился, развалился, автоматически секьюрити апдейтнулся(аригато, Azure), руками апгрейднулся(аригато, AWS, за принудительно-добровольные апгрейды, иначе денег-денег-денег дай).
Всё тоже самое, но с релизами приложений.
Выбрать любое.
После этого события у нас иногда сразу многое не работает и прилетает куча разных алёртов, ошибок, миллион ивентов.
Побуду бесплатным адвокатом AWS, такое крайне редко, чаще в Azure проблемы.
Проблема: в моменте не очень понятно - а куда вообще смотреть, чего чинить первым?
1) Я сразу по заранее сохранённой ссылке в
alertmanager, где стоит фильтр по кластеру(ам) и, иногда severity.Фильтр
cluster=~".*prod.*"Ссылка формата
+ есть аналог дашборда в графане, но по привычке лезу сразу в
alertmanager.Grafana красивее, нагляднее и удобнее, но привычка дело такое.
Тут ничего для всех нового, но алертов СЛИШКОМ много. Надо как-отфильтровать последнее.
2) Иду в кластер(ы) и одним махом очищаю всё, что мне помешает Быстрой диагностике.
Да, я знаю потенциальные последствия, на 100% их понимаю, что делают команды.
У меня есть алиасы формата
alias kkndp="k delete pod --field-selector 'status.phase!=Running' -A --force"
alias kkndj="kubectl delete jobs --all-namespaces --field-selector status.successful=0"
Я прям иногда ввожу
kkndp && kkndj в шелле.Что это даёт мне:
- все подвисшие/unknown/комплетед/файлед и так далее поды уходят в небытие и мне просто глазами визуально удобнее следить/чинить то, что надо, а не что исторически не релевантно
- все файлед джобы от кронджобов подчищаются и перестают лететь тонны алертов о незавершенных джобах.
Цель: быстро избавить визуальное пространство от "мусорных" исторических алертов и failed объектов, чтобы быстрее найти и починить главное и актуальное.
3) При необходимости смотрю ивенты, с фильтром по времени и не нормал северити
alias kwe="k get events -A --sort-by='.metadata.creationTimestamp' | grep -v Normal"
4) Снова иду в графану/алертменеджер, смотрю, что осталось(обычно 90-95% шума улетает сразу) и чиню релевантное оставшееся.
Минусы подхода должны быть очевидны опытным инженерам и совсем не очевидны для начинаюших специалистов.
Для никому не нужной интриги минусы под спойлер.
- если у нас не собираются где-то все ивенты и логи, то мы теряем историю и причины, почему был failed, unknown, crashloopback etc. Если всё логируется, то пофиг, разве что exit code/reason мы не увидим(а оно нам надо? итак видно, что кластер обновился).
- если у нас есть velero (https://velero.io/), то есть не иллюзорный шанс проетерять потенциальные бекапы. Например POD velero висел в pending, ожидая ресурсов(или иная причина), а я его убиваю.
Значит бекап, который должен был запуститься, будет запущен при следующем расписании. А сейчас его не будет.
В пендинге он может висеть, например, потому что разом запустилось по расписанию 100500 подов бекапа и упираемся(временно) в количество PVC/disk на ноде/нехватка нод во время апдейта.
Спустя время это проходит, но мои действия потенциально убивают штатный бекап.
С велеро я беру все риски на себя, осознавая, что он скоро (пере)запуститься и бекап будет готов. Так же у нас есть алерты по велеро, так что мне ок.
Возможно стоит переделать алиасы, добавив xargs и добавив в игнор велеро, но пока руки не дошли.
Да и не так часто такие ситуации бывают.