• Trying 10.233.53.172…

• TCP_NODELAY set

• Connected to panorama-v2-frontend-service.spring-prod.svc.cluster.local (10.233.53.172) port 8080 (#0)

GET / HTTP/1.1

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

User-Agent: curl/7.52.1

Accept: /

< HTTP/1.1 200 OK

2、排查过程

---

先对异常 Node 进行排查，因为其它节点是正常的,通过对异常 Node 的网络、kube-proxy、 iptables、ipvs 规则、kubelet 等排查后未发现有可疑的地方，就暂时排除嫌疑了。

第二个可疑的是 DNS, coreDNS 负责对 service 解析成 ClusterIP, 在出问题的 Node 上经过多次测试均能正确解析，coreDNS 排除嫌疑。

可疑的地方都筛了一遍,无果, 那就只能再从现象来发现看看有没有相同点。

首先，访问路径为：Service – > ClusterIP – > PodIP

对 service 访问异常，coreDNS 已经被排除了，那先绕过 service，直接使用 ClusterIP 访问呢? 测试后现象依旧。另外关注公号“终码一生”，回复关键词“资料”，获取视频教程和最新的面试资料！

那再绕过 ClusterIP，直接使用 PodIP 呢? Bingo，之前会出问题的访问都是正常的了。

那么问题就出在 CluterIP – > PodIP 上, 那么又有以下可能：

ClusterIP 没有正确转发到 PodIP 上可能导致超时

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

第一种可能性很容易排查，之前已经确认了 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，这样就导致回包时没有原路返回

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

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

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

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

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

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

写在最后

作为一名即将求职的程序员，面对一个可能跟近些年非常不同的 2019 年，你的就业机会和风口会出现在哪里？在这种新环境下，工作应该选择大厂还是小公司？已有几年工作经验的老兵，又应该如何保持和提升自身竞争力，转被动为主动？

就目前大环境来看，跳槽成功的难度比往年高很多。一个明显的感受：今年的面试，无论一面还是二面，都很考验Java程序员的技术功底。

最近我整理了一份复习用的面试题及面试高频的考点题及技术点梳理成一份“Java经典面试问题（含答案解析）.pdf和一份网上搜集的“Java程序员面试笔试真题库.pdf”（实际上比预期多花了不少精力），包含分布式架构、高可扩展、高性能、高并发、Jvm性能调优、Spring，MyBatis，Nginx源码分析，Redis，ActiveMQ、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多个知识点高级进阶干货！

由于篇幅有限，为了方便大家观看，这里以图片的形式给大家展示部分的目录和答案截图！

Java经典面试问题（含答案解析）

阿里巴巴技术笔试心得

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算

ecb71ac0)

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算