我有kubernetes个集群在4个Raspberry-pi设备上运行，其中1个充当master，其他3个充当worker，即w1 ，w2，w3。我已经启动了守护程序集部署，因此每个工作人员都在运行一个由2个容器组成的容器。
w2正在运行2个容器的容器。如果我exec进入任何容器并从该容器ping www.google.com，我将得到响应。但是，如果我在w1和w3上执行相同操作，则会显示temporary failure in name resolution。 kube系统中的所有pod都在运行。我正在使用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。我该如何调试此问题。
答案 0 :(得分：2)
您可以先检查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
希望这会有所帮助。
答案 1 :(得分：0)
这可能不适用于您的方案，但是我想记录一下我找到的解决方案。我的问题最终与主节点上的法兰绒网络覆盖设置有关。
# 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不同。
更改Pod部署配置以使其包含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
我的同事和我发现了许多不同的网站，建议不要设置hostNetwork: true。然后我们找到了this issue，目前正在研究它是一种可能的解决方案，没有hostNetwork: true。
通常，您可以使用法兰绒头的'--ip-masq'标志来执行此操作，默认情况下该标志为'false'，并被定义为“针对覆盖网络之外的流量的设置IP伪装规则”。听起来像您想要的。
事实证明我们的法兰绒网络覆盖配置不正确。我们需要确保我们的法兰绒配置图具有与我们的networking.podSubnet（kubeadm config view）相匹配的net-conf \ .json.network。更改这些网络以匹配我们的网络问题。然后，我们可以从部署中删除hostNetwork: true。