Troubleshooting Issue for Integrating Host to K8S

故障排查报告：`10.32.56.117` (K8s 节点) 与 `10.32.56.42` 通信失败

报告时间	2025 年 10 月 21 日
故障主机 (A)	`10.32.56.117` (`msr01vp` - Kubernetes 节点)
对端主机 (B)	`10.32.56.42`
初始症状	主机 B 无法 Ping 通主机 A (TCP/ICMP 流量失败)。
最终结论	L3 层的内核反向路径过滤 (RPF) 机制被触发。 `net.ipv4.conf.all.rp_filter` 参数设置过于严格，导致 Calico CNI 引入的复杂路由结构被内核错误地识别为 Martian Source (IP 欺骗)，从而丢弃了来自 `10.32.56.42` 的入站 IP 流量。 `IP冲突`
建议修复	将 `net.ipv4.conf.all.rp_filter` 和 `net.ipv4.conf.ens192.rp_filter` 设置为 `2` (宽松模式)。

一、排查时间线与过程分析

排查思路遵循了 网络层 (L2) -> 安全过滤 -> L3 路由 -> IP冲突 的顺序，逐步收窄范围。

阶段 I：L2 连通性确认 (ARP 协议排查)

时间线	使用工具 / 命令	观察到的现象 / 结果	阶段结论
T0: 链路层确认	`sudo tcpdump -eni ens192 arp`	观察到 ARP Request (`who-has 10.32.56.117 tell 10.32.56.42`) 成功到达 `10.32.56.117` 的 `ens192` 网卡。但 ARP Reply 未发出。	问题锁定在 `10.32.56.117` 本地系统。交换机和链路没有隔离。
T1: 内核参数检查	`sysctl net.ipv4.conf.all.arp_ignore` / `sysctl net.ipv4.conf.ens192.arp_ignore` / `sysctl net.ipv4.conf.all.arp_filter`	`all.arp_ignore = 1` (严格)；`ens192.arp_ignore = 0` (宽松)；`arp_filter = 0` (宽松)。	`arp_ignore=1` 成为首要嫌疑人，可能与 CNI 冲突。
T2: L2/L3 防火墙检查	`sudo ebtables -L` / `sudo iptables -t raw -L -v`	`ebtables` (L2 防火墙) 策略为 ACCEPT ，无规则。`iptables raw` (L3 早期过滤) 中无针对 ARP 的 `DROP` 规则。	排除所有标准软件防火墙拦截。
T3: CNI 组件确认	`calicoctl node status`	确认 `10.32.56.117` 是一台正在运行 Calico BGP CNI 的 Kubernetes 节点。	CNI 逻辑被确认为影响网络栈的关键因素。
T4: CNI 策略检查	`kubectl get hostendpoint -o yaml` / `kubectl get GlobalNetworkPolicy -o yaml`	两者均为空 (`items: []`)。	排除 Calico 网络策略拦截 ARP 响应的可能性。

阶段 II：L3 路由与内核日志分析 (根本原因定位)

时间线	使用工具 / 命令	观察到的现象 / 结果	最终结论
T5: 系统日志检查 (非侵入)	`sudo journalctl -k -r` (内核日志)	发现大量重复日志：`IPv4: martian source 10.32.56.117 from 10.32.56.42, on dev ens192`。	故障根源锁定：这是内核反向路径过滤 (RPF) 机制被触发的证据。问题不在于 ARP 响应本身，而在于随后的 IP 流量被 RPF 机制丢弃。
T6: 根本原因确定	（分析日志和内核原理）	RPF 机制（由 `rp_filter` 控制）在 Calico 复杂路由环境中将来自 `10.32.56.42` 的合法流量错误地标记为 Martian Source，并静默丢弃。	解决方案确定：必须修改 `rp_filter` 参数。
T7: K8S Service 策略检查	`kubectl get svc -A`	LoadBalancer 10.24.207.82 10.32.56.42	定位到 LoadBalancer Service 设置VIP。

