Почему поды в Kubernetes находятся в состоянии Pending

Что проверяют

Умеете ли вы диагностировать, а не перечислять причины по памяти. Pending означает «под принят, но ещё не запущен», и ценность ответа в том, с чего вы начинаете выяснение, а не в длине списка.

Как отвечать

Сначала инструмент: kubectl describe pod и события в конце вывода. Планировщик пишет причину дословно и с разбивкой по узлам: сколько отсеялось по нехватке процессора, сколько по taint, сколько по affinity. Дальше смотрят события кластера, описание узлов и состояние PVC.

Типовые причины:

• не хватает ресурсов под requests. Планировщик считает сумму запросов уже размещённых подов, а не фактическую загрузку узла, поэтому свободная память в мониторинге ничего не доказывает;
• на узлах taint, а у пода нет соответствующего toleration;
• nodeSelector, affinity или правила распределения по зонам невыполнимы: подходящего узла просто нет;
• том не привязан: нет подходящего PV, класс хранилища ждёт первого потребителя, диск в другой зоне;
• квота namespace или LimitRange отвергают под;
• автоскейлер не добавляет узел: достигнут потолок группы либо под не влезает целиком ни в один тип узла.

Где спотыкаются

Путают Pending и ContainerCreating. Отсутствующий Secret или ConfigMap не мешает планированию: под уже назначен на узел и висит на создании контейнера, а причину пишет kubelet, а не планировщик.

Лечат симптом, срезая requests до символических значений. Под запустится, но узел окажется переподписан, и вместо Pending вы получите вытеснение по памяти и деградацию соседей.

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