Kubernetes：容器无法 ping www.google.com

Question

我有kubernetes集群在 4 个Raspberry-pi设备上运行，其中 1 个充当master kubernetes ，其他 3 个充当worker w1 ，即w1 、 w2 、 w3 。 我已经开始了一个守护进程集部署，所以每个工作人员都在运行一个包含 2 个容器的 pod。

w2正在运行 2 个容器的 pod。 如果我exec到任何容器并从容器 ping www.google.com ，我会得到响应。 但是如果我在w1和w3上做同样的事情，它会说temporary failure in name resolution 。 kube-system 中的所有 pod 都在运行。 我正在使用weave进行网络连接。 以下是 kube-system 的所有 pod

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

您可以先检查 dns 是否正常工作

从 pod 内部在 kubernetes.default 上运行 nslookup，检查它是否正常工作。

[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

检查 Pod 内的本地 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

最后，在运行 ping 命令时检查 kube-dns 容器日志，它将为您提供名称未解析的可能原因。

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

希望这可以帮助。

Answer 2

这可能不适用于您的场景，但我想记录我找到的解决方案。 我的问题最终与我们主节点上的法兰绒网络覆盖设置有关。

# 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

如果我执行到任何容器并从容器 ping 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从主节点运行。

更改我的 pods 部署配置以包含hostNetwork: true允许我在容器外进行 ping 操作。

我新运行的 pod ip 路由

# 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 。 然后我们发现了这个问题，目前正在研究它作为一个可能的解决方案，sans hostNetwork: true 。

通常你会用'--ip-masq'标志来做这件事，默认情况下它是'false'，被定义为“为覆盖网络之外的流量设置IP伪装规则”。 这听起来像你想要的。

更新 2

事实证明，我们的法兰绒网络覆盖配置错误。 我们需要确保我们的 flannel configmap 有 net-conf\\.json.network 匹配我们的networking.podSubnet（ kubeadm config view ）。 更改这些网络以匹配减轻了我们的网络问题。 然后我们能够从我们的部署中删除hostNetwork: true 。