Kubernetes 同一个 Node 节点内的 Pod 不能通过 Service 互访

前言

    最近在测试 Kubernetes 应用的时候,发现了一个非常蛋疼的问题:同一个 Node 节点内的 Pod 不能通过 Service 互访

    各种百度、google,都没有查到有效的解决方法,一度怀疑是我部署的集群有问题,经过多天的折腾,终于找到问题所在,下面进行一下记录,作为一个实验报告吧~~

 

环境信息

Kubernetes版本 v1.18.8
网络组件 flannel:v0.12.0-amd64

 

 

组件部署方式                                                                                        

flannel 使用 DaemonSet 部署,coreDns 使用Deployment 部署,其他组件(etcd、kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy)使用二进制部署

kube-proxy运行模式

ipvs

 

资源名称 资源类型 Cluster-IP 网关 所在节点 监听端口
mars1 Pod 10.244.0.18 10.244.0.1 k8s1 /
mars2 Pod 10.244.2.31 10.244.2.1 k8s2 /
mars3 Pod 10.244.1.43 10.244.1.1 k8s3 /
nginx-app Deployment /   / /
nginx-app-57679cfb75-6z8nq Pod 10.244.0.19 10.244.0.1 / 80
nginx Service 10.98.171.178   k8s1 8080
kubectl get pod -o wide
kubectl get svc
kubectl get deployment

 

 

现象

1、mars1、mars2、mars3 三个 Pod 访问 nginx-app-57679cfb75-6z8nq 这个 Pod 的 80 端口是正常的

kubectl exec mars1 -- nc -v -z -w 5 10.244.0.19 80
kubectl exec mars2 -- nc -v -z -w 5 10.244.0.19 80
kubectl exec mars3 -- nc -v -z -w 5 10.244.0.19 80

 

 2、mars1 不能访问 nginx 这个 Service 的 8080 端口,mars2、mars3 可以访问 nginx 这个Service 的 8080 端口

kubectl exec mars1 -- nc -v -z -w 5 10.98.171.178 8080
kubectl exec mars2 -- nc -v -z -w 5 10.98.171.178 8080
kubectl exec mars3 -- nc -v -z -w 5 10.98.171.178 8080

 

 3、多次尝试后,发现当两个 Pod 处于同一个 Node 节点时,就不能通过 Service 的 IP+端口互访 

即如果把 nginx 的 Pod 调度到 k8s2 节点的话,就会变成 mars2 不能访问 10.98.171.178:8080,调度到 k8s3 节点的话,mars3 不能访问 10.98.171.178:8080。

 

排查过程

1、首先在 Google 、百度上面各种查,大多数的文章主要是针对 kubelet 的 hairpinMode 配置,该配置必须设置为 hairpin-veth 或者 promiscuous-bridge,查看了一下,我当前的配置是 hairpinMode: promiscuous-bridge,没有问题,尝试修改为 hairpin-veth 并重启 kubelet ,问题依旧。

#在所有 Node 节点执行
sed -i 's/hairpinMode: promiscuous-bridge/hairpinMode: hairpin-veth/' /var/lib/kubelet/config.yaml
systemctl restart kubelet

 

2、同时需要 /sys/devices/virtual/net/docker0/brif/veth-xxx/hairpin_mod 内容设置为1,查了配置已经均为1,没有问题。

 

3、尝试把 kube-proxy 的运行模式改为 iptables 并重启 kube-proxy ,问题依旧。

 

4、没办法之下只能抓包分析,由于一开始使用的镜像是 nginx官方镜像、busybox官方镜像,不方便进行抓包,于是自行用 centos 的官方镜像安装了一些测试工具进行调试,上面的 mars1、mars2、mars3、nginx-app 都是使用该镜像生成的。

     (1)首先看看正常访问的抓包结果:在 mars2 及 nginx-app-57679cfb75-6z8nq 上面抓包(两者在不同的 Node 节点上),mars2 上面使用自身的 IP为条件,nginx-app-57679cfb75-6z8nq 上面使用 80 端口为条件,然后在 mars2 上面使用 nc 命令访问 nginx 这个 Service 的 8080 端口,结果如下:

mars2 的抓包结果

tcpdump -vnn -i eth0 host 10.244.2.31

 

   nginx-app-57679cfb75-6z8nq 的抓包结果

