k8s-mtu设置不当引发的线上故障

背景

在部署新的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。
posted @ 2022-08-22 07:32  紫色飞猪  阅读(1106)  评论(0编辑  收藏  举报