Calico IPIP模式深度解析：跨网段Pod通信的隧道原理与排障指南

做 Kubernetes 网络排障的同行应该都有同感：跨节点 Pod 通信的坑永远离不开 MTU、路由、overlay 这三个关键词。今天要聊的 Calico IPIP 模式，属于网络方案里那个"装完默认就能跑、但很多人没完全读懂"的类型。如果你集群里存在跨网段节点，或者你正在纠结为什么 Pod 之间偶尔不通、大包 ping 总是断断续续，那这篇应该能帮你把 Calico IPIP 从"能用"变成"懂用"。

Calico 是 Kubernetes 生态里最流行的 CNI 插件之一，核心思路是三层路由而非 overlay 转发。但纯 BGP 直连有一个前提：节点之间必须在同一个二层网络。一旦节点分布在不同的网段或机房，路由信息能通过 BGP 传递，数据包却没法直接送过去。这时候 IPIP 隧道模式就派上用场了。这篇文章我会从原理、配置、排障三个角度，把 IPIP 模式里里外外讲清楚，最后再给出生产环境的选型建议。

1. 为什么需要 IPIP：先看懂 Calico 的三种网络模式

1.1 BGP 直连：最理想但依赖物理网络

Calico 的默认设计思路是放弃 overlay，直接用三层路由转发 Pod 流量。每个节点上的 Felix 负责维护路由和 iptables，BIRD 负责把 Pod 网段路由通过 BGP 协议广播给其他节点。这样两个 Pod 通信时，数据包就是一次普通的三层路由转发，没有额外的隧道封装，也没有 NAT，转发路径短，性能损耗小。

但这套方案有个隐藏前提：所有 Calico 节点必须在同一个二层网络里。为什么？因为 BGP 路由只能告诉你"目标 Pod 在哪台节点上"，而真正的数据转发还需要知道"到达那台节点下一跳的 MAC 地址是什么"。这个 MAC 地址只能靠 ARP 在二层广播里拿到。如果两台节点跨了网段，中间隔着一台路由器，ARP 就拿不到对端 MAC，数据包发到默认网关后，网关要么不知道怎么转发、要么需要额外配置才能把流量送出去。

我见过不少团队在刚开始搭集群时，节点全在同一个交换机下，Calico 默认模式跑得很欢。后来扩容加了几个别的网段的节点，新节点上的 Pod 能创建，但和旧节点 Pod 通信就时好时坏，抓包一看全是 ARP 请求没人应答。核心问题就是二层不通。

1.2 IPIP 隧道：给跨网段通信开一条"隧道"

IPIP 模式解决的就是上面这个跨网段问题。它的思路很直接：既然底层二层网络不连通，那就把 Pod 流量封装起来，通过节点的三层网络（也就是 IP 网络）来传输。每一份原始的 Pod 数据包外面，再套一层新的 IP 头，新 IP 头的源地址、目的地址分别是两个节点的 IP。这样数据包到了节点 A 的物理网卡之后，就是一份可以在三层网络里正常路由的普通 IP 包，节点 B 收到后再剥掉外层头，还原成原始的 Pod 数据包继续转发。

在 Calico 里，IPIP 有两种触发方式，通过 IPPool 的 ipipMode 字段控制：

• Always：所有跨节点的 Pod 流量都走隧道封装
• CrossSubnet：只有跨网段节点之间的流量才封装，同网段节点之间走 BGP 直连
• Never：永远不封装

我强烈建议生产环境用 CrossSubnet，既能享受同网段节点之间的直连高性能，又能保证跨网段节点的连通性。之前遇到有人把整个集群配成 Always，集群规模一大，所有流量都过隧道，CPU 白白烧在封装解封装上，完全没有必要。

1.3 IPIP vs VXLAN：都是隧道，差异化很大

Calico 除了 IPIP 还支持 VXLAN 模式，很多初学者会混淆这两个概念。它们都是 overlay 隧道方案，但底层封装格式完全不一样。IPIP 是在内层 IP 包外面直接再套一个 IP 头，协议号是 4，封装开销是 20 字节。VXLAN 则是把原始二层帧封装在 UDP 里，外面再套 IP 头，封装开销按标准计算约为 50 字节（VXLAN 头 8 字节、UDP 头 8 字节、外层 IP 头 20 字节，再加上外层以太头 14 字节）。

