Релиз, новый обработчик отчётов не стартует: в событиях
Insufficient cpu. Соседний Pod той же мощности работает, реальная загрузка низкая.Планировщик сравнивает с
allocatable узла сумму requests назначенных ему Pod, а не фактическое потребление. Pending при уже назначенном узле — ожидание запуска. Назначение видно по spec.nodeName; Pod в очереди на назначение запросы на конкретном узле ещё не занимает.kubectl describe node node-a
kubectl top pod -n reportsВымышленный узел с
allocatable 2000m: занято 1750m, новый Pod просит 500m — сумма 2250m строго больше, отказ ожидаем. При равенстве проходит только проверка CPU.Здесь один обычный контейнер на Pod, без Init/sidecar, overhead, Pod-level requests и незавершённого resize; все системные Pod учтены.
Развилка: событие дословно, запросы на узле по всем namespace, реальное потребление при доступном Metrics API.
Insufficient cpu не доказывает низкую загрузку и не содержит гарантированных чисел.Ошибка — повышать квоту или
limits: при заданных requests это не устраняет нехватку по учёту. Новый подходящий узел может помочь. resizePolicy управляет перезапуском при изменении ресурсов, а не освобождает requests. Снижать запрос по одному снимку нагрузки нельзя.Развилку учёта ресурсов сохраняем для разбора Kubernetes при подготовке обучения в УЦ ФОРС.
#Kubernetes #DevOps #УЦФОРС
VK | Телеграм | Сайт