Kubernetes环境下TCP RST原因排查：基于Wireshark捕获分析

问题背景 #

在Kubernetes集群中，Pod A向Pod B发起连接请求时，收到来自Pod B侧的TCP RST重置包，现基于客户端Pod A内捕获的Wireshark包分析原因，并给出后续排查方向。

网络拓扑 #

POD A (10.244.0.109)-- service A (10.103.61.120) -----------TCP通道--------- service B (10.111.125.227) -- POD B (10.244.0.133)

客户端Pod A捕获的RST包详情 #

43781   2023-08-24 07:05:17.182965  0.000032    10.111.125.227  10.244.0.109    TCP 56  64  4560 → 39868 [RST] Seq=1 Win=0 Len=0

帧43781：线上56字节（448比特），捕获56字节（448比特）
封装类型：Linux cooked-mode捕获v1（25）
到达时间：2023年8月24日 12:35:17.182965000 印度标准时间
[此数据包的时间偏移：0.000000000秒]
纪元时间：1692860717.182965000秒
[与前一个捕获帧的时间差：0.000032000秒]
[与前一个显示帧的时间差：0.000032000秒]
[与参考帧或第一帧的时间差：1866.143300000秒]
帧编号：43781
帧长度：56字节（448比特）
捕获长度：56字节（448比特）
[帧已标记：否]
[帧已忽略：否]
[帧中的协议：sll:ethertype:ip:tcp]
[着色规则名称：TCP RST]
[着色规则字符串：tcp.flags.reset eq 1]
Linux cooked捕获v1
    数据包类型：单播到本机（0）
    链路层地址类型：以太网（1）
    链路层地址长度：6
    源地址：ba:72:a7:1d:e4:65 (ba:72:a7:1d:e4:65)
    未使用：0000
    协议：IPv4（0x0800）
互联网协议版本4，源：10.111.125.227，目的：10.244.0.109
    0100 .... = 版本：4
    .... 0101 = 头部长度：20字节（5）
    差分服务字段：0x00（DSCP: CS0，ECN: 不支持ECT）
        0000 00.. = 差分服务代码点：默认（0）
        .... ..00 = 显式拥塞通知：非ECN-capable传输（0）
    总长度：40
    标识：0x0000（0）
    010. .... = 标志：0x2，不分片
        0... .... = 保留位：未设置
        .1.. .... = 不分片：已设置
        ..0. .... = 更多分片：未设置
    ...0 0000 0000 0000 = 分片偏移：0
    生存时间：64
    协议：TCP（6）
    头部校验和：0xa71d [验证已禁用]
    [头部校验和状态：未验证]
    源地址：10.111.125.227
    目的地址：10.244.0.109
传输控制协议，源端口：4560，目的端口：39868，Seq: 1，Len: 0
    源端口：4560
    目的端口：39868
    [流索引：379]
    [会话完整性：不完整（40）]
    [TCP段长度：0]
    序列号：1    （相对序列号）
    序列号（原始）：937229753
    [下一个序列号：1    （相对序列号）]
    确认号：0
    确认号（原始）：0
    0101 .... = 头部长度：20字节（5）
    标志：0x004（RST）
        000. .... .... = 保留位：未设置
        ...0 .... .... = 精确ECN：未设置
        .... 0... .... = 拥塞窗口减少：未设置
        .... .0.. .... = ECN-Echo：未设置
        .... ..0. .... = 紧急：未设置
        .... ...0 .... = 确认：未设置
        .... .... 0... = 推送：未设置
        .... .... .1.. = 重置：已设置
            [专家信息（警告/序列号）：连接重置（RST）]
                [连接重置（RST）]
                [严重级别：警告]
                [组：序列号]
        .... .... ..0. = 同步：未设置
        .... .... ...0 = 结束：未设置
        [TCP标志：·········R··]
    窗口大小：0
    [计算出的窗口大小：0]
    [窗口大小缩放因子：-1（未知）]
    校验和：0x390b [未验证]
    [校验和状态：未验证]
    紧急指针：0
    [时间戳]
        [此TCP流中与第一帧的时间差：0.000032000秒]
        [此TCP流中与前一帧的时间差：0.000032000秒]

基于当前捕获包的分析 #

从提供的单个RST包仅能得到以下有限信息：

1. RST包来自Service B的集群IP（10.111.125.227），目标为Pod A的IP（10.244.0.109），对应端口为Pod A发起端口39868和Service B的4560端口。
2. 包的相对序列号为1、确认号为0，说明该RST并非对已建立连接的响应，更可能是目标端（Pod B或Service B）无法识别当前连接请求的序列号，或Pod B的4560端口未处于监听状态。
3. 会话完整性标记为“不完整”，说明Wireshark仅捕获到RST包，未捕获到前置的SYN请求包，无法确认SYN是否正常到达目标端，也无法判断目标端是直接拒绝SYN还是在其他阶段触发重置。

后续排查方向 #

仅靠当前包无法精准定位原因，需补充数据并从多维度排查：

• 补充全链路抓包：
  • 在Pod A中捕获从SYN发起开始的完整TCP流，确认SYN包是否正常发出、是否收到SYN-ACK响应。
  • 在Pod B中抓包，验证是否收到来自Pod A的连接请求，以及Pod B内核/应用层的处理行为。
  • 在Service B所在节点抓包，排查Service流量转发是否正常。
• 验证Pod B端口监听状态：
  • 进入Pod B执行ss -tulpn或netstat -tulpn，确认4560端口是否有进程监听。
  • 检查Pod B应用日志，确认应用是否正常启动、端口配置是否正确。
• 直接测试Pod间连通性：
  • 在Pod A中ping Pod B的IP（10.244.0.133），确认底层网络可达。
  • 使用telnet 10.244.0.133 4560或nc -zv 10.244.0.133 4560绕过Service，直接验证Pod间端口连通性。
• 检查Kubernetes Service配置：
  • 确认Service B的spec.ports中targetPort是否与Pod B实际监听端口一致，port是否为4560。
  • 检查Service B的selector是否正确匹配Pod B的标签，确保流量能正确转发到目标Pod。
• 排查网络策略与防火墙规则：
  • 检查集群中是否有NetworkPolicy限制Pod A到Pod B的流量。
  • 查看节点上的iptables/ipvs规则，确认Service B的转发规则是否正确，是否有DROP/REJECT规则拦截流量。
• 检查内核TCP栈配置：
  • 查看Pod B所在节点的内核参数（如net.ipv4.tcp_syncookies、net.ipv4.tcp_max_syn_backlog），确认是否因SYN队列溢出导致重置。
  • 检查Pod B网络命名空间内的TCP相关配置，是否存在异常限制。

内容的提问来源于stack exchange，提问作者myquest9 sh