标签：consul mtu 故障 集群 operator 日志 k8s 节点

背景

在部署新的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。

标签：consul,mtu,故障,集群,operator,日志,k8s,节点
来源： https://www.cnblogs.com/zisefeizhu/p/16611626.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。