Wie wird CrashLoopBackOff für den zweiten Knoten repariert?
Ich habe 2 VMs Knoten. Beide sehen sich entweder nach Hostname (über / etc / hosts) oder nach IP-Adresse. Einer wurde mit kubeadm als Master ausgestattet. Ein anderer als Arbeiterknoten. Befolgen Sie die Anweisungen http: //kubernetes.io/docs/getting-started-guides/kubeadm) Ich habe Webenetz hinzugefügt. Die Liste der Pods sieht folgendermaßen aus:
vagrant@vm-master:~$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system etcd-vm-master 1/1 Running 0 3m
kube-system kube-apiserver-vm-master 1/1 Running 0 5m
kube-system kube-controller-manager-vm-master 1/1 Running 0 4m
kube-system kube-discovery-982812725-x2j8y 1/1 Running 0 4m
kube-system kube-dns-2247936740-5pu0l 3/3 Running 0 4m
kube-system kube-proxy-amd64-ail86 1/1 Running 0 4m
kube-system kube-proxy-amd64-oxxnc 1/1 Running 0 2m
kube-system kube-scheduler-vm-master 1/1 Running 0 4m
kube-system kubernetes-dashboard-1655269645-0swts 1/1 Running 0 4m
kube-system weave-net-7euqt 2/2 Running 0 4m
kube-system weave-net-baao6 1/2 CrashLoopBackOff 2 2m
CrashLoopBackOff wird für jeden verbundenen Arbeitsknoten angezeigt. Ich habe einige unserer Jahre damit verbracht, mit Netzwerkschnittstellen zu spielen, aber es scheint, dass das Netzwerk in Ordnung ist. Ich habe eine ähnliche Frage gefunden, bei der die Antwort angeraten hat, in die Protokolle zu schauen und keine Folgemaßnahmen zu treffen. Also, hier sind die Protokolle:
vagrant@vm-master:~$ kubectl logs weave-net-baao6 -c weave --namespace=kube-system
2016-10-05 10:48:01.350290 I | error contacting APIServer: Get https://100.64.0.1:443/api/v1/nodes: dial tcp 100.64.0.1:443: getsockopt: connection refused; trying with blank env vars
2016-10-05 10:48:01.351122 I | error contacting APIServer: Get http://localhost:8080/api: dial tcp [::1]:8080: getsockopt: connection refused
Failed to get peers
Was mache ich falsch? Wohin von dort?