通过在每个节点上添加具有适当规则的静态路由表,容器网络也可以正常工作。例如,给定三个具有三个不同docker bridge子网的节点:
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
当kube-proxy在iptables模式下运行时,cluster-service-ip将转换为pod ip,最后通过路由表路由到相关节点。
那么在路由表上使用cni插件有什么好处?路由表方法是否存在性能问题?
答案 0 :(得分:1)
根据设计,Kubernetes具有流畅的结构。 Pod,服务,节点可以根据需要来来去去,可以通过手动更改(滚动更新,新部署)或通过自动缩放(HPA,节点自动缩放)来实现。手动设置刚性网络结构会抵消动态Kubernetes环境的好处。
默认情况下不需要覆盖网络,但是它们在特定情况下会有所帮助。就像我们没有足够的IP空间,或者网络无法处理额外的路由一样。或者,当我们想要叠加层提供的一些额外管理功能时。一种常见的情况是,云提供商路由表可以处理的路由数受到限制。例如,AWS路由表最多支持50条路由,而不会影响网络性能。因此,如果我们有超过50个Kubernetes节点,那么AWS路由表将不够用。在这种情况下,使用覆盖网络会有所帮助。
它实质上是封装一个跨分组的数据包,该数据包跨节点遍历本机网络。您可能不希望使用覆盖网络,因为由于所有数据包的封装/解封装,它可能会导致一些延迟和复杂性开销。通常不需要使用它,因此只有在知道为什么需要它时,才应使用它。
https://itnext.io/an-illustrated-guide-to-kubernetes-networking-part-2-13fdc6c4e24c
如果您担心由CNI插件引起的延迟和开销,这里是方便的Benchmark results of Kubernetes network plugins