Kubernetes - Pod остается в состоянии создания контейнера
Я новичок во всех вещах Kubernetes, так что еще есть чему поучиться.
Создали двухузловой кластер Kubernetes, и оба узла (основной и рабочий) готовы выполнять работу, которая хороша:
[monkey@k8s-dp1 nginx-test]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-dp1 Ready master 2h v1.9.1
k8s-dp2 Ready <none> 2h v1.9.1
Кроме того, все Бобы Kubernetes выглядят хорошо:
[monkey@k8s-dp1 nginx-test]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system etcd-k8s-dp1 1/1 Running 0 2h
kube-system kube-apiserver-k8s-dp1 1/1 Running 0 2h
kube-system kube-controller-manager-k8s-dp1 1/1 Running 0 2h
kube-system kube-dns-86cc76f8d-9jh2w 3/3 Running 0 2h
kube-system kube-proxy-65mtx 1/1 Running 1 2h
kube-system kube-proxy-wkkdm 1/1 Running 0 2h
kube-system kube-scheduler-k8s-dp1 1/1 Running 0 2h
kube-system weave-net-6sbbn 2/2 Running 0 2h
kube-system weave-net-hdv9b 2/2 Running 3 2h
Однако, если я пытаюсь создать новое развертывание в кластере, развертывание создается, но его модуль не может перейти в соответствующее состояние RUNNING. например
[monkey@k8s-dp1 nginx-test]# kubectl apply -f https://k8s.io/docs/tasks/run-application/deployment.yaml
deployment "nginx-deployment" created
[monkey@k8s-dp1 nginx-test]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
default nginx-deployment-569477d6d8-f42pz 0/1 ContainerCreating 0 5s
default nginx-deployment-569477d6d8-spjqk 0/1 ContainerCreating 0 5s
kube-system etcd-k8s-dp1 1/1 Running 0 3h
kube-system kube-apiserver-k8s-dp1 1/1 Running 0 3h
kube-system kube-controller-manager-k8s-dp1 1/1 Running 0 3h
kube-system kube-dns-86cc76f8d-9jh2w 3/3 Running 0 3h
kube-system kube-proxy-65mtx 1/1 Running 1 2h
kube-system kube-proxy-wkkdm 1/1 Running 0 3h
kube-system kube-scheduler-k8s-dp1 1/1 Running 0 3h
kube-system weave-net-6sbbn 2/2 Running 0 2h
kube-system weave-net-hdv9b 2/2 Running 3 2h
Я не уверен, как выяснить, в чем проблема, но если я, например, сделать kubectl get evЯ вижу следующее подозрительное событие:
<invalid> <invalid> 1 nginx-deployment-569477d6d8-f42pz.15087c66386edf5d Pod
Warning FailedCreatePodSandBox kubelet, k8s-dp2 Failed create pod sandbox.
Но я не знаю, куда идти отсюда. Я также вижу, что само изображение докера nginx никогда не появляется в docker images,
Как я могу узнать больше о проблеме? Я что-то упустил в настройке kubernetes?
--- НОВАЯ ИНФОРМАЦИЯ ---
Для справочной информации на случай, если это поможет...
Узлы Kubernetes работают на виртуальных машинах CentOS 7, расположенных на Windows 10 hyper-v.
--- НОВАЯ ИНФОРМАЦИЯ ---
Бег kubectl describe pods показывает следующее предупреждение:
Warning NetworkNotReady 1m kubelet, k8s-dp2 network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized]
--- НОВАЯ ИНФОРМАЦИЯ ---
Выключив виртуальные машины Hyper-v, работающие с Kubernetes, на ночь после того, как мои дневные рабочие часы закончились, и по возвращении в офис этим утром я снова включил виртуальные машины Kubernetes, чтобы в течение примерно 15 минут выполнить команду:
kubectl get pods --all-namespaces все еще показывал ContainerCreating для этих модулей nginx, как и вчера, но сейчас команда теперь показывает все модули как Running включая модули nginx... т.е. проблема решилась сама собой после полной перезагрузки виртуальных машин как главного, так и рабочего узлов.
Теперь я снова выполнил еще одну полную перезагрузку, и все модули отображаются как "Бег", что хорошо.
11 ответов
При полной перезагрузке обеих виртуальных машин, на которых запущен главный узел Kubernetes и рабочий узел Kubernetes, все модули отображались как Running (ПРИМЕЧАНИЕ: после первой перезагрузки потребовалось около 15-20 минут для того, чтобы рассматриваемые модули перешли в Running состояние и, при последующей перезагрузке, указанные модули перешли в Running состояние относительно намного быстрее... 3-5 минут).
Использование kubectl describe pod <name> чтобы увидеть больше информации
С помощью kubectl describe pod покажет все события. В некоторых случаях при развертывании все еще могут извлекаться образы док-станции с удаленного компьютера, поэтому состояние будет по-прежнему отображаться как ContainerCreating
Просто поделился, что эта команда очень помогла выяснить мою проблему со статусом ContainerCreating:
kubectl get events --sort-by=.metadata.creationTimestamp
Вы можете удалить пакет, он будет создан автоматически.
kubectl delete pod -n namespace podname
В моем случае это было связано с отсутствием секрета или, скажем, ConfigMap в пространстве имен развертываний
Вы можете запустить
kubectl describe при развертывании, чтобы быть уверенным в происходящих событиях, или вы можете запустить
describe команда на модулях, развертывание которых набирает обороты.
Иногда у вас может не хватить ресурсов в вашем кластере. Проверьте, что вы используете
kubectl top на запущенных модулях, чтобы проверить, не исчерпывает ли один из них все ваши ресурсы.
Я надеюсь, что это достаточно полезно
Вчера я столкнулся с той же проблемой. Когда я описываю эти модули в статусе ContainerCreating, проблема была в CNI, он давал сбой, и модули остаются в статусе ContainerCreating. Поэтому я удаляю CNI с панели управления и повторно развертываю его. Все модули в течение минуты изменят свой статус на рабочий.
Была такая же проблема, но проблема с моей стороны заключалась в том, что кластеру потребовалось слишком много времени, чтобы вытащить изображение, может ли быстрый перезапуск кластера может помочь ускорить процесс
Я столкнулся с той же проблемой. Когда я перечисляю модули, некоторые из которых находились в статусе ContainerCreating, могут возникнуть следующие проблемы, которые будут видны в команде описания. Причины:- проблема с получением образа (или секрет отсутствует) / карта конфигурации недоступна и т. д.
причины можно увидеть в двух командах ниже.
kubectl описать пространство имен pod -n
systemctl status kubelet (здесь вы получите все ошибки соединения с репо)
обычно эта проблема возникает из-за прерывания получения изображения.
поэтому перезапустите последовательно два приведенных ниже сервиса.
sudo systemctl демон-перезагрузка
sudo systemctl перезапустить докер
sudo systemctl перезагрузить докер
sudo systemctl перезапустите kubelet (здесь мы получаем все журналы активных подключений)
Надеюсь, это поможет.