Kubernetes: контейнер не может пропинговать www.google.com

Question

У меня кластер kubernetes работает на 4 Raspberry-pi устройствах, из которых 1 действует как master, а остальные 3 работают как worker т.е. w1, w2, w3. Я начал развертывание набора демонов, поэтому каждый работник запускает модуль из 2 контейнеров.

w2 это стручок 2 контейнера. Если я exec в любой контейнер и пинг www.google.com из контейнера, я получаю ответ. Но если я сделаю то же самое на w1 и w3, это скажет temporary failure in name resolution. Все модули в kube-системе работают. Я использую weave для работы в сети. Ниже представлены все модули для системы kube

NAME                                READY     STATUS    RESTARTS   AGE
etcd-master-pi                      1/1       Running   1          23h
kube-apiserver-master-pi            1/1       Running   1          23h
kube-controller-manager-master-pi   1/1       Running   1          23h
kube-dns-7b6ff86f69-97vtl           3/3       Running   3          23h
kube-proxy-2tmgw                    1/1       Running   0          14m
kube-proxy-9xfx9                    1/1       Running   2          22h
kube-proxy-nfgwg                    1/1       Running   1          23h
kube-proxy-xbdxl                    1/1       Running   3          23h
kube-scheduler-master-pi            1/1       Running   1          23h
weave-net-7sh5n                     2/2       Running   1          14m
weave-net-c7x8p                     2/2       Running   3          23h
weave-net-mz4c4                     2/2       Running   6          22h
weave-net-qtgmw                     2/2       Running   10         23h

Если я запускаю контейнеры с помощью обычной команды docker container, но не из развертывания kubernetes, тогда я не вижу этой проблемы. Я думаю, что это из-за kube-dns. Как я могу отладить эту проблему .?

Answer 1

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

# kubectl get pods --namespace kube-system
NAME                         READY   STATUS    RESTARTS   AGE
coredns-qwer                 1/1     Running   0          4h54m
coredns-asdf                 1/1     Running   0          4h54m
etcd-h1                      1/1     Running   0          4h53m
etcd-h2                      1/1     Running   0          4h48m
etcd-h3                      1/1     Running   0          4h48m
kube-apiserver-h1            1/1     Running   0          4h53m
kube-apiserver-h2            1/1     Running   0          4h48m
kube-apiserver-h3            1/1     Running   0          4h48m
kube-controller-manager-h1   1/1     Running   2          4h53m
kube-controller-manager-h2   1/1     Running   0          4h48m
kube-controller-manager-h3   1/1     Running   0          4h48m
kube-flannel-ds-amd64-asdf   1/1     Running   0          4h48m
kube-flannel-ds-amd64-qwer   1/1     Running   1          4h48m
kube-flannel-ds-amd64-zxcv   1/1     Running   0          3h51m
kube-flannel-ds-amd64-wert   1/1     Running   0          4h54m
kube-flannel-ds-amd64-sdfg   1/1     Running   1          4h41m
kube-flannel-ds-amd64-xcvb   1/1     Running   1          4h42m
kube-proxy-qwer              1/1     Running   0          4h42m
kube-proxy-asdf              1/1     Running   0          4h54m
kube-proxy-zxcv              1/1     Running   0          4h48m
kube-proxy-wert              1/1     Running   0          4h41m
kube-proxy-sdfg              1/1     Running   0          4h48m
kube-proxy-xcvb              1/1     Running   0          4h42m
kube-scheduler-h1            1/1     Running   1          4h53m
kube-scheduler-h2            1/1     Running   1          4h48m
kube-scheduler-h3            1/1     Running   0          4h48m
tiller-deploy-asdf           1/1     Running   0          4h28m

Если я выполняю exec'd в любой контейнер и ping'd google.com из контейнера, я получаю неправильный адрес ответа.

# ping google.com
ping: bad address 'google.com'

# ip route
default via 10.168.3.1 dev eth0
10.168.3.0/24 dev eth0 scope link  src 10.168.3.22
10.244.0.0/16 via 10.168.3.1 dev eth0

IP-маршрут варьируется от ip route запуска от главного узла.

изменение конфигурации развертывания моих модулей для включения hostNetwork: true позволило мне пропинговать вне моего контейнера.

мой недавно запущенный IP-маршрут для pod

# ip route
default via 172.25.10.1 dev ens192  metric 100
10.168.0.0/24 via 10.168.0.0 dev flannel.1 onlink
10.168.1.0/24 via 10.168.1.0 dev flannel.1 onlink
10.168.2.0/24 via 10.168.2.0 dev flannel.1 onlink
10.168.3.0/24 dev cni0 scope link  src 10.168.3.1
10.168.4.0/24 via 10.168.4.0 dev flannel.1 onlink
10.168.5.0/24 via 10.168.5.0 dev flannel.1 onlink
172.17.0.0/16 dev docker0 scope link  src 172.17.0.1
172.25.10.0/23 dev ens192 scope link  src 172.25.11.35  metric 100
192.168.122.0/24 dev virbr0 scope link  src 192.168.122.1

# ping google.com
PING google.com (172.217.6.110): 56 data bytes
64 bytes from 172.217.6.110: seq=0 ttl=55 time=3.488 ms

Обновление 1

Мы с моим партнером нашли несколько разных веб-сайтов, которые не советуют устанавливать hostNetwork: true. Затем мы нашли эту проблему и в настоящее время исследуем ее как возможное решение, без hostNetwork: true.

Обычно вы делаете это с флагом «--ip-masq» для фланели, который по умолчанию имеет значение «false» и определяется как «правило IP-маскарада для трафика, предназначенного вне оверлейной сети». Что звучит как то, что вы хотите.

Обновление 2

Оказывается, что наше перекрытие фланелевой сети было неправильно настроено. Нам нужно было убедиться, что наш configmap для фланели имеет net-conf \ .json.network, соответствующий нашему network.podSubnet (kubeadm config view). Изменение этих сетей для соответствия облегчило наши сетевые проблемы. Затем мы смогли удалить hostNetwork: true из наших развертываний.

Answer 2

Вы можете начать с проверки, работает ли днс

Запустите nslookup на kubernetes.default из модуля, проверьте, работает ли он.

[root@metrics-master-2 /]# nslookup kubernetes.default
Server:     10.96.0.10
Address:    10.96.0.10#53

Name:   kubernetes.default.svc.cluster.local
Address: 10.96.0.1

Проверьте локальную конфигурацию DNS внутри модулей:

[root@metrics-master-2 /]# cat /etc/resolv.conf 
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local ec2.internal
options ndots:5

Наконец, проверьте журналы контейнера kube-dns во время выполнения команды ping. Это даст вам возможные причины, по которым имя не разрешается.

kubectl logs kube-dns-86f4d74b45-7c4ng -c kubedns -n kube-system

Надеюсь, это поможет.