Кубернетес застрял на создании контейнера

102

Модуль в моем кластере Kubernetes застрял на «ContainerCreating» после запуска создания. Как я вижу журналы для этой операции, чтобы диагностировать, почему она застревает? kubectl logsпохоже, не работает, поскольку контейнер должен находиться в состоянии ожидания.

kubernetes

— four43
источник

kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/… является документацией о возможных этапах. К сожалению, это не включает ContainerCreating...

— Сюн Чямов

Ответы:

128

kubectl describe podsбудет перечислять все события, связанные с модулем, включая извлечение изображений, запуск контейнеров. Это может помочь

— Срикант Потанис
источник

Что делать, если контейнер застрял в ContainerCreating без каких-либо событий? для меня события отображаются как «Нет событий».

— Боб

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

— jwadsack

Это происходит, когда вы используете секреты, а они не найдены (например, опечатка в yaml или вы забыли создать ее раньше). Для почти всех других возможных ошибок он получает состояния CrashLoopback или Error, но с секретами он просто застревает в ContainerCreating. Если вы опишите модуль, то в самом конце вы увидите сообщение о том, что секрет не найден, но он едва говорит ничего о проблеме.

— Даниус

Да, обычно у тебя нет событий до того, как он начинает что-то делать.

— erikbwork

Произошло со мной сегодня утром, и это была опечатка в hostPath для тома. Yay липкая клавиатура.

— Джо Блок

В моем случае доступ докера к интернету был заблокирован. Это было решено с помощью прокси ( используя комментарий sandylss ):

minikube stop
minikube delete
export http_proxy=http://user:pass@ip:port
export https_proxy=http://user:pass@ip:port
export no_proxy=192.168.99.0/24

minikube start --logtostderr --v=0 --bootstrapper=localkube --vm-driver hyperv 
  --hyperv-virtual-switch "Primary Virtual Switch" --docker-env HTTP_PROXY=$http_proxy \
  --docker-env HTTPS_PROXY=$https_proxy --docker-env NO_PROXY=$no_proxy

export no_proxy=$no_proxy,$(minikube ip)
export NO_PROXY=$no_proxy,$(minikube ip)

Затем, чтобы проверить, есть ли у докера доступ к Интернету, запустите:

$ docker pull tutum/hello-world

в кластере (подключиться к кластеру используя minikube ssh); остановите процесс, если начнется загрузка.

Моя вторая проблема была медленное подключение к интернету. Поскольку требуемые образы докеров имеют размер порядка 100 МБ, как контейнеры докеров, так и модули Kubernetes оставались в состоянии \pauseи сохранялись в ContainerCreatingтечение 30 минут.

Чтобы проверить, загружает ли докер изображения, запустите:

$ ls -l /var/lib/docker/tmp

в кластере, который показывает загружаемый временный файл изображения [s], в противном случае - пустой.

Если вы разрабатываете в Minikube и используете VPN, Docker может использовать ваш VPN через Fiddler . То есть докер будет подключен к ip: порту fiddler, а fiddler подключен к VPN. В противном случае VPN не разделяется между вашим хостом и виртуальной машиной Minikube.

— user477273
источник

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

— Джим

Один раз я попал в это, потому что мои объявления о ресурсах были случайно очень маленькими.

ресурсы: ограничения: процессор: 1000 м памяти: 1024 МБ запросы: процессор: 1000 м памяти: 1024 МБ

против

ресурсы: ограничения: процессор: 1000 м памяти: 1024 м запросов: процессор: 1000 м памяти: 1024 м

капитализация этого m делает очень большую разницу в использовании ресурсов. Я застрял на ContainerCreating, потому что я не дал достаточно памяти для моего контейнера.

— Луис Фелипе Моура Перейра Де С
источник