Как исправить weave-net CrashLoopBackOff для второго узла?

Question

У меня есть два узла VM. Оба видят друг друга либо по имени хоста (через/etc/hosts), либо по ip-адресу. Один из них был снабжен кубистом в качестве мастера. Другой - рабочий узел. Следуя инструкциям (http://kubernetes.io/docs/getting-started-guides/kubeadm/), я добавил weave-net. Список стручков выглядит следующим образом:

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 появляется для каждого узла рабочего подключения. Я провел несколько наших игр с сетевыми интерфейсами, но кажется, что сеть в порядке. Я нашел аналогичный вопрос, где ответ посоветовал посмотреть в журналы и не следить. Итак, вот журналы:

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 

Что я делаю неправильно? Куда пойти оттуда?

Answer 1

Это происходит с установкой одного узла. Я пробовал несколько вещей, таких как повторное использование конфигурации и отдыха, но самым стабильным способом на данный момент является полное срыв (как описано в документах) и снова кластер.

Я использую эти сценарии для перезапуска кластера:

down.sh

#!/bin/bash 

systemctl stop kubelet; 
docker rm -f -v $(docker ps -q); 
find /var/lib/kubelet | xargs -n 1 findmnt -n -t tmpfs -o TARGET -T | uniq | xargs -r umount -v; 
rm -r -f /etc/kubernetes /var/lib/kubelet /var/lib/etcd; 

up.sh

#!/bin/bash 

systemctl start kubelet 
kubeadm init 
# kubectl taint nodes --all dedicated- # single node! 
kubectl create -f https://git.io/weave-kube 

редактировать: Я также хотел бы дать другим сетям PoD попробовать, как Calico, если это проблема, связанная с переплетением

Answer 2

Я столкнулся с тем же вопросом. Кажется, weaver хочет подключиться к IP-адресу Kubernetes Cluster, который является виртуальным. Просто запустите это, чтобы найти кластер ip: kubectl get svc. Это должно дать вам что-то вроде этого:

$ kubectl get svc 
NAME      CLUSTER-IP  EXTERNAL-IP PORT(S) AGE 
kubernetes    100.64.0.1  <none>  443/TCP 2d 

Weaver поднимает этот IP и пытается подключиться к нему, но рабочие узлы ничего не знает об этом. Простой маршрут решит эту проблему. На всех рабочих узлов, выполнить:

route add 100.64.0.1 gw <your real master IP> 

Answer 3

Наиболее распространенными причинами этого могут быть: - наличие брандмауэра (например, firewalld на CentOS) - конфигурация сети (например, интерфейс NAT по умолчанию на VirtualBox)

В настоящее время kubeadm по-прежнему является альфой, и это одна из проблем, о которых уже сообщали многие альфа-тестеры. Мы изучаем это, документируя наиболее распространенные проблемы, такая документация будет готова ближе к бета-версии.

Право существует a VirtualBox+Vargant+Ansible for Ubunutu and CentOS reference implementation, который предоставляет решения для брандмауэров, проблем SELinux и VirtualBox NAT.