Calico IPIP模式mtu问题_calico mtu-CSDN博客

文章描述了一个KafkaPod由于通过127.0.0.1:2181连接Zookeeper失败导致Pod非Running状态的问题。经过分析，发现是由于IPIP隧道的MTU设置不正确，Calico网络策略要求减去20字节。通过调整集群Calico的MTU从1440到1430，修复了跨节点HTTPS通信问题，使Pod能够正常运行。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

用户问题

kafka命令空间下Pod kafka-kafka-X为非Running状态。

分析过程

1、查看问题Pod日志。

关键日志：

client: /127.0.0.1:32896, server: localhost/127.0.0.1:2181

Timed out waiting for connection while in state: CONNECTING

2、127.0.0.1:2181是什么？

查看Sidecar容器日志，继续分析。

关键日志：

Service [zookeeper-2181] accepted connection from 127.0.0.1:32896

connect_blocking: connected

其中，A为zk service，后面对应3个endpoint，分别为kafka-zookeeper-0，kafka-zookeeper-1，kafka-zookeeper-2。

3、连通性验证

分析：该Pod由两个容器组成，主容器kafka，以及sidecar容器tls-sidecar，前者kafka会通过127.0.0.1:2181连接zk，由于访问失败导致主容器启动失败，从而整个Pod启动失败。后者tls-sidecar提供的127.0.0.1:2181实际上是访问同namespace的zk svc：kafka-zookeeper-client 172.16.218.3:2181，svc则通过rr模式访问后端3个zk Pod。排障经过：进入容器tls-sidecar中，直接curl 172.16.218.3:2181，能rr到3个zk Pod，正常响应；直接curl 3个后端zk Pod的2181端口也正常。对比，curl 127.0.0.1:2181，实际会转换zk svc 172.16.218.3:2181，rr 3次请求只会成功一次，成功这次为相同节点的zk Pod响应。通过抓包分析，curl 127.0.0.1:2181实际走的https，而直接curl 172.16.218.3:2181或3个后端，实际走的http。二者效果不同，http协议通，https协议不通。换验证方式，curl https://172.16.218.3:2181，以及3个后端，也是只有相同节点的zk Pod能响应。问题变换为跨节点执行https为何不通的问题。Node节点上直接抓包，现象也相同。经抓包，原节点tunl0网卡出错"TCP Previous segment not captured"，目的节点tunl0网卡及cali网卡出错"TCP Retransmission"。后续分析：tunl0的mtu及其他网络接口的二三层配置是否对数据包的转发有影响。

4、继续分析

处理过程：1、昨日怀疑IPIP隧道tunl0的mtu有问题。2、Calico官网查询mtu相关资料，IPIP模式协议头占20字节，需要在节点主网卡mtu上减20，当前集群主网卡eth0的mtu为1450，tunl0的mtu为1440，不满足Calico要求。相关链接：https://docs.projectcalico.org/networking/mtu3、按照上述资料调整集群的mtu，主要使用下面两条命令$ kubectl patch configmap/calico-config -n kube-system --type merge -p '{"data":{"veth_mtu": "1430"}}'$ kubectl rollout restart daemonset calico-node -n kube-system4、再次观察tunl0的mtu，已自动修改为1430。5、新的mtu需要对新Pod生效，所以手动删除kafka命名空间下已有Pod，使其自动重建。6、待Pod重建后，观察到Pod内eth0的mtu已为1430。7、Pod kafka-kafka-0内连通性检查，3次curl 127.0.0.1:2181正常；3次curl -k 172.16.218.3:2181(zk svc)正常；分别curl -k <zk Pod>:2181正常。8、查看该命名空间下Pod状态，均Running。

问题总结

昨日怀疑IPIP隧道tunl0的mtu有问题，今天分析后，修改集群Calico的mtu从1440到1430，问题解决。后续会针对Calico IPIP模式调整集群部署工具的参数。

参考资料

Configure MTU to maximize network performance：https://docs.projectcalico.org/networking/mtu