А вы это... Скорее всего... Неправильно считаете утилизацию ресурсов в ваших кластерах Kuberentes и даже не подозреваете об этом. (Ну я не подозревал, хотя, скорее всего, просто не задумывался) В чём проблема? Когда у init-контейнеров указаны requests больше, чем у основных контейнеров в поде: 1️⃣ Распределение ресурсов в кластере работает некорректно. 2️⃣ Grafana врёт на графиках утилизации, игнорируя «прожорливые» init-контейнеры. Представьте, что вас есть pod, у которого для initContainer'a в requests указано: resources: requests: cpu: 100m memory: 500Mi А для обычного Container'a что-то типа: resources: requests: cpu: 20m memory: 50Mi Получается для планирования контейнеров pod'a на ноды будут учитываться максимальные реквесты (реквесты initContainer'a) и эти же ресурсы будут "зажаты" pod'ом и Kubernetes Shceduler будет считать, что эти ресурсы недоступны для планирования) Хотя по факту основной контейнер не использует столько ресурсов) Так же Metrics Server при сборе информации о потреблении, лимитов и реквестов ресурсов не учитывает, что указано в initContainer. То есть для такого pod'а kubelet "зажал" 100m и 500Mi, однако в метриках эти ресурсы будут считаться свободными))) (Почитать про это можно тут) Вы можете объективно заявить: "Какой дурак будет делать такие ресурсы для InitContainer'a". А я отвечу: "Да кто угодно, бл*ть". Вот например RabbitMQ оператор этим грешит. (Хотя ребята норм уже одобрили MR, чтобы пофиксить проблему) P.S. В приложенных файлах небольшой Go-скриптец, который пробежится по всему Kubernetes кластеру, который у вас подключен в Kube Context, и подсветит все pod'ы, у которых initContainer реквестит больше, чем основной контейнер. У меня в самом жирном кластере нашлось 2462 таких pod'ов