Calico IPIP 与 kube-proxy IPVS 包路径核查
本页提炼原笔记中的观察位置，供分析特定网络模式时建立假设。路径和命令未在目标集群验证；不能把它套用到 eBPF 代理、VXLAN、无隧道或其他 CNI。
先确认两种不同的转换
在原笔记假设的环境里，Service 数据面负责从虚拟 Service 地址选出后端；Calico 提供 Pod 接口、节点路由和可能的跨节点 IPIP 传输。Calico 的 CNI 插件负责 Pod 建网，Felix、路由组件和内核数据面各有不同职责，不能将每个数据包动作统称为“CNI 执行”。IPVS 模式仍可能借助 iptables 处理部分 Service 流量。
外部请求经过 Ingress 时至少要区分两段连接：客户端 → Ingress，以及 Ingress → 上游服务。Ingress 是否直连后端 Pod、访问 Service 地址或采用其他上游方式，取决于控制器配置；原笔记的“直接连接 Pod IP”只是一个待核查场景。
逐段看什么
| 观察位置 | 在该假设下可回答的问题 |
|---|---|
| 入站节点的物理网卡 | 请求是否到达 NodePort，以及负载均衡器转发后的目标地址是什么？ |
| Ingress Pod 的网络接口 | 第一段连接是否进入控制器；控制器发出的第二段连接指向哪里？ |
| 源节点的 Pod veth 和路由表 | Pod 流量是否交给宿主机，以及所选后端对应哪条路由？ |
tunl0 与物理网卡 | 跨节点路径是否确实使用 IPIP；隧道内层是 Pod 地址、外层是节点地址吗？ |
| 目标节点的 Pod veth | 解封装后的流量是否投递给目标 Pod？ |
同节点 Pod 互访通常无需跨节点隧道。跨节点访问 Service 时，应先确认实际 EndpointSlice，再检查 Service 转换、到所选后端的路由和隧道；回包还需核对连接跟踪和源地址转换。原笔记把这些路径画在一起，排障时应按每一段真实连接分别取证。
原笔记的待核查点
- 文中同时使用 IPVS 假设和 iptables 模式的
KUBE-SVC/KUBE-SEP逐跳图，不能直接把链名与 Netfilter 钩子顺序当作 IPVS 模式实测结果。 - “外部流量总会 SNAT”“后端总能看到某种源 IP”取决于
externalTrafficPolicy、入口和网络实现；不能无条件套用。 - “物理 MTU 1500、IPIP 开销 20 字节，所以 Pod MTU 必须 1480”只描述单层 IPv4 IPIP 的估算，仍需核对链路 MTU 与其他封装。
- 原文的 IPVS 性能阈值和复杂度数字没有测试条件或出处，暂不纳入结论。
关联：网络与 CNI 模块给出全局主题；Service 不通可承接具体现象。