Облачная платформаAdvanced

Что делать, если Pod не удалось выгнать?

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Принцип выселения

Когда узел находится в ненормальном состоянии, Kubernetes будет выселять некоторые pods на узле, чтобы обеспечить доступность нагрузки.

В Kubernetes как kube-controller-manager, так и kubelet могут выселять pods.
  • Выселение, реализованное kube-controller-manager

    kube-controller-manager состоит из нескольких контроллеров, а выселение реализовано node controller. Node controller периодически проверяет статус всех узлов. Если узел находится в состоянии NotReady в течение определённого времени, все pods на узле будут выселены.

    kube-controller-manager поддерживает следующие параметры запуска:
    • pod-eviction-timeout: указывает интервал, в течение которого узел недоступен, после чего pods на этом узле выселяются. Интервал по умолчанию — 5 минут.
    • node-eviction-rate: указывает количество узлов, выселяемых в секунду. Значение по умолчанию — 0.1, что означает, что pods выселяются с одного узла каждые 10 секунд.
    • secondary-node-eviction-rate: задаёт скорость выселения узлов второго уровня. Если в кластере отключено большое количество узлов, скорость выселения будет снижена до secondary-node-eviction-rate. Значение по умолчанию — 0.01.
    • unhealthy-zone-threshold: задаёт порог, при котором AZ считается нездоровой. Значение по умолчанию — 0.55, что означает, что если доля неисправных узлов в AZ превышает 55 %, AZ будет считаться нездоровой.
    • large-cluster-size-threshold: задаёт порог, при котором кластер считается большим. Параметр по умолчанию — 50. Если количество узлов превышает этот порог, кластер считается большим. Если более 55 % узлов в кластере неисправны, скорость выселения снижается до 0.01. Если кластер небольшой, скорость выселения снижается до 0, что означает, что pods, работающие на узлах кластера, не будут выселяться.
  • Выселение, реализованное kubelet

    Если ресурсы узла исчерпываются, kubelet применяет политику выселения, основываясь на приоритете pod, использовании ресурсов и запросе ресурсов. Если у pods одинаковый приоритет, первым будет выселен pod, который использует наибольшее количество ресурсов или запрашивает их больше всего.

    kube-controller-manager выселяет все pods на неисправном узле, тогда как kubelet выселяет некоторые pods на неисправном узле. kubelet периодически проверяет ресурсы памяти и диска узлов. Если ресурсов недостаточно, он выселит некоторые pods в зависимости от приоритета. Подробную информацию о приоритете выселения pod см. в Pod selection for kubelet eviction.

    Существуют мягкие пороги выселения и жёсткие пороги выселения.
    • Soft eviction thresholds: Для ресурсов узла настроен период ожидания. kubelet будет освобождать ресурсы узла, связанные с этими порогами, если период ожидания истечёт. Если использование ресурсов узла достигает этих порогов, но опускается ниже их до истечения периода ожидания, kubelet не будет выселять pod‑ы на узле.

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

      • eviction-soft: указывает мягкий порог выселения. Если eviction signal узла достигает определённого порога, например, memory.available<1.5Gi, kubelet не будет немедленно выселять некоторые pod‑ы на узле, а подождёт период ожидания, настроенный параметром eviction-soft-grace-period. Если порог был достигнут после истечения периода ожидания, kubelet выселит некоторые pod‑ы на узле.
      • eviction-soft-grace-period: указывает период ожидания выселения. Если pod достигает мягкого порога выселения, он будет завершён после истечения настроенного периода ожидания. Этот параметр указывает разницу во времени, в течение которой завершающийся pod реагирует на достижение порога.
      • eviction-max-pod-grace-period: указывает максимальный допустимый период ожидания, используемый при завершении pod‑ов в ответ на достижение мягкого порога выселения.

    • Hard eviction thresholds: Pod‑ы выселяются немедленно, как только эти пороги достигаются.

      Вы можете настроить жёсткие пороги выселения, используя следующие параметры:

      eviction-hard: указывает жёсткий порог выселения. Когда eviction signal узла достигает определённого порога, например, memory.available<1Gi, то есть когда доступная память узла менее 1 ГиБ, выселение pod‑а будет инициировано немедленно.

      kubelet поддерживает следующие значения по умолчанию для жёстких порогов выселения:
      • memory.available<100Mi
      • nodefs.available<10%
      • imagefs.available<15%
      • nodefs.inodesFree<5% (for Linux nodes)

    kubelet также поддерживает другие параметры:
    • eviction-pressure-transition-period: указывает период, в течение которого kubelet должен ждать перед переходом из состояния давления выселения. Значение по умолчанию — 5 минут. Если время превышает порог, узел переводится в DiskPressure или MemoryPressure. Затем некоторые pod'ы, работающие на узле, будут выселены. Этот параметр может предотвратить ошибочные решения о выселении, когда узел колеблется выше и ниже мягкого порога выселения в некоторых случаях.
    • eviction-minimum-reclaim: указывает минимальное количество ресурсов, которое должно быть освобождено при каждом выселении. Этот параметр может предотвратить повторные выселения pod'ов kubelet'ом, когда при выселении pod'ов освобождается лишь небольшое количество ресурсов в некоторых случаях.

