Поды в Kubernetes могут находиться в состоянии Pending, в чем проблема

Диагностика состояния Pending у Pod в Kubernetes

Состояние Pending у Pod в Kubernetes — это индикатор того, что Pod был принят системой (запланирован в API), но не может быть запущен на одном из узлов кластера. Это не ошибка в прямом смысле, а скорее симптом, указывающий на то, что для запуска контейнера не выполнены необходимые условия. Проблема может быть связана с различными компонентами кластера и требует системного подхода к диагностике.

Основные причины состояния Pending

• Нехватка ресурсов на узлах (Insufficient Resources): Наиболее частая причина. Kubernetes Scheduler не может найти узел, удовлетворяющий запросам Pod по CPU и памяти (requests), или в кластере физически недостаточно ресурсов.

  # Пример: Pod запрашивает 2 CPU, но на всех узлах доступно меньше
  resources:
    requests:
      memory: "1Gi"
      cpu: "2"
  

• Отсутствие подходящего узла по селекторам Node Selector / Node Affinity: Pod имеет правила привязки к узлам, но в кластере нет узлов, соответствующих этим правилам.

  # Пример: Pod требует узел с label `disktype=ssd`, но таких нет
  spec:
    nodeSelector:
      disktype: ssd
  

• Проблемы с PersistentVolumeClaim (PVC): Если Pod использует постоянное хранилище (PersistentVolume), он будет ждать в Pending, пока соответствующая PVC не перейдет в статус Bound. Это может быть вызвано:

    *   Отсутствием подходящего PersistentVolume (PV) по размеру или режиму доступа.
    *   Некорректным StorageClass (например, `storageClassName: non-existent`).
    *   Проблемами с внешним CSI-драйвером (например, в облачном провайдере).

• Taints и Tolerations: На узлах могут быть установлены taints (метки-«загрязнения»), которые Pod не может переносить (toleration). Scheduler просто игнорирует такие узлы.

  # Проверка taints на узлах
  kubectl describe node <node-name> | grep Taint
  

• Достигнут лимит ресурсов (ResourceQuota): В Namespace может быть установлена квота, и создание нового Pod превысит лимит по CPU, памяти или количеству Pod-объектов.

• Проблемы с образом контейнера (ImagePullBackOff): Хотя Pod часто быстро переходит в состояние ImagePullBackOff или ErrImagePull, изначально он может быть Pending, пока kubelet пытается скачать образ. Причины: неверное имя образа, отсутствие прав на приватный registry, проблемы сети.

• Проблемы с планировщиком (Scheduler): Редко, но возможны сбои в работе самого kube-scheduler (например, недостаточно прав, аварийное завершение).

Пошаговая диагностика

Для эффективного поиска причины выполните следующие команды:

1. Детальное описание Pod: Основной источник информации.

   kubectl describe pod <pod-name> -n <namespace>
   

    Ищите секции **Events** в конце вывода. Там будут сообщения от Scheduler вида `0/X nodes are available: 1 Insufficient cpu, 2 node(s) didn't match Pod's node affinity`.

1. Проверка ресурсов кластера:

   # Просмотр доступных ресурсов на узлах
   kubectl describe nodes | grep -A 10 "Allocatable"
   # Или используйте
   kubectl top nodes
   

2. Проверка статуса PVC:

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

3. Анализ квот Namespace:

   kubectl describe quota -n <namespace>
   

4. Проверка логики планировщика (для сложных случаев): Можно использовать kubectl events для фильтрации или включить более подробное логирование в Scheduler.

Пример решения проблемы

Допустим, kubectl describe pod показывает: 0/3 nodes are available: 1 Insufficient memory, 2 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.

Решение:

• Insufficient memory: Увеличить лимиты памяти на узлах, уменьшить requests для Pod или добавить в кластер новые узлы.
• Taint disk-pressure: Это автоматический taint, который kubelet добавляет при нехватке места на диске. Нужно очистить место на указанных узлах (логи, неиспользуемые образы). Не рекомендуется добавлять toleration на этот taint в Pod, так как это может привести к сбоям работы.

Вывод: Состояние Pending — это важный сигнал от планировщика Kubernetes. Его анализ через kubectl describe является первым и самым важным шагом в диагностике. Проблема почти всегда кроется не в самом Pod, а в его окружении: политиках кластера, доступности ресурсов или конфигурации зависимостей (таких как хранилище). Системный подход к проверке ресурсов, меток узлов, taints и статусов PVC позволяет быстро локализовать и устранить причину.