二、涉及的系统组件、日志与配置

1. 涉及的关键 Linux 工具

工具名称	目的
`tcpdump`	实时捕获网络流量，用于确认 ARP Request 到达 (L2 验证)。
`sysctl`	查看和修改内核网络参数 (`arp_ignore`, `arp_filter`, `rp_filter`)。
`ebtables` / `iptables`	检查 L2/L3 防火墙规则，排除安全过滤拦截。
`journalctl`	查看系统和内核日志，最终发现 `Martian Source` 错误。
`kubectl` / `calicoctl`	检查 Kubernetes CNI 状态 (`calico-node` 运行状态) 和网络策略 (`HostEndpoint`)。

shell 复制代码

# 额外的命令
ping -c 1 10.32.56.117
ss -nltp |grep 6443
arping 10.32.56.42

# 检查SELinux状态
sestatus

ip addr show dev ens192

tcpdump -eni ens192  arp
tcpdump -eni vlan56  "icmp or arp"
tcpdump -eni vlan56  src 10.32.56.xx  or dst 10.32.56.xx

# 在 10.32.56.117 上执行
sudo iptables -t raw -L -v

# 或者直接清除 ARP 缓存并 ping
sudo arp -d 10.32.56.117

sudo journalctl --since "2 minutes ago" --until "now" -o verbose > /tmp/system.log

calicoctl node status

2. 关键日志片段 (最终证据)

