Как ищешь причину зависания кода в состоянии Pending в Kubernetes

Когда под зависает в состоянии Pending, я выполняю системную диагностику в следующем порядке:

1. Анализ событий и описания пода:

   kubectl describe pod <pod-name> -n <namespace>
   kubectl get events --all-namespaces --sort-by='.lastTimestamp' | grep -i pending

   В выводе describe ищу секцию Events — там часто сразу указана причина (например, FailedScheduling).

2. Проверка доступности ресурсов кластера:

   • Нехватка ресурсов на нодах: kubectl describe nodes покажет Allocatable CPU/memory. Сравниваю с запрошенными ресурсами пода (kubectl get pod <pod> -o yaml | grep -A 5 resources).
   • Ограничения по лимитам (ResourceQuota) в namespace: kubectl describe namespace <namespace>.

3. Верификация зависимостей пода:

   • PersistentVolumeClaim (PVC): Проверяю, находится ли PVC в статусе Bound.

     kubectl get pvc -n <namespace>
     kubectl describe pvc <pvc-name> -n <namespace>

   • Node Selector / Affinity / Tolerations: Сверяю требования пода (nodeSelector, affinity, tolerations) с метками (labels) и taints нод.

     kubectl get nodes --show-labels
     kubectl describe node <node-name> | grep -i taint

4. Проверка доступности образа (Image): В событиях ищу ошибки типа ErrImagePull или ImagePullBackOff. Проверяю корректность имени образа и доступность в registry.

Типичные причины: нехватка CPU/RAM на нодах, PVC в статусе Pending, несовпадение nodeSelector с метками нод, отсутствие ноды с подходящим toleration для taint, исчерпание квот namespace или лимитов на количество подов.