На кластере есть свободная фактическая память, но новая реплика не запускается из-за нехватки ресурсов. Как планировщик принимает такое решение?
Планировщик обычно принимает решение по запрошенным ресурсам контейнера, а не по его текущему фактическому потреблению. Если сумма уже размещённых запросов и запроса новой реплики превышает доступный планировщику объём узла, реплика не будет назначена, даже когда мониторинг показывает свободную память.
Такой подход появился из-за необходимости предсказуемо размещать рабочие нагрузки в общем кластере. Фактическое потребление приложений меняется со временем, поэтому планирование только по текущим метрикам могло бы привести к переполнению узла и взаимному влиянию сервисов.
Запросы ресурсов дают планировщику консервативную гарантию: при размещении подов учитывается заранее заявленная минимальная потребность. Это отделяет решение о размещении от кратковременных колебаний нагрузки.
Предположим, на узле осталось немного свободной памяти по данным мониторинга, но уже размещённые поды суммарно заявили больший объём ресурсов. Если планировщик разрешит новую реплику, ориентируясь только на фактическое потребление, несколько приложений могут одновременно увеличить нагрузку.
Последствиями станут вытеснение подов, аварийное завершение процессов из-за нехватки памяти или нестабильность всего узла. Обратная ситуация тоже возможна: завышенные запросы приводят к неэффективному использованию кластера и ошибочному впечатлению, что в нём нет места.
При размещении пода планировщик проверяет, помещаются ли его requests в доступный для планирования ресурс узла. Доступность оценивается относительно allocatable-ресурсов узла, а не относительно показания свободной памяти в данный момент.
Limits задают верхнюю границу потребления, но сами по себе обычно не определяют, может ли под быть размещён. Если request не задан, платформа может использовать значения по умолчанию через политики namespace или считать запрос равным нулю; это не означает, что приложение безопасно для совместного запуска.
Когда фактическое потребление ниже requests, часть ресурсов остаётся незарезервированной с точки зрения размещения. Поэтому запросы должны отражать реалистичную потребность, а не только среднее значение. Слишком маленькие requests повышают плотность размещения, но увеличивают риск конкуренции и вытеснения; слишком большие requests улучшают предсказуемость, но снижают утилизацию и могут вызвать преждевременное масштабирование кластера.
Для диагностики нужно сопоставить состояние пода, причину отказа планировщика, requests уже размещённых подов и allocatable узлов. Метрики фактического потребления полезны для подбора значений, но не заменяют проверку параметров, на которых основано решение планировщика.
В кластере наблюдалась низкая фактическая загрузка памяти, но новые реплики фонового сервиса оставались в состоянии ожидания. Выяснилось, что requests каждой реплики были рассчитаны по пиковому значению и существенно превышали обычное потребление.
Рассматривались два варианта. Можно было просто уменьшить requests: это повысило бы плотность размещения, но создало бы риск нехватки памяти при одновременном росте нагрузки. Другой вариант — добавить узлы: он сохранял запас производительности, но увеличивал постоянные расходы.
Выбрали пересмотр requests по историческим метрикам с отдельным запасом для пиков и настроили автоматическое добавление узлов при невозможности размещения подов. В результате планировщик получил более реалистичные данные, обычная загрузка кластера выросла, а пиковые периоды стали покрываться масштабированием без ручного вмешательства.
Вопрос: Почему свободная память на графике не гарантирует возможность разместить новый под?
Ответ: График обычно показывает фактическое потребление, тогда как планировщик сравнивает requests подов с allocatable-ресурсами узлов. Часть ресурса может быть уже зарезервирована запросами, хотя в данный момент не используется. Кроме того, размещение может быть запрещено не только ресурсами, но и другими ограничениями: taints, affinity, узловыми селекторами или портами.
Вопрос: Что произойдёт, если requests сильно занижены относительно реального пикового потребления?
Ответ: Планировщик разместит больше подов, чем узел устойчиво выдерживает при нагрузке. При дефиците памяти ядро или агент управления контейнерами может завершить процессы, а платформа начнёт вытеснять поды согласно их приоритету и качеству обслуживания. Поэтому низкие requests улучшают плотность только номинально и должны проверяться по пиковым метрикам и поведению при конкуренции.
Вопрос: Почему увеличение limits без увеличения requests не решает проблему невозможности планирования?
Ответ: Планировщик использует requests как обязательную потребность пода при принятии решения. Увеличение только limits меняет допустимый максимум потребления уже размещённого пода, но не добавляет узлу планируемой ёмкости и не гарантирует размещение. Если поду действительно нужен больший гарантированный объём, соответствующий request должен быть увеличен, после чего может потребоваться масштабирование или перераспределение узлов.