背景
随着kubernetes逐渐成为应用部署的事实标准,开发运维人员可以更便捷的部署、拓展应用程序,同时也带来了一系列的云上疑难杂症。其中最莫过于头疼的无非是网络问题。由于传统的虚拟机应用使用内核网络比较清晰,内核网络故障概率也比较少,问题往往出现在物理网络,即使问题出现在内核网络,也相对比较容易定界。而容器使用内核网络的方式出现了颠覆性的变化,比如使用了更多的二层、三层转发、不同namespace的通信、各种路由防火墙策略。在如此复杂的环境下,可能某一条网络规则的配置错误或者某个虚拟网络设备的状态不正常都会导致网络故障。
在如此复杂的网络场景下,我们的SRE或者研发工程师很难全局把控容器网络,可以说整个内核网络是一个黑盒。所以,面对这一系列的困境,kindling正在逐步尝试将内核网络白盒化以及帮助工程师确定是容器网络问题还是物理网络问题
Kindling的设想
基于以上问题,假如告诉用户数据包在哪个网络设备之后就“断链”是不是就能缩小问题的排查范围了呢?下图是flannel网络的vxlan模式通信图。
vxlan模式通信图
当podA发起一次调用podB的请求时,中间会经过veth设备、cni网桥、vxlan设备、物理网卡。
-
对于该次请求而言,如果数据包已经从node1的ens192网卡上发送出去了,而node2并没有收到该次请求,则说明物理网络出