K8s为啥要启用bridge-nf-call-iptables内核参数？用案例给你讲明白(2)

• 如果正确转发，响应没有返回也可能导致超时

第一种可能性很容易排查，之前已经确认了 ipvs 规则、iptables 规则都是没有问题的，且通过 ClusterIP 发起的请求可以到达 PodIP 上, 基本就排除了可能性一

另外，对比正常跟异常请求会发现，异常的请求原 Pod 跟目标 pod 都是在同一个 Node 上，而正常的请求则处于不同的 Node，会是这个影响吗？

上面的可能性二，只能祭出抓包神器了tcpdump, 通过抓包发现(抓包过程见文未)会发现请求中出现了Reset

那么问题转换一下: 为什么相同 Node 上 podA 通过 service/ClusterIP 访问 PodB 响应会不返回呢，而通过 PodIP 访问就没问题？

补充一句就是，相同 Node 上的 pod 相互访问是不需要经过 Flannel 的，因此 Flannel 可以排除嫌疑

so, 问题在哪?

回到 tcpdump 的抓包数据, 可以发现，响应的数据没有按照请求的路径返回，嗯，Interesting

3、罪魁祸首

---

不管是 iptables 还是 ipvs 模式，Kubernetes 中访问 service 都会进行 DNAT，将原本访问 ClusterIP:Port 的数据包 DNAT 成 service 的某个 Endpoint (PodIP:Port)，然后内核将连接信息插入 conntrack 表以记录连接，目的端回包的时候内核从 conntrack 表匹配连接并SNAT，这样原路返回形成一个完整的连接链路.

从 tcpdump 看到请求被 reset 了, 没错, bridge-nf-call-iptables(如果是 ipv6 的话则是net.bridge.bridge-nf-call-ip6tables)参数

但是不对，这个参数 linux 默认开启的呢?难道是有人修改了么？

使用命令查看该参数是否开启:

$ cat /proc/sys/net/bridge/bridge-nf-call-iptables

# 0

返回 0，说明确实没有开启(后来被证实是被同事修改了)，那这个参数是如何影响的返回路径的呢?

那就不得不说linux bridge了！

虽然 CNI 使用的是 flannel, 但 flannel 封装的也是 linux bridge，linux bridge 是虚拟的二层转发设备，而 iptables conntrack 是在三层上，所以如果直接访问同一网桥内的地址(ip 同一网段)，就会直接走二层转发，不经过 conntrack:

结合上面的图来看，同 Node 通过 service 访问 pod 的访问路径如下：

PodA 访问 service, 经过 coreDNS 解析成 Cluster IP，不是网桥内的地址(ClusterIP 一般跟 PodIP 不在一个网段)，走 Conntrack,进行 DNAT，将 ClusterIP 转换成 PodIP:Port

• DNAT 后发现是要转发到了同节点上的 PodB，PodB 回包时发现目的 IP(此时是 PodA 的 IP) 在同一网桥上(PodA 与 PodB 的 IP 段一致)，就直接走二层转发了，不会去调 conntrack，这样就导致回包时没有原路返回

没有返回包就导致请求方一直等直到超时退出.

这样也解释了为何访问在其它节点的应用的 ClusterIP 没有问题，因为目标 PodIP 与源 PodIP 不在同一个网段上,肯定要走 conntrack.

4、问题解决

---

总述，开启参数后问题解决

$ echo “net.bridge.bridge-nf-call-iptables=1” >> /etc/sysctl.conf

$ echo “net.bridge.bridge-nf-call-ip6tables=1” >> /etc/sysctl.conf

$ sysctl -p /etc/sysctl.conf

5、linux conntrack

---

关于 conntrack 其实也是个值得好好研究一番的知识点, 各个发行版都有工具可以看到 conntrack 里的记录,格式如下:

$ conntrack -L

tcp 6 119 SYN_SENT src=10.224.1.34 dst=10.233.53.172 sport=56916 dport=8080 [UNREPLIED] src=10.224.1.56 dst=10.224.1.34 sport=8080 dport=56916 mark=0 use=1

那个著名的DNS 5s timeout[1]的问题就跟 conntrack 机制有关，由于篇幅有限，就不在这里展开.

