前言

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

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

环境信息

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 爸爸，查到这个配置项的作用：

      看起来就是我要的结果，把配置文件里面的值改成 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 。

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

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