Определение неисправности

Если pod'ы не выселяются при неисправности узла, выполните следующие действия для определения причины неисправности:

После выполнения следующей команды вывод показывает, что многие pod'ы находятся в состоянии Evicted.

 
kubectl get pods

Результаты проверки будут записаны в журналы kubelet узла. Вы можете выполнить следующую команду для поиска информации:

cat /var/log/cce/kubernetes/kubelet.log | grep -i Evicted -C3

Устранение неполадок

Проблемы здесь описаны в порядке их вероятности возникновения.

Проверяйте эти причины одну за другой, пока не найдёте причину неисправности.

Пункт проверки 1: Находится ли узел под нагрузкой ресурсов

Если узел испытывает нехватку ресурсов, kubelet изменит node status и добавит taints к узлу. Выполните следующие действия, чтобы проверить, существует ли соответствующий taint на узле:

 
$ kubectl describe node 192.168.0.37
Name:               192.168.0.37
...
Taints:             key1=value1:NoSchedule
...
Table 1 Состояния узлов с нехваткой ресурсов и решения

Node Status

Taint

Eviction Signal

Description

MemoryPressure

node.kubernetes.io/memory-pressure

memory.available

Доступная память на узле достигает порогов выселения.

DiskPressure

node.kubernetes.io/disk-pressure

nodefs.available, nodefs.inodesFree, imagefs.available or imagefs.inodesFree

Доступное дисковое пространство и inode на корневой файловой системе или файловой системе образа узла достигают порогов выселения.

PIDPressure

node.kubernetes.io/pid-pressure

pid.available

Доступный идентификатор процесса на узле ниже порогов выселения.

Пункт проверки 2: Настроены ли Tolerations для рабочей нагрузки

Используйте kubectl или найдите строку, содержащую целевую рабочую нагрузку, и выберите More > Edit YAML в столбце Operation, чтобы проверить, настроена ли toleration для рабочей нагрузки. Подробности см. в Taints and Tolerations.

Пункт проверки 3: Выполнены ли условия для прекращения выселения Pod

В кластере с менее чем 50 рабочими узлами, если количество неисправных узлов составляет более 55 % от общего числа узлов, выселение pod будет приостановлено. В этом случае Kubernetes не будет пытаться выселять рабочую нагрузку с неисправного узла. Подробности см. в Rate limits on eviction.

Пункт проверки 4: Совпадают ли выделенные ресурсы Pod с ресурсами узла

Выселенный pod будет часто планироваться на исходный узел.

Возможная причина

Pod'ы на узле выселяются на основе использования ресурсов узла. Выселенные pod'ы планируются на основе выделенных ресурсов узла. Выселение и планирование основаны на разных правилах. Поэтому выселенный контейнер может быть снова запланирован на исходный узел.

Решение

Правильно выделяйте ресурсы каждому контейнеру.

Пункт проверки 5: Постоянно ли происходит сбой Pod рабочей нагрузки и её повторный деплой

Pod рабочей нагрузки постоянно сбоит и повторно деплоится.

Анализ

После того как pod будет выгнан и запланирован на новый узел, если pods в этом узле также выгнаны, pod будет выгнан снова. Pods могут быть выгнаны многократно.

Если pod выгнан kube-controller-manager, он будет находиться в состоянии Terminating. Этот pod будет автоматически удалён только после восстановления узла, на котором расположен контейнер. Если узел был удалён или не может быть восстановлен по другим причинам, вы можете принудительно удалить pod.

Если pod выгнан kubelet, он будет находиться в состоянии Evicted. Этот pod используется только для последующего поиска неисправностей и может быть удалён напрямую.

Решение

Выполните следующую команду для удаления выгнанных pod'ов:

 
kubectl get pods -n <namespace> | grep Evicted | awk '{print $1}' | xargs kubectl delete pod -n <namespace>

В предыдущей команде \u003cnamespace\u003e указывает имя пространства имён. Настройте его в соответствии с вашими требованиями.

Ссылки

Kubelet не удаляет выгнанные pods
Родительская тема: Workload Exception Troubleshooting
Предыдущая статья
Что делать, если запуск Pod не удался?
Следующая статья
Что делать, если Storage Volume не может быть смонтирован или монтирование завершается тайм‑аутом?
Поддержка Юридические документы Политика конфиденциальности
© 2026 Cloud.ru