一、现象说明
我们在k8s集群上部署服务，发现在72段主机上的服务访问是都没有问题的；但是在161段主机有的服务可以访问；有的访问没有返回值；其中在161段主机访问没有返回值的服务；到服务所在的主机是可以访问的。
二、解决过程
针对上述现象，我们确定了这两个段的ip是在一个vpc的，互相访问是没有问题的，不然也不可能存在有的访问有返回值，有的没有返回值，截图如下：
上图是我把grafana调到161段主机上curl就不正常了，重新把它调度到72段就能正常访问，后面我们部署了个nginx到161段发现也能正常访问，包括已经部署的redis集群和kafka集群以及其他服务都能正常访问，这些redis的管理web页面访问就不能正常返回，只能说太邪门了。
对比了下72段主机和161段的主机只是发现主机内核不一样还有主机网卡的mtu值是不一样的，因为我们之前部署calico因为mtu值不对造成服务不可以正常访问的问题，看了下自己的calico配置，因为我们calico用的是ip-ip模式，所示calico的mtu值应该是所在主机的网卡mtu值减去20，因为我们主机72段的主机和161段的主机mtu值是不一样的；只能选择按主机最小的mtu来定义calio的mtu值，发现配置的是没有问题的，难道按照主机mtu值最小的来算calico的mtu值是不行的吗，想着就把calico的mtu值改为了72段主机的mtu值来算了，创建更新calico,再去访问服务，发现情况依然没有改变，只能通过分别抓包看看了，抓包截图如下： 通过抓包发现不正常的服务发送出去的包，没有回应，并且不断重试发送，这个时候怀疑可能是主机的mtu值导致的，发现72段主机的mtu值是1500；发出的数据包都有很快的返回；而161段主机就无法正常返回，并且不断重试，然后改下161段主机的mtu值到1500,发现再去访问服务就都是能正常返回了。

mtu: 工作在数据链路层，在IP层下面的每一种数据链路层都有自己的帧格式，其中包括帧格式中的数据字段的最大长度，这称为最大传送单元 MTU(Maximum Transfer Unit)。
当一个数据报封装成链路层的帧时，此数据报的总长度（即首部加上数据部分）一定不能超过下面的数据链路层的MTU值。