Подвиды в ожидании состояния неопределенно

Question

Я работаю с кластером из 6 узлов в течение последних нескольких недель без проблем. Раньше сегодня мы столкнулись с проблемой открытого файла (https://github.com/kubernetes/kubernetes/pull/12443/files), и я исправил и перезапустил kube-proxy.

С тех пор все rc развернули контейнеры для ВСЕХ, НО узел-01 застряли в ожидающем состоянии и там были сообщения журнала с указанием причины.

Глядя на демон докеров на узлах, контейнеры в контейнере на самом деле работают, и удаление rc их удаляет. По-видимому, это какая-то проблема обратного вызова между состоянием в соответствии с кубелем и кубиком-купером.

Кластер работает v1.0.3

Вот пример состояния

docker run --rm -it lachie83/kubectl:prod get pods --namespace=kube-system -o wide 
NAME    READY  STATUS RESTARTS AGE  NODE 
kube-dns-v8-i0yac 0/4  Pending 0   4s  10.1.1.35 
kube-dns-v8-jti2e 0/4  Pending 0   4s  10.1.1.34 

получить событий

Wed, 16 Sep 2015 06:25:42 +0000 Wed, 16 Sep 2015 06:25:42 +0000 1   kube-dns-v8      ReplicationController            successfulCreate {replication-controller } Created pod: kube-dns-v8-i0yac 
Wed, 16 Sep 2015 06:25:42 +0000 Wed, 16 Sep 2015 06:25:42 +0000 1   kube-dns-v8-i0yac     Pod                 scheduled   {scheduler }    Successfully assigned kube-dns-v8-i0yac to 10.1.1.35 
Wed, 16 Sep 2015 06:25:42 +0000 Wed, 16 Sep 2015 06:25:42 +0000 1   kube-dns-v8-jti2e     Pod                 scheduled   {scheduler }    Successfully assigned kube-dns-v8-jti2e to 10.1.1.34 
Wed, 16 Sep 2015 06:25:42 +0000 Wed, 16 Sep 2015 06:25:42 +0000 1   kube-dns-v8      ReplicationController            successfulCreate {replication-controller } Created pod: kube-dns-v8-jti2e 

планировщик журнал

I0916 06:25:42.897814 10076 event.go:203] Event(api.ObjectReference{Kind:"Pod", Namespace:"kube-system", Name:"kube-dns-v8-jti2e", UID:"c1cafebe-5c3b-11e5-b3c4-020443b6797d", APIVersion:"v1", ResourceVersion:"670117", FieldPath:""}): reason: 'scheduled' Successfully assigned kube-dns-v8-jti2e to 10.1.1.34 
I0916 06:25:42.904195 10076 event.go:203] Event(api.ObjectReference{Kind:"Pod", Namespace:"kube-system", Name:"kube-dns-v8-i0yac", UID:"c1cafc69-5c3b-11e5-b3c4-020443b6797d", APIVersion:"v1", ResourceVersion:"670118", FieldPath:""}): reason: 'scheduled' Successfully assigned kube-dns-v8-i0yac to 10.1.1.35 

хвостовых kubelet лог-файл во время стручок создать

tail -f kubelet.kube-node-03.root.log.INFO.20150916-060744.10668 
I0916 06:25:04.448916 10668 config.go:253] Setting pods for source file : {[] 0 file} 
I0916 06:25:24.449253 10668 config.go:253] Setting pods for source file : {[] 0 file} 
I0916 06:25:44.449522 10668 config.go:253] Setting pods for source file : {[] 0 file} 
I0916 06:26:04.449774 10668 config.go:253] Setting pods for source file : {[] 0 file} 
I0916 06:26:24.450400 10668 config.go:253] Setting pods for source file : {[] 0 file} 
I0916 06:26:44.450995 10668 config.go:253] Setting pods for source file : {[] 0 file} 
I0916 06:27:04.451501 10668 config.go:253] Setting pods for source file : {[] 0 file} 
I0916 06:27:24.451910 10668 config.go:253] Setting pods for source file : {[] 0 file} 
I0916 06:27:44.452511 10668 config.go:253] Setting pods for source file : {[] 0 file} 

процессу kubelet список узлов

root@kube-node-03:/var/log/kubernetes# ps -ef | grep kubelet 
root  10668  1 1 06:07 ?  00:00:13 /opt/bin/kubelet --address=10.1.1.34 --port=10250 --hostname_override=10.1.1.34 --api_servers=https://kube-master-01.sj.lithium.com:6443 --logtostderr=false --log_dir=/var/log/kubernetes --cluster_dns=10.1.2.53 --config=/etc/kubelet/conf --cluster_domain=prod-kube-sjc1-1.internal --v=4 --tls-cert-file=/etc/kubelet/certs/kubelet.pem --tls-private-key-file=/etc/kubelet/certs/kubelet-key.pem 

docker run --rm -it lachie83/kubectl:prod get nodes 
NAME   LABELS            STATUS 
10.1.1.30 kubernetes.io/hostname=10.1.1.30,name=node-1 Ready 
10.1.1.32 kubernetes.io/hostname=10.1.1.32,name=node-2 Ready 
10.1.1.34 kubernetes.io/hostname=10.1.1.34,name=node-3 Ready 
10.1.1.35 kubernetes.io/hostname=10.1.1.35,name=node-4 Ready 
10.1.1.42 kubernetes.io/hostname=10.1.1.42,name=node-5 Ready 
10.1.1.43 kubernetes.io/hostname=10.1.1.43,name=node-6 Ready 

Answer 1

Похоже, вы создаете кластер с нуля. Проводили ли вы тест соответствия с вашим кластером? Если нет, то, пожалуйста, запустите его и подробные сведения можно найти по адресу:

https://github.com/kubernetes/kubernetes/blob/e8009e828c864a46bf2e1d5c7dab8ef413c8bbe5/hack/conformance-test.sh

тест на соответствие должен не удалось, или, по крайней мере, дать нам больше информации о вашей установке кластера. Пожалуйста, отправьте результат теста где-нибудь, чтобы мы могли больше диагностировать вашу проблему.

Проблема, скорее всего, ваш кубелет и ваш кубик-купер не согласны с именем узла здесь. И я также заметил, что вы также используете hostname_override.

Answer 2

Проблема оказалась проблемой MTU между узлом и ведущим. Как только это было исправлено, проблема была решена.