#kubernetes #devops #sre

TLDR: это не пост с решением.
Скорее пост-размышление с очередным внутренним вопросом, на который я сам себе так и не ответил.


Прилетает алерт.
Смотрю чо там.
У него метрика простая:
kube_node_status_condition{condition="DiskPressure",status="true"} == 1
Полез смотреть - да, реально диска не хватает.

Дальше вопрос на минуту:
а чем именно забито? Логами? Эфемерными томами подов? Или это имаджи?
Смотрим ещё одну метрику:
kubelet_image_garbage_collected_total{reason="space"}

Счётчик прыгнул вверх ровно в момент алерта.
Всё, картина ясна: раздел на 200 гигов забился старыми образами (очень частые релизы, по гигалион раз в день), кублет сам это увидел, сам почистил, алерт потух.

Красота же?
Сработало как задумано: от NodeHasDiskPressure до NodeHasNoDiskPressure прошло 8 минут, ни одной ручной команды.

Но вот дальше я сижу и не понимаю, что с этим делать дальше.
В голову приходит несколько вариантов:
- увеличить диск
Поможет? Да, отодвинет проблему во времени. Но это буквально плата за то, чтобы не думать. И мы вроде не резинового бюджета контора, чтобы просто лупать гигабайты, потому что "так спокойнее".

- подвинуть трешхолды гарбаджколлектора *
стояло:

image-gc-high-threshold-percent = 85
image-gc-low-threshold-percent = 80

Много это или мало - а хуй знает.
Может, надо 60/65, чтобы чистка начиналась заранее и мы вообще не долетали до disk pressure. Может вообще поставить 40%, лол.
А может это сделает только хуже - кублет начнёт чиститься чаще, будет чаще передёргивать пул подов, которые сейчас пуллят образ.
Кстати да, у меня был страх - а не удалит ли гарбаджколлектор образ, который прямо сейчас используется живым контейнером?
По идее нет, не удалит, вроде кублетовский image GC чистит только то, что не занято ни одним запущенным контейнером. Но осадочек "а что если" всё равно остался, потому что документация - это одно, а современный вайбкод, даже в кубере, это другое.

- моё любимое - забить болт 😎
Формально всё ок: алерт мигнул и потух сам, никакого даунтайма. Disk pressure - это не баг, это фича, механизм ровно для этого и придуман.

- вырубить нахер этот алерт?
Да вроде тупость. Тогда зачем я его добавлял.

- поменять алерт, чтобы была проверка "вот тоже самое, но длительностью больше 15 минут"
Вроде звучит логично, фолс-позитив будет пропущен, но могу и упустить реальную катастрофу.

- менять северити на инфо?
А если это реальная трабла?

Вот и хер знает что делать в таких ситуациях.
Диск бесконечно раздувать - не вариант, это деньги в никуда. Трешхолды крутить - можно, но на каких цифрах остановиться - не знаю, беру их из головы, а не из какой-то формулы. Забить - вроде тоже можно, работает же.
Тюнить алерт конечно хорошо, но хз.

После появления нейронок спрашивал и у них.
Они охуеть как уверенно дают советы, но если копнуть источники, то иногда они ссылаются на статьи индусов, а если дальше копнуть и почитать эти и другие статьи у них, то там просто жопа начинает гореть от "логики" и экспертизы. Воздержусь, пожалуй.

Так и не знаю, какой из путей правильный.
Подозреваю, что правильного ответа тут вообще нет, есть только свой уровень принятия риска и адаптация к счёту за EBS

- - -
* Кстати я не помню, надо гуглить, а точно ли эти метрики, это случаем не эвикшн менеджер дергает триггер на imagefs.available<15%?
Или один трешхолд запускает чистку, а другой двигает метрику диск прешр?
Надо читать.