在k8s中使用cni代替静态路由table有什么好处
What's the benefit of using cni instead of static route table in k8s
通过在每个具有适当规则的节点上添加静态路由 table，容器网络也可以正常工作。例如，给定具有三个不同 docker 网桥子网的三个节点：
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，并最终通过路由 table 路由到相关节点。
那么在路由 table 上使用 cni 插件有什么好处？路由 table 方法是否存在性能问题？
根据设计，Kubernetes 具有流畅的结构。 Pods，服务、节点可以根据需要来来去去，可以通过手动更改（滚动更新、新部署）或自动扩展（HPA、节点 auto-scaling）。手动设置刚性网络结构抵消了动态 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
通过在每个具有适当规则的节点上添加静态路由 table，容器网络也可以正常工作。例如，给定具有三个不同 docker 网桥子网的三个节点：
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，并最终通过路由 table 路由到相关节点。
那么在路由 table 上使用 cni 插件有什么好处？路由 table 方法是否存在性能问题？
根据设计，Kubernetes 具有流畅的结构。 Pods，服务、节点可以根据需要来来去去，可以通过手动更改（滚动更新、新部署）或自动扩展（HPA、节点 auto-scaling）。手动设置刚性网络结构抵消了动态 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