Блоки, работающие в подчиненном узле Kubernetes, находятся в состоянии ContainerCreating - PullRequest
Новая
       6

Блоки, работающие в подчиненном узле Kubernetes, находятся в состоянии ContainerCreating

0 голосов
/ 28 июня 2018

Мне удалось настроить мастера Kubernetes. Я создал подчиненный узел Kubernetes, установив Docker и kubelet (используя kubeadm). После выполнения команды соединения подчиненный узел присоединяется к кластеру. Я могу проверить это с главного узла. Но модули, которые развертываются в подчиненном узле, всегда находятся в состоянии ContainerCreating. Кроме докера и кублета, есть ли что-то еще, что нужно установить в подчиненном узле ??

Состояние kubectl показывает, что remote_runtime.go: RunPodSandBox из службы времени выполнения не выполнен: ошибка rpc: code = DeadlineExceeded

Ценю вашу помощь.

1 Ответ

0 голосов
/ 29 июня 2018

В таких случаях я обычно начинаю устранять неполадки кластера, проверяя состояние модулей в пространстве имен kube-system с помощью команды: 

$ kubectl get pods --all-namespaces -o wide

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

NAMESPACE     NAME                    READY     STATUS    RESTARTS   AGE       IP               NODE
kube-system   calico-node-2rpns       2/2       Running   0          2h        10.154.0.5       kube-node1
kube-system   calico-node-cn6cl       2/2       Running   0          2h        10.154.0.6       kube-master
kube-system   calico-node-fr7v5       2/2       Running   1          2h        10.154.0.7       kube-node2

Полный набор сетевых контейнеров зависит от того, какое сетевое решение Kubernetes используется.

Затем я проверяю, есть ли какие-нибудь модули в состоянии «Не готов», и проверяю ошибки в описании: 

$ kubectl describe pod not-ready-pod-name

В случае возникновения ошибок, связанных с извлечением изображения или созданием контейнера, я проверяю журналы kubelet на узле для получения более подробной информации: 

$ journalctl -u kubelet

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

$ docker pull <image>

Если у модуля много перезагрузок, я проверяю журналы контейнера модуля: 

$ kubectl logs ${POD_NAME} ${CONTAINER_NAME}

или журналы предыдущего разбившегося контейнера: 

$ kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}

Мои следующие шаги зависят от предыдущих результатов.

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

...