Как отлаживать ошибки Kubernetes «FailedScheduling»

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

Ожидающие поды, вызванные проблемами планирования, обычно не запускаются без ручного вмешательства. Вам нужно будет выяснить основную причину и принять меры по исправлению вашего кластера. В этой статье вы узнаете, как диагностировать и решить эту проблему, чтобы увеличить рабочие нагрузки.

Выявление ошибки FailedScheduling

Поды могут показывать статус Ожидание в течение короткого периода времени после того, как вы добавите их в свой кластер. Kubernetes необходимо запланировать экземпляры контейнера для ваших узлов, и эти узлы должны получить образ из своего реестра. Первым признаком того, что планирование пода не удалось, является то, что он все еще отображается как Ожидание по истечении обычного периода запуска. Вы можете проверить статус, выполнив команду Kubectl get pods:

$ kubectl get pods

NAME        READY   STATUS      RESTARTS    AGE
demo-pod    0/1     Pending     0           4m05s

demo-pod старше четырех минут, но все еще находится в состоянии Pending. Подам обычно не требуется так много времени для запуска контейнеров, поэтому пора приступить к изучению того, чего ждет Kubernetes.

Следующим шагом диагностики является получение истории событий модуля с помощью команды describe pod:

$ kubectl describe pod demo-pod

...
Events:
  Type     Reason            Age       From               Message
  ----     ------            ----      ----               -------
  ...
  Warning  FailedScheduling  4m        default-scheduler  0/4 nodes are available: 1 Too many pods, 3 Insufficient cpu.

История событий подтверждает, что ошибка FailedScheduling является причиной продолжительного состояния Pending. Об этом событии сообщается, когда Kubernetes не может выделить необходимое количество Pod ни одному из рабочих узлов в вашем кластере.

Сообщение события показывает, почему планирование в настоящее время невозможно: в кластере четыре узла, но ни один из них не может взять Pod. У трех узлов недостаточная мощность ЦП, в то время как другой достиг предела количества подов, которые он может принять.

Понимание ошибок FailedScheduling и подобных проблем

Kubernetes может планировать поды только на тех узлах, у которых есть свободные ресурсы. Узлы с исчерпанным объемом ЦП или памяти больше не могут принимать поды. Поды также могут не выполнить планирование, если они явно запрашивают больше ресурсов, чем может предоставить любой узел. Это поддерживает стабильность вашего кластера.

Плоскость управления Kubernetes знает о модулях, уже выделенных узлам в вашем кластере. Он использует эту информацию для определения набора узлов, которые могут получить новый Pod. Ошибка планирования возникает, когда нет доступных кандидатов, в результате чего модуль зависает Pending до тех пор, пока емкость не будет освобождена.

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

• Возможно, администратор оцепил узел, чтобы он не получал новые модули перед техническим обслуживанием.
• Узел может быть заражен эффектом, препятствующим планированию модулей. Ваш Pod не будет принят узлом, если он не имеет соответствующего допуска.
• Возможно, ваш модуль запрашивает hostPort, который уже привязан к узлу. Узлы могут одновременно предоставлять определенный номер порта только одному поду.
• Ваш модуль может использовать nodeSelector, что означает, что он должен быть запланирован для узла с определенной меткой. Узлы без ярлыка не допускаются.
• Соответствие и антисоответствие Pod и Node может быть неудовлетворительным, вызывая конфликт расписания, препятствующий принятию новых Pod.
• В модуле может быть поле nodeName, определяющее конкретный узел для планирования. Pod будет зависать в ожидании, если этот узел отключен или не запланирован.

В обязанности kube-scheduler, планировщика Kubernetes, входит работа с этими условиями и определение набора узлов, которые могут принять новый под. Событие FailedScheduling возникает, когда ни один из узлов не удовлетворяет критериям.

Разрешение состояния FailedScheduling

Сообщение, отображаемое рядом с событиями FailedScheduling, обычно показывает, почему ни один узел в вашем кластере не смог принять Pod. Вы можете использовать эту информацию, чтобы начать решение проблемы. В приведенном выше примере в кластере было четыре модуля, три из которых достигли предела ЦП, а один превысил лимит количества модулей.

Емкость кластера является основной причиной в этом случае. Вы можете масштабировать свой кластер с помощью новых узлов, чтобы решить проблемы с потреблением оборудования, добавив ресурсы, которые обеспечат дополнительную гибкость. Поскольку это также повысит ваши расходы, стоит сначала проверить, есть ли в вашем кластере избыточные поды. Удаление неиспользуемых ресурсов освободит место для новых.

Вы можете проверить доступные ресурсы на каждом из ваших узлов с помощью команды describe node:

$ kubectl describe node demo-node

...
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests     Limits
  --------           --------     ------
  cpu                812m (90%)   202m (22%)
  memory             905Mi (57%)  715Mi (45%)
  ephemeral-storage  0 (0%)       0 (0%)
  hugepages-2Mi      0 (0%)       0 (0%)

Поды на этом узле уже запрашивают 57% доступной памяти. Если новый Pod запросит для себя 1 Gi, узел не сможет принять запрос на планирование. Мониторинг этой информации для каждого из ваших узлов может помочь вам оценить, не становится ли ваш кластер избыточным. Важно иметь свободную емкость на случай, если один из ваших узлов выйдет из строя и его рабочие нагрузки придется перенести на другой.

При сбое планирования из-за отсутствия планируемых узлов в событии FailedScheduling отображается сообщение, подобное следующему:

0/4 nodes are available: 4 node(s) were unschedulable

Узлы, которые не планируются из-за того, что они были оцеплены, будут включать SchedulingDisabled в поле статуса:

$ kubectl get nodes
NAME       STATUS                     ROLES                  AGE   VERSION
node-1     Ready,SchedulingDisabled   control-plane,master   26m   v1.23.3

Вы можете отключить узел, чтобы он мог получать новые поды:

$ kubectl uncordon node-1
node/node-1 uncordoned

Когда узлы не огорожены и имеют достаточно ресурсов, ошибки планирования обычно вызываются заражением или неправильным полем nodeSelector в вашем поде. Если вы используете nodeSelector, убедитесь, что вы не сделали опечатку и что в вашем кластере есть поды с указанными вами метками.

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

$ kubectl taint nodes node-1 demo-taint=allow:NoSchedule

Измените манифесты ваших подов, чтобы они могли планироваться на узле:

spec:
  tolerations:
    - key: demo-taint
      operator: Equal
      value: allow
      effect: NoSchedule