开销差异直接反映在 MTU 上。节点网卡的 MTU 默认是 1500，走 IPIP 隧道时 Pod 网卡的 MTU 得降到 1480，走 VXLAN 则要降到 1450 左右。别小看这几十字节的差异，在大流量传输场景下会影响分片行为和吞吐表现。IPIP 的封装逻辑也更简单，数据包进入 tunl0 设备时，内核只需要追加一个 IP 头，不需要查 UDP 端口、不需要处理外层 MAC 地址。VXLAN 多了一层 UDP 和以太封装，处理路径更长，CPU 开销相对更高。所以在同样硬件条件下，IPIP 模式的理论性能通常优于 VXLAN。

2. IPIP 模式的核心原理：数据包是怎么完成"套娃"的

2.1 一条完整的数据包旅行路径

先看一个具体场景。集群里有两个节点：node1 的 IP 是 192.168.1.10，node2 的 IP 是 192.168.2.20，两个节点不在同一个网段。Pod A 运行在 node1 上，IP 是 10.244.1.5，Pod B 运行在 node2 上，IP 是 10.244.2.8。Pod A 要访问 Pod B 的 80 端口。

Pod A 发出请求，数据包首先到达 node1 的 veth 对端，经过内核路由查找。node1 上的路由表里有一条由 Calico 写好的路由，大约长这样：

10.244.2.0/24 via 192.168.2.20 dev tunl0 proto bird scope link

目的网段正好匹配，数据包被送到 tunl0 这个隧道设备。在这里，内核做的第一件事是封装：在原始 IP 包外面加一个外层 IP 头，源地址填 node1 的 IP 192.168.1.10，目的地址填 node2 的 IP 192.168.2.20，外层头的协议字段填 4，也就是 IP-in-IP。封装完成后，数据包又从 tunl0 出来，进入 node1 物理网卡 eth0 的发送队列，按照普通 IP 包的路由规则发送到默认网关。

node2 的 eth0 收到这个包后，看到协议号是 4，就会把它交给内核的 IPIP 协议栈处理，也就是解封装：剥掉外层 IP 头，还原出原始的 Pod 数据包。然后根据内层 IP 包的目的地址 10.244.2.8，查找 node2 的路由表，发现目标网段 10.244.2.0/24 的下一跳就是本机的 Pod 网卡，于是直接通过 veth 送进 Pod B。

全程下来，对应用层是透明的：Pod A 完全不知道自己经过了隧道封装，Pod B 也看不到外层 IP 头。整个封装、解封装过程都发生在 Linux 内核里，不需要额外部署代理进程，这是 Calico 的 IPIP 性能天然优于纯用户态方案的原因。

2.2 IPIP 为什么不改变路由决策

这里有个很容易被误解的点：很多人以为 IPIP 是"把数据包塞进一条隧道然后再做二次路由"，其实不是这样。在 IPIP 模式下，路由决策只有一次，数据包在进入 tunl0 之前，就已经按照内层 IP 包的目的地址完成了原本的路径查找，只是这条路径的出口设备是 tunl0 而不是 eth0。封装只是把已经选好路径的包再包一层，外层目的地址直接写节点 IP，不需要再走一遍完整的路由表。

这也解释了为什么 IPIP 模式下，tunl0 路由的 scope 通常是 link，因为隧道对端就是从路由表里拿到的下一跳信息。BIRD 在广播路由时，不仅广播了 Pod 网段，还携带了下一跳信息，也就是对端节点 IP。tunl0 就负责把包原样封装后发给这个节点 IP。

理解这一点对排障很重要。当网络不通时，你不需要先去怀疑隧道协商有没有成功（IPIP 无状态、无握手），而是应该先查路由表里有没有对应的隧道路由，再看节点的物理网络是否连通。这也是我排障时优先执行ip route show dev tunl0而不是去查各种隧道状态的原因。

2.3 MTU 问题为什么绕不开

隧道封装压缩了可用 MTU，这是所有 overlay 方案的宿命。节点网卡默认 MTU 是 1500，IPIP 封装要给每个包额外加 20 字节外层 IP 头。如果 Pod 网卡 MTU 仍然配成 1500 以上，就会出现一个问题：原始数据包已经接近物理链路极限，加上外层头后超出允许范围，只能在发送端分片。

