【问题标题】：Kubernetes: Container not able to ping www.google.comKubernetes：容器无法 ping www.google.com
【发布时间】：2018-11-15 06:57:16
【问题描述】：

我有 kubernetes 集群在 4 个 Raspberry-pi 设备上运行，其中 1 个充当 master，其他 3 个充当 worker，即 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。我该如何调试这个问题？

【问题讨论】：

标签： docker networking kubernetes

【解决方案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

希望这会有所帮助。

【讨论】：

当您说从 pod 内部运行 nslookup 时，您是指从容器内部还是在主设备上运行。谢谢
您也可以在容器内进行。是一样的。
kubernetes.default 中的 default 是什么意思。这个默认值是否意味着默认命名空间，所以这意味着我必须在 nslookup 时提及我的命名空间
当我运行 ping 命令时，我在 kube-dns 的日志中看不到任何活动
kubernetes.default 在我的例子中解析为集群IP为10.96.0.1的kubedns服务。那只是为了检查 kubedns 是否工作正常。如果它工作正常，则意味着问题出在其他地方。我刚刚使用 weave CNI 部署了 3 个节点（1 个主节点，2 个工作节点）的 kubernetes 集群。在我的集群上一切正常。

【解决方案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 route 不同于ip route 从主节点运行。

更改我的 pod 部署配置以包含 hostNetwork: true 允许我在容器外部 ping。

我新运行的 pod ip route

# 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。然后我们找到了this issue，目前正在调查它作为一种可能的解决方案，没有hostNetwork: true。

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

更新 2

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

【讨论】：