ipip模式仅适用于底层不支持bgp直连路由的跨三层环境，如云厂商vpc或隔离子网；需满足节点间物理ip可达但pod子网未被识别的条件，典型表现为pod能通宿主机ip却无法通对方pod ip、路由表缺失via node-ip条目、底层设备不学习容器网段，且日志报no route to host；启用时须显式配置calico ippool并重启calico-node，同时调优mtu至1480、按需启用crosssubnet模式、验证ipip0隧道状态；若在可管环境中，应优先采用bgp直连以获得更低延迟与更高吞吐。
直接启用IPIP模式就能解决跨三层网络下容器不通或卡顿的问题，但关键在于它只应在底层不支持BGP直连路由的环境中使用——比如云厂商VPC、隔离子网、或无法配置BGP的交换机环境。盲目开启反而会引入封装开销和延迟。
IPIP模式适用的真实场景判断
不是所有“跨网段”都需要IPIP。只有当节点间物理IP可达，但Pod子网路由未被底层网络识别时，才真正需要它。典型信号包括：
- 同一集群内不同节点上的Pod能互相ping通宿主机IP，但无法ping通对方Pod IP
- 执行
ip route show | grep calico发现目标Pod网段没有对应via <node-ip></node-ip>路由条目 - 底层网络设备（如云平台路由表、物理路由器）不支持注入/学习192.168.x.0/24这类容器网段
- 错误日志中出现
no route to host或Network is unreachable而非连接超时
启用IPIP的核心配置步骤
Calico默认可能禁用IPIP，需显式创建或更新IPPool资源。注意：修改后必须重启calico-node Pod才能生效。
- 检查当前IPPool：
calicoctl get ippool -o wide - 若未启用，创建带IPIP的池（示例）：
apiVersion: projectcalico.org/v3 kind: IPPool metadata: name: default-ippool spec: cidr: 192.168.0.0/16 ipipMode: Always natOutgoing: true
- 应用配置：
calicoctl apply -f ipip-pool.yaml - 强制重建节点组件：
kubectl delete pod -n kube-system -l k8s-app=calico-node
避免IPIP引发新卡顿的关键调优
IPIP本身会增加20字节封装、影响MTU、并消耗CPU解包。以下三点不调，性能可能比BGP还差：
-
同步调整MTU：宿主机网卡MTU需预留IPIP头空间，建议设为
1480（1500 − 20），并在calico-node DaemonSet中通过IP_AUTODETECTION_METHOD和FELIX_IPINIPMTU环境变量固化 -
关闭无意义的IPIP：如果部分节点在同子网（如都在172.16.6.0/24），应改用
CrossSubnet模式，仅对跨子网链路启用IPIP，减少全局封装 -
验证隧道状态：在节点上运行
ip tunnel show，确认有ipip0设备；再用tcpdump -i ipip0抓包，观察是否有持续重传或ICMP Fragmentation Needed报文
替代方案：什么时候该放弃IPIP
如果已部署在私有机房或可管理交换机环境，优先考虑BGP直连：
- BGP模式延迟稳定在0.3ms以内，吞吐达9.8Gbps，而IPIP实测延迟常在2–5ms
- 只需在交换机侧配置BGP邻居指向各Node IP，并允许接收192.168.0.0/16路由即可，无需修改容器网络
- 若担心BGP规模问题，可用BGP Route Reflector（如BIRD RR）集中分发路由，避免全互联
