Столкнулся с интересной проблемой в Kubernetes кластере с Bottlerocket AMI и хочу поделиться находкой.

Изначально ситуация выглядела как классическая проблема с памятью:
1. Растет нагрузка на сервис (новые прожорливые поды)
2. Приложения начинают потреблять больше памяти
3. Происходят OOM киллд шторм, сжирается вся память нод.
4. Ноды падают в not ready, сервис деградирует

Первый этап решения был очевидным - настроить kubelet так, чтобы защитить ноды от падения(выше пример).
Внес изменения, и теперь:
1. Растет нагрузка
2. Приложения едят память
3. Происходят OOM шторм
4. Ноды теперь живы, поды умирают по оомкиллед не убивая ноду - поды убивает кублет.

Вроде бы лучше, но проблемы с сервисом все равно есть.
Включил расширенное логирование, собрал данные за несколько дней и обнаружил реальную причину:
1. Растет нагрузка
2. Приложения едят память
3. OOM киллы убивают поды, ноды живы.
4. Автоскейлер поднимает новые ноды (около 15 секунд)
5. НО! Новые ноды не могут сразу принять поды, потому что сетевой драйвер (CNI) еще инициализируется
"NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"

И вот эта временная яма между "старые поды умерли от ООМкиллд шторма" и "новые ноды еще не готовы из-за долгой инициализации сетевого драйвера" создает провал в работе сервиса. Сраные 11 секунд.

Сейчас исследую два направления решения:
1. Ускорение инициализации сетевого драйвера на новых нодах
2. Упреждающее масштабирование - чтобы новые ноды поднимались заранее, до достижения критической нагрузки

Забавно, как иногда решение одной проблемы просто показывает следующую, более глубокую.
И насколько важно копать глубже очевидных симптомов.

Ниже можно найти окончание истории, проблема была не в этом