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。

同时也获知DROP后面方括号内是DROP的次数和包大小,可以确认此规则实际没有产生过作用。

第二阶段

在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,按道理nameserver应该配置为coredns的service cluster ip,然而查看发现K8S的coredns的service ip是10.192.0.10:

也就说容器内配置的nameserver ip和coredns的service ip不一样,到底哪个是对的IP呢?

正确的是10.192.0.10,用这个IP可以访问到coredns,并且查看iptables-save命令配置的也是10.192.0.10的负载均衡:

与运维同学沟通,可能与初始化集群时候重复kubeadm init有关,导致前一次的DNS配置遗留到了最后一次配置中。

修复方法是在configmap中找到kubelet-config-1.13(我的K8S版本是1.13):

里面有一个clusterDNS的配置,目前是错误的IP,改成当前coredns的service ip即可:

需要重启应用的POD才能生效到它们的/etc/resolv.conf中。

最后

排查这个问题主要用到了几个东西:

  • route -n:查看路由表
  • ip addr:查看网卡、网桥
  • tcpdump:-i参数监听具体网卡
如果文章帮助到你,那么帮我点一下广告 or 打赏1元钱,服务器费用需要大家的支持。

发表评论

电子邮件地址不会被公开。