日志来源	日志内容	含义
Kernel Log (`journalctl -k`)	`IPv4: martian source 10.32.56.117 from 10.32.56.42, on dev ens192`	决定性证据。内核 RPF 机制被触发，将来自 `10.32.56.42` 的 IP 流量视为非法数据包并丢弃。
`tcpdump` Output (Initial)	`Request who-has 10.32.56.117 tell 10.32.56.42`	证明 L2 请求成功到达主机 A。
`calicoctl` node status	`Calico process is running. [...] node-to-node mesh	up

网卡配置

bash 复制代码

ip addr show dev ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:xx:xx:xx:xx:88 brd ff:ff:ff:ff:ff:ff
    altname enp11s0
    inet 10.32.56.117/23 brd 10.32.57.255 scope global noprefixroute ens192
       valid_lft forever preferred_lft forever
    inet6 xx::xx:xx:xx:xx/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

操作系统日志

bash 复制代码

Tue 2025-10-21 17:04:49.220021 CST [s=27c31c427ac747bdb1e79fe70a7c48a3;i=8be592;b=4a9990ffd03743888cf36f0f7eabc964;m=2554b2ab5b41;t=641a77dfb29b5;x=2a9f9a597a6e15b2]
    _TRANSPORT=kernel
    PRIORITY=4
    SYSLOG_FACILITY=0
    SYSLOG_IDENTIFIER=kernel
    _BOOT_ID=4a9990ffd03743888cf36f0f7eabc964
    _MACHINE_ID=c668def169814c39979f8c3d86346086
    _HOSTNAME=msr01vp
    MESSAGE=IPv4: martian source 10.32.56.117 from 10.32.56.42, on dev ens192
    _SOURCE_MONOTONIC_TIMESTAMP=41045375854198

网络抓包

bash 复制代码

[root@msr01vp ~]# sudo tcpdump -eni ens192  arp
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
...
15:37:49.615002 04:32:01:cb:37:50 > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.32.56.117 tell 10.32.56.42, length 46
...
15:37:50.640166 04:32:01:cb:37:50 > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.32.56.117 tell 10.32.56.42, length 46
...
15:37:51.664159 04:32:01:cb:37:50 > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.32.56.117 tell 10.32.56.42, length 46

bash 复制代码

msr01vp ~]# calicoctl node status
Calico process is running.

IPv4 BGP status
+--------------+-------------------+-------+------------+-------------+
| PEER ADDRESS |     PEER TYPE     | STATE |   SINCE    |    INFO     |
+--------------+-------------------+-------+------------+-------------+
| 10.32.56.xx | node-to-node mesh | up    | 2025-07-23 | Established |
| 10.32.56.xx | node-to-node mesh | up    | 2025-07-23 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 2025-08-21 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 2025-08-20 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 2025-08-20 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 2025-08-19 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 2025-08-19 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 2025-08-14 | Established |
| 10.32.56.xx | node-to-node mesh | up    | 2025-07-23 | Established |
| 10.32.56.xx | node-to-node mesh | up    | 2025-07-23 | Established |
| 10.32.56.xx | node-to-node mesh | up    | 2025-07-23 | Established |
| 10.32.56.xx | node-to-node mesh | up    | 2025-07-23 | Established |
| 10.32.56.xx | node-to-node mesh | up    | 2025-07-23 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 2025-08-08 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 2025-08-08 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 2025-08-08 | Established |
| 10.32.56.xx  | node-to-node mesh | up    | 09:16:42   | Established |
+--------------+-------------------+-------+------------+-------------+

IPv6 BGP status
No IPv6 peers found.

3. 关键冲突参数

参数名称	原始值	冲突类型
`net.ipv4.conf.all.rp_filter`	预期为 `1` (严格模式)	直接冲突！在 Calico 复杂路由环境中，严格模式导致 RPF 检查失败。
`net.ipv4.conf.all.arp_ignore`	`1`	间接冲突。虽然不是直接原因，但严格的 `arp_ignore` 与严格的 `rp_filter` 共同作用，使 Calico 节点对外部通信变得极其脆弱。

三、最终结论与建议修复方案

结论

故障的根本原因是 L3 路由不对称 与 内核的严格反向路径过滤 (RPF) 机制的冲突，而不是简单的 L2 故障。Kubernetes 节点上的 Calico CNI 引入的 BGP 路由导致内核的 RPF 机制错误地认为来自同网段的流量是非法欺骗 (Martian Source)。

IP冲突

建议修复方案

将源主机修改成未使用的IP，源主机可以成接入到K8S并正常使用。

故障修复心得

这次排查历经 整整两天 的艰辛，是技术深度探寻、跨部门协作和个人坚持求真务态度的生动写照。

我们从最初 L2 ARP 故障的表象着手，通过网络抓包和细致的内核日志分析（journalctl 发现 Martian Source ），如同剥洋葱般层层深入，最终锁定了潜在的故障根源------内核 RPF 机制被错误触发。

整个过程不仅成功排除了所有常见的网络和安全策略因素，更重要的是，它极大地加深了我们对以下核心技术的理解：

ARP 协议 (L2)：理解了 ARP 请求成功到达但 ARP 响应未发出的本地化问题。
内核网络栈行为 (RPF) ：理解了 Martian Source 错误及其与 rp_filter 参数的严格耦合关系。
Calico CNI 机制：理解了复杂 CNI 环境（如 BGP 路由）如何与主机内核参数发生冲突。

这份坚持，是对技术严谨性的最好肯定。通过协调网络、操作系统和 Calico CNI 团队，我们不仅解决了当前问题，更成功地规避了未来因内核参数冲突而可能引发的系统级故障，促进了跨部门的信任与协作。这证明了求真务实的态度和跨领域知识的结合，才是最高效、最根本的解决之道。

Troubleshooting Issue for Integrating Host to K8S

故障排查报告：10.32.56.117 (K8s 节点) 与 10.32.56.42 通信失败

一、排查时间线与过程分析

阶段 I：L2 连通性确认 (ARP 协议排查)

阶段 II：L3 路由与内核日志分析 (根本原因定位)

二、涉及的系统组件、日志与配置

1. 涉及的关键 Linux 工具

2. 关键日志片段 (最终证据)

3. 关键冲突参数

三、最终结论与建议修复方案

结论

建议修复方案

故障修复心得

故障排查报告：`10.32.56.117` (K8s 节点) 与 `10.32.56.42` 通信失败