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

#kubernetes #weave

#kubernetes #переплетение

Вопрос:

У меня есть 2 виртуальных узла. Оба видят друг друга либо по имени хоста (через /etc/hosts), либо по ip-адресу. Один из них был предоставлен с помощью kubeadm в качестве ведущего. Другой в качестве рабочего узла. Следуя инструкциям (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
  

Сбой привязки отображается для каждого подключенного рабочего узла. Я провел несколько наших игр с сетевыми интерфейсами, но, похоже, сеть в порядке. Я нашел аналогичный вопрос, в котором в ответе рекомендуется заглянуть в журналы и не следить. Итак, вот журналы:

 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
  

Что я делаю не так? Что делать дальше?

Ответ №1:

Я тоже участвовал в том же выпуске. Похоже, weaver хочет подключиться к IP-адресу кластера Kubernetes, который является виртуальным. Просто запустите это, чтобы найти 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>
  

Комментарии:

1. Добавление маршрута является допустимым решением для некоторых случаев, однако передача Weave CIDR в kube-proxy with --cluster-cidr=10.32.0.0/12 , возможно, является лучшим вариантом.

2. @errordeveloper — Спасибо за предложение, этот рабочий отлично!

3. @errordeveloper как добавить —cluster-cidr=10.32.0.0/12 в kube-proxy ?

Ответ №2:

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

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

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, если это проблема, связанная с weave

Комментарии:

1. Я сказал это неправильно… Я имел в виду, что это происходит и для одного узла (не только)… я отредактирую свой ответ….

2. Я не уверен, что ваша проблема совпадает с описанной OP. Бывает, что есть похожие симптомы для разных, несколько разных проблем.

Ответ №3:

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

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

Прямо сейчас существует эталонная реализация VirtualBox Vargant Ansible для Ubunutu и CentOS, которая предоставляет решения для проблем брандмауэра, SELinux и VirtualBox NAT.

Ответ №4:

сброс /usr/local/bin/weave

было ли это исправлением для меня — надеюсь, оно полезно — и да, убедитесь, что selinux отключен, а firewalld не запущен (в выпусках redhat / centos)

kube-system weave-net-2vlvj 2/2 Работает 3 11d
kube-system weave-net-42k6p 1/2 Работает 3 11d
kube-system weave-net-wvsk5 2/2 работает 3 11d