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

Question

我有一个运行在4个树莓派设备上的Kubernetes集群，其中1个作为主节点（master），另外3个作为工作节点（worker），分别是w1、w2、w3。我已经开始了一个daemon set部署，因此每个工作节点都在运行两个容器的pod。

w2正在运行一个包含2个容器的pod。如果我进入任何一个容器并从容器中ping www.google.com，则会得到响应。但是如果我在w1和w3上执行相同的操作，则会显示“名称解析暂时失败”。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 容器命令启动容器，而不是从 Kubernetes 部署中启动，那么我就看不到这个问题。我认为这是由于 kube-dns 引起的。我该如何调试这个问题？

- S Andrew

Answer 1

您可以从检查DNS是否正常开始。

在Pod内部运行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

检查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

希望这能帮到你。

- Prafull Ladha

---

当你说在 Pod 内运行 nslookup，是指在容器内还是在主设备上运行。谢谢。 - S Andrew

当我运行ping命令时，我没有在kube-dns的日志中看到任何活动。 - S Andrew

kubernetes.default 解析为 kubedns 服务，该服务在我的情况下具有 clusterIP 10.96.0.1。这只是为了检查 kubedns 是否正常工作。如果它正常工作，那么问题就出在其他地方。我刚刚部署了一个由 3 个节点（1 个主节点，2 个工作节点）和 weave CNI 组成的 Kubernetes 集群。在我的集群中，一切都正常工作。 - Prafull Ladha

感谢您的解释，Prafull。我运行了nslookup命令并得到了以下响应：`服务器: 192.168.0.21 地址: 192.168.0.21#53** 服务器无法找到kubernetes.default: NXDOMAIN`。 - S Andrew

您正在显示一个NXDOMAIN回复，这意味着它确实收到了来自某个DNS服务器的回复，并且该服务器声明从未听说过“kubernetes.default”。 我建议查看kube-dns的日志，以查看（a）是否实际上是该服务器在回复，以及（b）原因。 - Prafull Ladha

Answer 2

这可能与您的情况不适用，但我想记录我找到的解决方案。我的问题最终与我们主节点上设置的 flannel 网络覆盖层有关。

# 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 不同。

修改我的 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 的网站。然后我们发现了 this issue，目前正在调查它作为可能解决方案的可行性，而不使用 hostNetwork: true。

通常情况下，您可以通过 flannel 的“--ip-masq”标志来执行此操作，默认情况下该标志设置为“false”，并定义为“设置用于目的地位于覆盖网络之外的流量的 IP 假冒规则”。这听起来就是您想要的。

更新 2

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

- rjminchuk