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

У меня есть 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

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

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


kubernetes weave
person Andrew    schedule 05.10.2016    source источник

Ответы (4)


arrow_upward
12
arrow_downward

Я тоже столкнулся с той же проблемой. Кажется, 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>
person Hitman_99    schedule 31.10.2016
comment
Добавление маршрута является допустимым решением для некоторых случаев, однако передача Weave CIDR на kube-proxy с --cluster-cidr=10.32.0.0/12, возможно, является лучшим вариантом. - person errordeveloper; 01.11.2016
comment
@errordeveloper - Спасибо за предложение, этот рабочий отлично! - person Hitman_99; 01.11.2016
comment
@errordeveloper, как добавить --cluster-cidr=10.32.0.0/12 в kube-proxy? - person Vaibhav Jain; 26.06.2017

arrow_upward
2
arrow_downward

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

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

вниз.ш

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

person David Steiman    schedule 28.10.2016
comment
Я сказал это неправильно... Я имел в виду, что это происходит и для одного узла (не только)... я отредактирую свой ответ.... - person David Steiman; 30.10.2016
comment
Я не уверен, что ваша проблема такая же, как описанная OP. Бывает, что бывают похожие симптомы при разных несколько разных проблемах. - person errordeveloper; 01.11.2016

arrow_upward
2
arrow_downward

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

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

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

person errordeveloper    schedule 01.11.2016

arrow_upward
0
arrow_downward

/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

person Jeff Schmitz    schedule 26.09.2018