K8S – 记一次网络问题排查

运维同学最近提供了一个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的规则：

正常来说，物理网卡收到目标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参数监听具体网卡

博主无私的分享着知识，你愿意送他一顿热腾腾的早餐吗？