通过在每个节点上添加具有适当规则的静态路由表，容器网络也可以正常工作。例如，给定三个具有三个不同泊坞桥子网的节点:
node-1(192.168.0.1):
10.0.1.1/24
node-2(192.168.0.2):
10.0.2.1/24
node-3(192.168.0.3):
10.0.3.1/24
在每个节点上添加以下路由:
ip route add 10.0.1.0/24 via 192.168.0.1 dev eth0
ip route add 10.0.2.0/24 via 192.168.0.2 dev eth0
ip route add 10.0.3.0/24 via 192.168.0.3 dev eth0
通过在iptables模式下运行kube-proxy，cluster-service-ip将转换为pod ip，最后通过路由表路由到相关节点。
那么在路由表上使用cni插件有什么好处？路由表方法是否存在性能问题？
最佳答案
通过设计，Kubernetes具有流畅的结构。 Pod，服务，节点可以根据需要来来去去，可以通过手动更改(滚动更新，新部署)或通过自动缩放(HPA，节点自动缩放)来实现。手动设置刚性网络结构会抵消动态Kubernetes环境的好处。
Overlay networks are not required by default, however, they help in specific situations. Like when we don’t have enough IP space, or network can’t handle the extra routes. Or maybe when we want some extra management features the overlays provide. One commonly seen case is when there’s a limit of how many routes the cloud provider route tables can handle. For example, AWS route tables support up to 50 routes without impacting network performance. So if we have more than 50 Kubernetes nodes, AWS route table won’t be enough. In such cases, using an overlay network helps.
It is essentially encapsulating a packet-in-packet which traverses the native network across nodes. You may not want to use an overlay network since it may cause some latency and complexity overhead due to encapsulation-decapsulation of all the packets. It’s often not needed, so we should use it only when we know why we need it.
https://itnext.io/an-illustrated-guide-to-kubernetes-networking-part-2-13fdc6c4e24c
如果您担心由CNI插件引起的延迟和开销，这里是一个方便的Benchmark results of Kubernetes network plugins
关于docker - 在k8s中使用cni代替静态路由表有什么好处，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56357988/