6、tcpdump

---

在容器中的抓包命令

$ tcpdump -vvv host 10.224.1.34 or 10.233.53.172 or 10.224.1.56

其中的三个 ip 分别对应 podA IP, podB 的 ClusterIP, podB 的 PodIP

这里由于篇幅的关系，只保存有关键信息，同时使用注释是作者加入的，方便理解.

对于异常请求的 tcpdump，如下:

# podA 请求 PodB

panorama-frontend-deploy-c8f6fd4b6-52tvf.45954 > panorama-v2-frontend-service.spring-prod.svc.cluster.local.8080: Flags [S], cksum 0x4cc5 (incorrect -> 0xba1b), seq 1108986852, win 28200, options [mss 1410,sackOK,TS val 1345430037 ecr 0,nop,wscale 7], length 0

10-224-1-56是PodB的podIP, 这里省略了解析过程,可以看到返回数据给PodA

10-224-1-56.panorama-v2-frontend-service.spring-prod.svc.cluster.local.8080 > panorama-frontend-deploy-c8f6fd4b6-52tvf.45954: Flags [S.], cksum 0x1848 (incorrect -> 0x99ac), seq 3860576650, ack 1108986853, win 27960, options [mss 1410,sackOK,TS val 2444502128 ecr 1345430037,nop,wscale 7], length 0

重点: podA直接reset了请求.

panorama-frontend-deploy-c8f6fd4b6-52tvf.45954 > 10-224-1-56.panorama-v2-frontend-service.spring-prod.svc.cluster.local.8080: Flags [R], cksum 0xb6b5 (correct), seq 1108986853, win 0, length 0

最后会发现 PodA 给 PodB 发送了个R Flags, 也就是reset, 就是因为当 PodB 返回握手确认给到 PodA，PodA 根本不认识这个请求，所以直接给 reset 掉了, 三手握手都没有建立，this is why!

而对于net.bridge.bridge-nf-call-iptables=1的正常请求的 tcpdump 如下:

能看到正常的三次握手， 这里省略

开启传输数据

panorama-frontend-deploy-c8f6fd4b6-52tvf.36434 > panorama-v2-frontend-service.spring-prod.svc.cluster.local.8080: Flags [P.], cksum 0x4d3c (incorrect -> 0x6f84), seq 1:128, ack 1, win 221, options [nop,nop,TS val 1346139372 ecr 2445211463], length 127: HTTP, length: 127

GET / HTTP/1.1

Host: panorama-v2-frontend-service.spring-prod.svc.cluster.local:8080

User-Agent: curl/7.52.1

Accept: /

panorama-v2-frontend-service.spring-prod.svc.cluster.local.8080 > panorama-frontend-deploy-c8f6fd4b6-52tvf.36434: Flags [.], cksum 0x4cbd (incorrect -> 0xe8a6), seq 1, ack 128, win 219, options [nop,nop,TS val 2445211463 ecr 1346139372], length 0

panorama-v2-frontend-service.spring-prod.svc.cluster.local.8080 > panorama-frontend-deploy-c8f6fd4b6-52tvf.36434: Flags [P.], cksum 0x4dac (incorrect -> 0x0421), seq 1:240, ack 128, win 219, options [nop,nop,TS val 2445211463 ecr 1346139372], length 239: HTTP, length: 239

HTTP/1.1 200 OK

Server: nginx/1.17.1

Date: Wed, 18 Aug 2021 15:10:17 GMT

Content-Type: text/html

Content-Length: 1540

Last-Modified: Fri, 09 Jul 2021 06:36:53 GMT

Connection: keep-alive

ETag: “60e7ee85-604”

Accept-Ranges: bytes

相信这个请求路径还是很清晰的，就不再啰嗦.

7、结语

---

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

分享

1、算法大厂——字节跳动面试题

2、2000页互联网Java面试题大全

3、高阶必备，算法学习

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

[外链图片转存中…(img-akajZl4E-1713337652781)]

2、2000页互联网Java面试题大全

[外链图片转存中…(img-ENwHQU7r-1713337652781)]

3、高阶必备，算法学习

[外链图片转存中…(img-wxAyZRqv-1713337652781)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！