Блог

Главная - Вопросы по программированию - Причины сбоя состояния модуля

Причины сбоя состояния модуля

#kubernetes #kubelet #kube-controller-manager

#kubernetes #kubelet #kube-контроллер-менеджер

Вопрос:

Если состояние модуля равно Failed , Kubernetes попытается создать новые модули, пока не достигнет terminated-pod-gc-threshold in kube-controller-manager . В результате в кластере останется много Failed модулей, которые необходимо очистить.

Существуют ли другие причины, кроме Evicted того, что вызовет Pod Failed ?

Комментарии:

1. Что kubectl describe pod NAME говорит? Пожалуйста, добавьте вывод к вашему вопросу. Правильно ли настроены проверки работоспособности модуля? Можете ли вы показать их конфигурацию?

2. @John Я не видел других причин, кроме Evicted тех, которые вызывают Pod Failed , и хочу знать, есть ли другие причины: D

3. О, так это скорее теоретический вопрос?

4. Да, я хочу знать, видел ли кто-нибудь причины, отличные от Evicted тех, которые вызывают Pod Failed .

Ответ №1:

Может быть много причин для состояния POD FAILED . Вам просто нужно проверить наличие проблем (если таковые существуют), выполнив команду

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

Внимательно проверьте EVENTS раздел, в котором перечислены все события, произошедшие во время создания модуля. Надеюсь, вы сможете точно определить причину сбоя оттуда.

Однако существует несколько причин сбоя модуля POD, некоторые из них следующие:

  • Неправильный образ, используемый для модуля.
  • В модуль передаются неправильные команда / аргументы.
  • Kubelet не удалось проверить работоспособность модуля (т. Е. Сбой проверки работоспособности).
  • Модуль не прошел проверку работоспособности.
  • Проблема в сетевом плагине CNI (неправильная конфигурация плагина CNI, используемого для работы в сети).

Например:

модуль вышел из строя из-за ошибки извлечения изображения

В приведенном выше примере не удалось извлечь изображение «not-so-busybox», поскольку оно не существует, поэтому модуль НЕ удалось запустить. Состояние модуля и события четко описывают проблему.

Ответ №2:

Просто сделайте это:

 kubectl get pods <pod_name> -o yaml

И в выходных данных, ближе к концу, вы можете увидеть что-то вроде этого:

введите описание изображения здесь

Это даст вам хорошее представление о том, где именно произошел сбой модуля и что произошло.

Ответ №3:

Модули не выдержат сбоев планирования, сбоев узлов или других удалений, таких как нехватка ресурсов или в случае обслуживания узла. Модули не должны создаваться вручную, но почти всегда с помощью контроллеров, таких как развертывания (самовосстановление, репликация и т.д.).

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

 kubectl describe pod <pod_name>

Другие ситуации, с которыми я столкнулся при сбое модуля:

  • Проблемы с изображением (больше не существует)
  • Когда модуль пытается получить доступ, например, к ConfigMap или секретам, но он не найден в пространстве имен.
  • Сбой проверки работоспособности
  • Постоянный том не удается смонтировать
  • Ошибка проверки

Кроме того, удаление основано на ресурсах — Политика выселения

Это также может быть вызвано истощением узла / модуля. Вы можете прочитать об утечке здесь.