Kubernetes Deployment / Pod / Контейнерные статусы - PullRequest
6 голосов
/ 17 октября 2019

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

В любом случае, главный вопрос - это различия между всеми статусами капсул. И когда я говорю Статусы , я имею в виду столбец Статус при запуске kubectl get pods. Рассматриваемые статусы:

- ContainerCreating
- ImagePullBackOff
- Pending 
- CrashLoopBackOff 
- Error 
- Running 

Что заставляет контейнер / контейнер переходить в эти состояния? Для первых четырех статусов можно ли восстановить эти состояния без взаимодействия с пользователем? Какой порог для CrashLoopBackOff? Является ли Running единственным статусом, который имеет Ready Condition Истины? Любая обратная связь будет принята с благодарностью! Кроме того, было бы плохой практикой использовать kubectl в автоматическом сценарии для целей мониторинга? Например, каждую минуту регистрировать результаты kubectl get pods в Elasticsearch?

Ответы [ 2 ]

1 голос
/ 17 октября 2019

Подробную информацию о жизненном цикле модуля можно найти в документации по k8s . Рекомендуемый способ мониторинга кластера и приложений kubernetes с Прометей

0 голосов
/ 23 октября 2019

Я попытаюсь рассказать, что я вижу скрытым за этими условиями

  • ContainerCreating

Отображение, когда мы ожидаем загрузки изображения и контейнер будет создандокер или другая система.

  • ImagePullBackOff

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

  • Ожидание

Контейнер запускается (если запуск занимает время) или запускается, но произошла ошибка redinessProbe.

  • CrashLoopBackOff

Этот статус отображается, когда перезапуск контейнера происходит слишком часто. Например, у нас есть процесс, который пытается прочитать несуществующий файл и происходит сбой. Затем контейнер будет воссоздан Kube и повторен.

  • Ошибка

Это довольно ясно. У нас есть несколько ошибок для запуска контейнера.

  • Работает

Все в порядке, контейнер работает, и livenessProbe в порядке.

...