分片本身不是大问题，很多 TCP 流量都能正确处理。真正头疼的是 DF 标志（Don't Fragment）的报文。部分应用为了探测路径 MTU，发出的探测包带了 DF 标志，这类包在超过 MTU 时不会分片，而是直接丢弃并向源端返回 ICMP Fragmentation Needed 报文。如果 ICMP 报文被安全组或者主机防火墙拦截，源端就永远不知道要减小包大小，连接会一直处于"发大包、丢包、重传、再丢包"的恶性循环里。

所以 Calico 在为容器设置 MTU 时，必须准确反映隧道开销。默认情况下 Calico 会根据 IPIP 模式自动把容器 veth 的 MTU 调整为 1480，不需要你手动改。但如果你用了其他网络插件或者手动调整过节点网卡 MTU，这里就会出现偏差。这也是排障时最常见的 Root Cause 之一。

3. 实操：在 Calico 中启用和配置 IPIP 模式

3.1 先确认当前集群的网络模式

动手配置之前，必须确认清楚现状。Calico 的网络模式定义在 IPPool 资源对象里，IPPool 是一份全局配置，决定了 Pod 网段的分配方式，也决定了流量怎么转发。查看方式：

calicoctl get ippool -o yaml

输出里重点关注 spec.ipipMode 字段。如果值是 Never，说明当前是纯 BGP 直连模式；如果是 CrossSubnet，说明已经启用了 IPIP 且只在跨子网时封装；如果是 Always，说明所有跨节点流量都在走隧道。

另外还要看一眼 FelixConfiguration，确认 IPIP 在 Felix 层级没有被人为关闭：

calicoctl get felixconfiguration default -o yaml

里面有个 ipipEnabled 字段，必须是 true 才会真正生效。IPIP 的生效链路是：IPPool 声明使用 IPIP 模式，Felix 在实际下发路由和配置 tunl0 设备时执行封装，两者缺一不可。

提示：有些发行版的 Calico manifest 默认就把 ipipMode 配成了 Always。如果你只有一个小型测试集群且所有节点同网段，建议改成 CrossSubnet，能在不影响功能的前提下降低封装开销。

3.2 以 CrossSubnet 为目标修改 IPPool 配置

假设你当前是 Never 模式，要切换到 CrossSubnet，直接修改默认 IPPool 就行。先导出当前配置：

calicoctl get ippool default-ipv4-ippool -o yaml > ippool.yaml

修改后的文件大概长这样：

apiVersion: projectcalico.org/v3 kind: IPPool metadata: name: default-ipv4-ippool spec: cidr: 10.244.0.0/16 ipipMode: CrossSubnet natOutgoing: true disabled: false

然后执行：

calicoctl apply -f ippool.yaml

Calico 的配置变更不需要重启任何组件。Felix 会监听 IPPool 资源的变更，自动调整节点上的路由表和 tunl0 设备。生效后你会看到节点路由表里多出了通过 tunl0 出接口的跨网段 Pod 路由。

这里有一个经验细节：修改 IPPool 前最好确认集群里所有节点已经具备物理连通性，尤其是新配置的跨网段节点。因为 IPIP 隧道本身不负责打通节点之间的物理网络，它只是在物理网络之上加了一层封装。如果两个节点连 ping 都失败，把 IPIP 改成 Always 也不会让通信恢复。

3.3 配置后必须做的三个验证

配置完别急着收工，验证要跟上。我通常按以下顺序检查三件事。

第一件事，确认 tunl0 设备存在：

ip addr show tunl0

Calico 会在启用了 IPIP 的节点上自动创建 tunl0，状态是 UNKNOWN 也算正常。如果这个设备不存在，说明 Felix 配置没下发成功，优先查 calico-node Pod 的日志。

第二件事，查路由表确认隧道路线：

ip route show dev tunl0

如果配置正确，能看见跨网段 Pod CIDR 的条目，并且 proto 是 bird 或者 Calico 相关标识。如果看到的 Pod 网段路由走的是 eth0 而不是 tunl0，说明路由选择和你预期不一致，需要检查节点间的 BGP peering 状态，用calicoctl node status查看。

第三件事，做一次真实的 Pod 通信测试。建议直接创建一个测试 Pod，或者用已有的业务 Pod，从 Pod A ping Pod B 的 IP。为了验证隧道是否真的在传输，可以在 node2 上抓包：

tcpdump -i eth0 -n 'ip proto 4'

