Kubernetes选择CNI插件的11个注意事项

云原生应用程序的时代,引入了思考网络架构的新方法。

Kubernetes网络被设计为一种干净的,向后兼容的模型,从而消除了将容器端口映射到主机端口的需求。为了支持这一点,Kubernetes引入了许多围绕网络的基本结构,例如Pod网络,服务,集群IP,容器端口,主机端口和节点端口,这些将用户从底层基础结构中解放出来。

尽管Kubernetes中有许多网络基础的构建,但Kubernetes仍然存在许多故意的空白以使其与基础架构无关。网络中的这些空白大部分由网络插件填补,这些插件通过容器网络接口(CNI)与Kubernetes交互。

CNI插件的常见限制

Kubernetes使用插件模型进行网络连接,使用CNI来管理集群上的网络资源。大多数常见的CNI插件利用overlay networking(覆盖网络),该网络在现有第2层(L2)网络之上在集群内部创建了私有第3层(L3)网络。

使用这些CNI插件,专用网络只能由集群中的Pod访问。在节点之间甚至在集群外部交换数据包的过程在很大程度上取决于iptable规则以及专用和公用IP地址的网络地址转换(NAT)。

这些CNI插件的一些示例是Open vSwitch(OVS),Calico,Flannel,Canal和Weave。

每个可用于Kubernetes的网络CNI插件都有其优缺点。让我们探讨一下CNI插件的一些常见限制:

1. 依赖软件定义的网络(Software Defined Networking)

SDN(Software Defined Networking)网络功能是作为软件设备提供的,从而增加了各种复杂性,包括其他iptables和NATing。

SDN软件消耗了15%到20%的可用主机资源(CPU和内存),从而降低了效率并增加了运行实际应用程序所需的资源数量。

2. 在集群外公开应用程序

由于大多数联网解决方案都使用L3联网,因此Pod IP的存在位于集群本身内。将这些Pod暴露于外界仍然是一个挑战。Kubernetes利用ServiceType中的“ NodePort”和“ LoadBalancers”公开应用程序。

ServiceType中的 NodePort通过在主机网络接口随机唯一端口上,路由在节点上运行的所有应用程序。

在公共云中,云负载均衡器的可用性使生活变得更加轻松,因为它会自动将公共IP分配给Kubernetes中ServiceType为 LoadBalancer的服务。但是,此功能不适用于本地云。诸如MetalLB之类的解决方案可以用来解决此问题,但是它们有其自身的局限性和挑战。

3. 通过主机网络路由所有流量

当使用用ServiceType中的“ NodePort”和“ LoadBalancers”时,Kubernetes利用主机网络接口路由所有流量。由于安全性和性能问题,这不是企业环境中的理想方案。

NodePort和Loadblancer服务的数据包流

4. 流量隔离

大多数Kubernetes网络解决方案都使用相同的物理网络(主机网络)接口来处理各种流量。

这意味着控制,pod和存储流量共享同一网络接口。这可能会带来安全风险,并且还会影响Kubernetes控制平面的性能,因为Pod和存储流量很容易消耗可用带宽(反之亦然)。

5. 负载不均衡

大多数网络解决方案都依赖于外部负载均衡器,当Pod分布在集群中的多个节点上时,这不是问题。

但是,同一后端服务的多个Pod也可以在同一节点上运行。这可能会导致负载不平衡问题,因为外部负载均衡器只能在节点之间进行负载均衡,而不能在Pod之间进行负载均衡。

6. 额外 hops

1)在数据包转发网络中,hop指数据包经过路由器或直接通过节点转移到其他网络的过程。在互联网或者采用TCP/IP协议的网络中,hop数目会在数据包的包头上面有所记录。如果hop数目过大,就将此数据包忽略掉。

2)在蜂窝式数字分组数据(CDPD)中,hop是指到别的射频信道的交换过程。

参考自:https://searchcio.techtarget.com.cn/whatis/8-24231/

在L3网络中,外部访问总是通过暴露节点本身上的接口或端口来完成的。在这种情况下,如果请求通过错误的节点,则Pod和外部通信可能会产生额外的hop,从而影响性能和延迟。

7. 多宿主网络

在许多情况下,该应用程序可能需要用于Pod网络的多个接口,以便它可以连接到不同的隔离网络/子网。目前,大多数CNI插件均不支持多个接口。

8. 静态端点配置

Kubernetes中的Pod IP是动态的,并且在Pod重新启动时会更改。大多数CNI插件不支持为Pod分配静态端点或IP。

这意味着只能通过服务公开Pod,这对于某些类型的部署可能不是理想的选择。

9. Noisy Neighbors 和SLA性能

在同一节点上运行多个应用程序时,来自每个应用程序的流量都流经同一网络管道。如果一个应用程序行为不正常,则可能会影响其他应用程序的性能。

大多数CNI插件不支持在应用程序级别提供网络性能保证。

10. 多区域支持

高可用性对任何组织都至关重要,并且已成为生产Kubernetes部署中的要求。

拥有对多区域集群的网络支持非常重要,该支持可将应用分布在不同的域中。

11. 存储流量无分隔

大多数CNI插件无法区分存储流量和常规流量。他们使用相同的共享接口来进行存储数据交换,从而导致网络和存储流量(在某些情况下甚至控制流量)相互竞争。这会影响性能和安全性。

译文链接:https://thenewstack.io/top-considerations-when-selecting-cni-plugins-for-kubernetes/

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录