背景
在部署新的paas平台线上环境时，突发consul和es中间件无法创建。
排查过程
以consul
通过查询k8s集群中pod状态发现原来3pod的consul集群，其中2个pod一直重启。
# kubectl get pods -n paasconsul-propaas
通过describe查看pod信息，发现是liveness失败。
# kubectl describe pods -n paasconsul-propaas
查看liveness调用的是health-check的二进制文件，经过分析源码发现这个二进制文件的作用为连接本地consul节点，查看当前节点状态。现在查看集群状态错误。此时怀疑consul集群配置出现问题
通过查看operator的log发现集群并没有报错。并且打印有副本集配置完成的日志出现在最后一行。但是后续一直没有日志打印，此时怀疑是operator没有收到events事件。
为了验证events事件没有获取到，通过修改cr文件的cpu和内存参数，想要触发新的更新event。结果不出意外，operator并没有触发更新操作，日志并无新增，节点状态并没有改变
看到operator无任何响应，怀疑其已经卡死，为了验证此想法，又从paas平台创建一个集群，发现出现新日志，后续又到副本集配置完成日志打印，然后卡死。判断operator状态存活正常，只是对更新cr信息无响应。
问题分析
针对无法更新cr的状态无法获取events时间。开始分析
怀疑etcd写入失败，通过查看etcd日志发现一切正常。（❎）
想起之前遇见的pod名字受DNS Label Names 63位长度限制，怀疑其cr是否也存在其问题。通过将原cr的yaml信息保留下来，改其名称再运行。结果发现其正常运行。(✅)
问题处理
为什么名称长度限制会导致operator卡死无响应？
这时候想到了tcp的mtu设置。虚拟机mtu和容器mtu不匹配将会导致网络不通。
因为当前k8s集群采用的是IP-IN-IP协议，此协议可以解决掉k8s生产扩容时，不会引起新老主机不通问题。
# 查看物理节点mtu：
netstat -i
# 发现其物理节点mtu值为1450
# 查看calico配置的mtu参数
kubectl get configmap/cali-config -n kube-system | grep "veth_mtu"
# 发现其mtu值也为1450
此时问题原因找到，calico启用tunnel模式，因此经过tunnel会封装一个新的20字节的ip包头，所以当发送大量数据时，calico生成的1450大小的数据包再加上20大小的ip包头为1470字节的包。
本地网卡转发calico通讯数据包1470，将失败。
可以通过两种方式解决此问题。1、更改物理节点mtu值大小。2.修改calicomtu值大小为 物理节点mtu-20。
推荐使用第二种
kubectl patch configmap/calico-config -n kube-system --type merge -p '{"data":{"veth_mtu": "1430"}}
根据实际需要调整所在k8s node节点的 eth0或tunl0的mtu，需确保tunl0的mtu比eth0的mtu少20。