如果 IPIP 生效，只要 Pod A 在访问 Pod B，node2 的物理网卡上就能抓到协议号为 4 的封装包。这一步能最直观地证明封装路径是通的。

3.4 生产环境推荐的微调参数

除了 ipipMode 本身，IPPool 里还有几个和生产场景强相关的参数值得花两分钟确认。一是 natOutgoing，它控制 Pod 访问集群外地址（比如访问互联网）时是否做 SNAT。二是 allowedUses，它能限制这个 IPPool 的网段能被哪些别的 IPPool 引用，用于高级的 IP 规划场景。三是 blockSize，它决定每个节点能分配到的 Pod 网段大小，默认是 128（对应一个 /25 子网），如果你的节点密度很大，比如单节点跑了 200 个以上的 Pod，建议调大一些。

我把这几个参数的生产建议整理成了表格：

注意：修改 blockSize 只对之后创建的 IPPool 生效，已经运行中的 Pod 不会受影响。所以这属于集群规划阶段就要想清楚的事，中途改会有点麻烦。

4. IPIP 模式下的常见问题与排查实录

4.1 Pod 之间大包不通，小包正常

这是我遇到最多的一类问题，十次里有八次是 MTU 惹的祸。现象很典型：Pod A ping Pod B 的小包（比如 100 字节）没问题，一加上较大的 payload 就超时。原因在 2.3 里已经说过：隧道封装把实际可用 MTU 从 1500 压到了 1480，如果 Pod 网卡的 MTU 仍然偏大，大包要么需要分片、要么因 DF 标志被静默丢弃。

排查思路分两步。第一步，在 Pod 里确认 MTU 配置：

kubectl exec -it <pod-name> -- ip link show eth0

期望值应该是 1480。如果显示 1500 或者更高，说明 veth 的 MTU 与隧道不匹配，需要检查 Calico 版本的默认 MTU 逻辑，或者看节点物理网卡 MTU 是否被人为修改过。

第二步，用带 DF 标志的 ping 验证完整路径。1480 MTU 环境下，内层 IP 包最大只能到 1480 字节，去掉 IP 头 20 字节和 ICMP 头 8 字节，ICMP payload 最大是 1452 字节，所以验证命令是：

ping -M do -s 1452 <pod-b-ip>

1452 字节 payload 加上 28 字节头部，总共 1480，应该能通。如果这个值不通，再减小 payload 逐步测试，很快就能测出实际可达的最大值。找到偏差之后，再去对齐节点物理网卡、容器 veth 和隧道端口的 MTU 配置。

这里要特别提醒：某些云厂商的虚拟网卡默认 MTU 可能不是 1500，比如 1400 或者 1450。这种情况下，Calico 按 1500 自动计算出的 1480 依然是偏大的，如果物理链路实际只有 1400，一样会出问题。遇到这种环境，最稳妥的排查路径是确认物理网卡的真实 MTU，然后手动调整 Calico 的 MTU 相关配置。

4.2 路由表有隧道路由，但就是 ping 不通

另一个很典型的场景：路由表里明明存在走 tunl0 的 Pod 网段路由，tunl0 设备也正常创建了，但跨节点 Pod 之间始终不通。这种情况基本可以排除 Calico 自身配置的问题，重点查节点之间的物理网络以及安全策略。

我遇到过几次类似 case，最后定位的结果都是中间设备拦截了协议号为 4 的流量。IPIP 封装使用的是专用协议号 4，这个协议在日常防火墙策略里经常被忽略。有些交换机或者安全组默认只放行 TCP、UDP 和 ICMP，IP-in-IP 流量直接就被丢弃了。

排查命令很简单，在目的节点上抓包：

tcpdump -i eth0 -n 'ip proto 4'

如果源节点一直在发送封装包，比如每秒几十个，但目的节点一个包都抓不到，那基本可以判断流量被中间链路拦截。如果源节点都没有在发送，那问题可能在源节点的路由选择，继续检查源节点上到目的 Pod 网段的路由是否正常。

这里需要提醒一点：改了任何主机防火墙或网络策略之后，记得验证一下双向的 ICMP 和协议 4 流量，因为有的网络策略是单向放行的，会出现"Pod 能出不能回"的诡异现象，这种问题最容易让人绕远路。

4.3 跨网段通信延迟偏高，同网段正常

