运维同学最近提供了一个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发现不通。
在node02上执行iptables-save命令，发现的确有一条把forward包drop的规则：
正常来说，物理网卡收到目标IP不是自己的包时，会把包forward给本机符合条件的内部网卡，从而进入容器中，所以一旦drop就肯定网络不通了。
删除所有机器上的drop规则后，测试发现仍旧无法联通coredns的POD IP。
第二阶段
在node02上，通过tcpdump -i flannel.1进行抓包观察，并在容器中ping coredns的POD IP，结果发现flannel.1上没有流量。
执行route -n查看了一下宿主机的路由表，发现了缺了一条到node01的路由规则，导致发往node01虚拟网段的流量没有经过flannel网关：
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：
这里nameserver配的是10.224.0.10，按道理这应该是coredns的service cluster ip。
但是直接查看K8S的service信息，发现coredns的service ip是10.192.0.10：
也就说容器内配置的nameserver ip和coredns的service ip不一样，到底哪个是对的IP呢呢？显然下面的是对的，因为用这个IP可以访问到coredns，并且iptables规则里也是用的10.192.0.10做的service负载均衡：
与运维同学沟通，可能与初始化集群时候重复kubeadm init有关，导致前一次的DNS配置遗留到了最后一次配置中。
修复方法是在configmap中找到kubelet的配置：
里面有一个clusterDNS的配置，目前是错误的IP，改成当前coredns的service ip即可：
需要重启集群，才能让所有POD应用新的nameserver配置。
最后
排查这个问题主要用到了几个东西：
route -n：查看路由表
ip addr：查看网卡、网桥
tcpdump：-i参数监听具体网卡
