运维同学最近提供了一个K8S集群，但是使用的时候发现网络不通，于是展开了一次排查。
现象
node01（虚拟网段：10.244.0.0/24）部署了coredns，node02（虚拟网段：10.244.1.0/24）是我的容器，网络是flannel vxlan。
在我的容器中执行yum安装工具卡住，请求baidu.com也卡住。
第一阶段
在node02上通过ping baidu.com命令，确认没有解析到IP，所以是卡在DNS解析上。
K8S容器解析域名是调用coredns的service ip，尝试在ping coredns的POD IP发现不通。
一开始没有排查思路，在谷歌上搜索到相关问题：https://github.com/k8sp/sextant/issues/525。
在node02上执行iptables-save命令，发现的确有一条把forward包drop的规则：
|
1 |
:FORWARD DROP [0:0] |
正常来说，物理网卡收到目标IP不是自己的包时，会把包forward给本机符合条件的内部网卡，从而进入容器中，所以一旦drop就肯定网络不通了。
删除所有机器上的drop规则后，测试发现仍旧无法联通coredns的POD IP。
同时也获知DROP后面方括号内是DROP的次数和包大小，可以确认此规则实际没有产生过作用。
第二阶段
在node02上，通过tcpdump -i flannel.1进行抓包观察，并在容器中ping coredns的POD IP，结果发现flannel.1上没有流量。
执行route -n查看了一下宿主机的路由表，发现了缺了一条到node01的路由规则，导致发往node01虚拟网段的流量没有经过flannel网关：
|
1 2 3 4 |
10.244.2.0 10.244.2.0 255.255.255.0 UG 0 0 0 flannel.1 10.244.6.0 10.244.6.0 255.255.255.0 UG 0 0 0 flannel.1 10.244.7.0 10.244.7.0 255.255.255.0 UG 0 0 0 flannel.1 10.244.8.0 10.244.8.0 255.255.255.0 UG 0 0 0 flannel.1 |
node02的虚拟网段是10.244.1.0/24，所以本机POD之间直接走cni0网桥做2交换即可，而发往其他node的POD的流量都要发给flannel.1网关，由它在本机做vxlan封装后从eth0送出。
这里因为少了到node01网段10.244.0.0/24的路由规则，导致node02的包无法被flannel处理。
不太清楚是什么原因导致flannel没有生成这条路由规则，重启了各个节点就恢复了。
此时发现，虽然到coredns的POD IP已经可以ping通，但是ping baidu.com仍旧卡在解析上得不到IP，这是什么鬼？
第三阶段
既然到coredns的4层网络已通，于是只能向应用层怀疑：要么是coredns服务端不好，要么是客户端不好。
排查服务端很简单，dig @coredns的IP baidu.con，发现可以解析到IP，所以coredns服务正常。
客户端只能看一下/etc/resolv.conf：
|
1 2 3 4 |
[root@zhongce-67bd8b9977-l54s2 ~]# cat /etc/resolv.conf nameserver 10.224.0.10 search default.svc.cluster.global svc.cluster.global cluster.global options ndots:5 |
这里nameserver配的是10.224.0.10，按道理nameserver应该配置为coredns的service cluster ip，然而查看发现K8S的coredns的service ip是10.192.0.10：
|
1 2 3 |
[root@node03 ~]# kubectl get services -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.192.0.10 <none> 53/UDP,53/TCP 16d |
也就说容器内配置的nameserver ip和coredns的service ip不一样，到底哪个是对的IP呢？
正确的是10.192.0.10，用这个IP可以访问到coredns，并且查看iptables-save命令配置的也是10.192.0.10的负载均衡：
|
1 2 3 4 5 |
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.192.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-MARK-MASQ -A KUBE-SERVICES -d 10.192.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU -A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.192.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-MARK-MASQ -A KUBE-SERVICES -d 10.192.0.10/32 -p tcp -m comment --comment "kube-system/kube-dns:dns-tcp cluster IP" -m tcp --dport 53 -j KUBE-SVC-ERIFXISQEP7F7OF4 |
与运维同学沟通，可能与初始化集群时候重复kubeadm init有关，导致前一次的DNS配置遗留到了最后一次配置中。
修复方法是在configmap中找到kubelet-config-1.13（我的K8S版本是1.13）：
|
1 2 3 4 5 6 7 8 9 10 |
[root@node03 ~]# kubectl get configmap -n kube-system NAME DATA AGE coredns 1 16d extension-apiserver-authentication 6 16d istio.v1 1 12d kube-flannel-cfg 2 16d kube-proxy 2 16d kubeadm-config 2 16d kubelet-config-1.13 1 16d kubernetes-dashboard-settings 1 16d |
里面有一个clusterDNS的配置，目前是错误的IP，改成当前coredns的service ip即可：
|
1 2 3 4 5 |
$ kubectl get configmap kubelet-config-1.13 -n kube-system -o yaml 修改为正确的Coredns service ip： clusterDNS: - 10.192.0.10 |
需要重启应用的POD才能生效到它们的/etc/resolv.conf中。
最后
排查这个问题主要用到了几个东西：
- route -n：查看路由表
- ip addr：查看网卡、网桥
- tcpdump：-i参数监听具体网卡
如果文章帮助您解决了工作难题，您可以帮我点击屏幕上的任意广告，或者赞助少量费用来支持我的持续创作，谢谢~
