-
背景:某现场生产环境一资源池,突然间pod之间无法访问,导致业务大规模失败
-
分析: 现场的网络插件为calico,采用的网络模式是CrossSubnet.且不通的是同网段和跨网段
-
主要考虑方向 网络-路由-防火墙策略-防火墙是否有变更
最后以上方法没有效果的时候尝试重启服务,首先node节点的kubeproxy ,故障依然
然后重启kubelet ,故障依然,然后重启docker,无法可正常访问了
查看相关文档,发现docker重启时,会修改系统的内核参数,net.ipv4.ip_forward,这个参数如果设置为0,将导致pod的ip无法转发
现场执行systemctl net.ipv4.ip_forward
果然,输出表示当前系统的IP_FORWARD功能处于停用状态!
经检查确实是这个参数导致了部分pod之间无法访问(有的不通的,有网络策略限制)
可是问题来了,当时启动容器的时候都是好的啊,什么都没有输出,怎么用着用着IP_FORWARD功能就被禁用了呢?
后来查相关文档Docker daemon服务在启动的时候会自动设置iptables设置,难不成它还会检查IP_FORWARD设置,并帮我临时启用吗?
带着这个假设,我在自己虚拟机手动重启了一下Docker daemon服务:
果然,Docker daemon服务在启动过程中会检查系统的IP_FORWARD配置项,如果当前系统的IP_FORWARD功能处于停用状态,会帮我们临时启用IP_FORWARD功能,然而临时启用的IP_FORWARD功能会因为其他各种各样的原因失效… -
现场的问题:定位出来是内核参数失效导致的,但是不确定是谁引起的,因为我们作为应用方没有sudo权限,故无权限修改该参数,具体责任人,我就没继续深究了。但我觉得是默认没有设置到系统内核的配置文件里面,可能这些主机重启网络导致的失效。
ps:后续会补充一些calico,flannel的网络知识
网友评论