背景：某现场生产环境一资源池，突然间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的网络知识