tcpdump -vnn -i eth0 port 80

 

       可以看到,在 mars2 上面是自身的随机端口访问 Service 的 8080 端口,然后收到了 Service 的返回,正常建立了 TCP 三次握手。

       而在 nginx-app-57679cfb75-6z8nq 上面,可以看到源 IP 是 mars2 的 Pod  IP,也就是说,Service 只是对访问的流量进行了 DNAT,没有做 SNAT,但这样的话为什么 nginx-app-57679cfb75-6z8nq 直接给 mars2 的 Pod IP 回包,而 mars2 收到的包的源 IP 却又变成了 Service 的 IP 呢,我理解是因为 mars2 和 nginx-app-57679cfb75-6z8nq 不在同一个 Node 节点上,所以回包会经过网关 10.244.0.1 ,而网关会自动做一次回包的 SNAT ,把 nginx-app-57679cfb75-6z8nq 的 IP 转成 Service 的 IP,所以 mars2 收到的回包源 IP 就变成了 Service 的 IP。

     到了这里,问题的答案似乎已经呼之欲出了,接下来进行第二个抓包试验。

 

     (2)再来看看访问不正常的抓包结果:在 mars1 及 nginx-app-57679cfb75-6z8nq 上面抓包(两者在相同的 Node 节点上),mars1 上面使用自身的 IP为条件,nginx-app-57679cfb75-6z8nq 上面使用 80 端口为条件,然后在 mars1 上面访问 nginx 这个 Service 的 8080 端口,结果如下:

 mars1 的抓包结果

tcpdump -vnn -i eth0 host 10.244.0.18

 

   nginx-app-57679cfb75-6z8nq 的抓包结果

tcpdump -vnn -i eth0 port 80

  

      以上两个截图进一步验证了我的猜想, 原因就在于 Service 没有对访问它的流量做 SNAT ,nginx-app-57679cfb75-6z8nq 直接以 mars1 的 Pod IP 为目标 IP ,以自身的 Pod IP 为源 IP 进行回包。而由于两者是在同一个 Node 节点,处于同一个子网,走的是二层通信,没有经过网关,也不会有 NAT 转换。mars1 其实是已经接收到了 nginx-app-57679cfb75-6z8nq 的回包,但因为回包的源 IP+端口(10.244.0.19:80)和它发出去的请求的目标 IP+端口(10.98.171.178:8080)不一致,直接把包丢弃了。

 

      既然问题的原因已经找到了,那么解决的方向就是如何让 Service 对访问它的流量做 SNAT 。又经过一番排查,发现了 kube-proxy 有一个配置项 masqueradeAll ,当前的配置为 false 。

 

      根据字面意思,是把流量进行伪装,这不就是 iptables 里面的 MASQUERADE 吗,又找了 google 爸爸,查到这个配置项的作用:

masquerade-all 如果使用纯 iptables 代理,对所有通过集群 Service IP发送的流量进行 SNAT(通常不配置)

      看起来就是我要的结果,把配置文件里面的值改成 true 并重启 kube-proxy。

#在所有 Node 节点执行
sed -i 's/masqueradeAll: false/masqueradeAll: true/' /var/lib/kube-proxy/config.yaml
systemctl restart kube-proxy

 

      在 mars1 及 nginx-app-57679cfb75-6z8nq 上面重新抓包,mars1 上面使用自身的 IP为条件,nginx-app-57679cfb75-6z8nq 上面使用 80 端口为条件,然后在 mars1 上面访问 nginx 这个 Service 的 8080 端口,结果如下:

 mars1 的抓包结果

tcpdump -vnn -i eth0 host 10.244.0.18

 

 nginx-app-57679cfb75-6z8nq 的抓包结果

tcpdump -vnn -i eth0 port 80

 

       根据以上截图,可以看到,这次 mars1 正常建立了 TCP 三次握手,因为收到了 Service 的回包。另外,nginx-app-57679cfb75-6z8nq 上面看到访问的源 IP 变成了 mars1 的网关(10.244.0.1),所以 Service 针对访问它的流量做了 SNAT+DNAT,准确来说是做了 MASQUERADE ,nginx-app-57679cfb75-6z8nq 回包的时候就不会产生之前的 IP+端口不对应的问题了。同时测试了 mars2、mars3 都可以正常访问 Service。

 

总结

       这种故障主要出现在 Kubernetes 集群里面应用间需要通过 Service 的 IP 或者域名互访的场景,如果集群里面的应用只提供给外部访问,是不会有这种问题存在的。如果 nginx 是多个 Pod 的话,可能不容易发现,只会出现偶尔访问不通的情况,排查的时候最好只保留一个 Pod 。

       这个故障排查了好几天,主要耗费时间的地方在于一直想在网上找到现成的解决办法,而一直找不到。其实抓包分析是很基础的排查方法,但由于是容器环境,镜像里面难免会缺少一些必要的工具/命令,这时候我们就需要一个方便用于排查问题的镜像。其实自己制作一个适合自己使用的镜像并非难事,对于日常问题的排查还是非常有用的。

 

 

 

posted @ 2020-08-31 15:45  面壁者的逻辑  阅读(504)  评论(0编辑  收藏