第三个常见问题是性能类的：同网段节点之间 Pod 通信延迟很低，但跨网段时延迟明显上升。这个现象本质上是 IPIP CrossSubnet 模式的预期行为，因为跨网段的包走了封装路径，多了 20 字节的头和一次额外的处理逻辑。但如果你觉得延迟高得离谱，那要考虑几件事。

第一，确认封装确实只发生在跨网段流量上。如果因为节点划分子网时规划不合理，导致大量本该直连的流量也走了隧道，性能就会被白白浪费。利用ip route show dev tunl0，你能看到都有哪些网段走了隧道路由。第二，检查物理网络本身的延迟，用节点之间直接 ping 的 RTT 和 Pod 之间 ping 的 RTT 做差值，如果差值接近 0.2ms 以上且持续稳定，大概率是隧道处理引入的延迟；如果节点之间 ping 本来就很高，那问题不在 Calico，得先找网络运维。

从性能调优角度，对于跨网段但传输量很大的业务，我更推荐考虑使用 VXLAN 或者纯 BGP 直连（如果能打通二层）来替代 IPIP。另外，如果确认是大规模集群且所有节点都在同一机房同一二层，直接配置成 Never 模式是最优解，完全没有封装开销。

4.4 修改 IPPool 后旧 Pod 还是走老路径

最后一个很常见的坑发生在配置变更之后。你把 ipipMode 从 Always 改成 CrossSubnet，也执行了 apply，表面看配置已经生效了，但旧节点上已存在的 Pod 之间的通信路径还是走隧道，甚至直接不通。

原因是 IPIP 模式切换会影响路由表条目重建，但已存在连接的内核 conntrack 条目不会立刻清理。旧连接仍然按照老的封装方式处理，新连接才会使用新路径。所以切换后过一段时间，或者干脆重启相关工作负载，让连接全部重新建立，问题就消失了。

如果不想等，也可以主动清理 conntrack 表，但生产环境执行清理需要谨慎，最好选择业务低峰期。更多时候我会选择"保留一段时间再切换"的策略：先应用新配置，观察 10 到 15 分钟，确认新连接一切正常后再开始重启业务。

我把生产场景里的 Troubleshooting 经验整理成了一个速查表，方便你排障时对照：

5. 生产环境选型建议：IPIP 到底适不适合你

讲完原理和排障，最后聊聊选型。这不是简单的好坏题，而是要结合你的网络拓扑、业务特征和维护成本来做判断。

如果你的集群节点全部在同一个二层网络里，IPIP 模式就没有存在的必要，直接用 Never 模式，也就是纯 BGP 直连。这是性能最优解，少一层封装、少二十字节开销，排障也简单，路由全是物理直连，看ip route一目了然，遇到问题定位路径最短。

如果你的集群存在明显的多网段节点分布，而且你不想引入更重的 VXLAN，那 CrossSubnet 是首选。同网段节点享受直连，跨网段节点自动封装，兼顾性能和功能，配置也只需要改一个字段。这也是大多数中小规模混合部署集群里最常见的形态。

如果跨网段场景非常多、集群规模又大、网络策略又复杂，那可以考虑把 VXLAN 纳进来评估。虽然开销更大，但 VXLAN 在云原生生态里兼容性更好，很多公有云环境已经默认支持，而且它对底层网络的异常容忍度更高。反倒是 IPIP 依赖协议 4 这件事，在某些企业网络环境里需要额外申请策略放行，可能成为一条卡审批的问题。

在 IPIP 和 VXLAN 之间摇摆时，还可以做一个简单的压测。把同样的业务流量分别跑在两个模式下，观察 PPS 和吞吐量，选数据说话。我在一个模拟项目里测过，同一批节点的集群，IPIP 模式相比 VXLAN 大约有 8% 到 15% 的吞吐优势，但不同业务模型下差异会有浮动，还是要按自己的场景实测为准。

我个人在实际操作中的体会是：Calico IPIP 是那种"配置简单但原理不简单"的组件，用它之前最好还是花点时间把封装路径、MTU 影响、BGP 路由这几件事搞清楚。否则出了故障，你连从哪个方向排查都不知道。最后再分享一个小技巧：遇到跨节点网络问题，先用calicoctl node status看 BGP 连接，再用ip route show dev tunl0看隧道路由，最后用 tcpdump 抓协议 4 的包。这三步走下来，绝大多数 IPIP 问题都能定位到具体原因。