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

╰半橙微兮° 2022-12-17 14:57 264阅读 0赞

> **原文发表于[kubernetes中文社区][kubernetes]，为作者原创翻译 ，[原文地址][Link 1]**
> 
> **更多kubernetes文章，请多关注[kubernetes中文社区][kubernetes]**

**目录**

CNI插件的常见限制

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

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

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

4. 流量隔离

5. 负载不均衡

6. 额外 hops

7. 多宿主网络

8. 静态端点配置

9. Noisy Neighbors 和SLA性能

10. 多区域支持

11. 存储流量无分隔

另一种联网方法Diamanti

--------------------

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

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

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

# CNI插件的常见限制 #

Kubernetes使用插件模型进行网络连接，使用CNI来管理集群上的网络资源。大多数常见的[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利用主机网络接口路由所有流量。由于安全性和性能问题，这不是企业环境中的理想方案。

![43c0b727b2bdc15ad67f2bd77763e5a1.png][]

*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插件无法区分存储流量和常规流量。他们使用相同的共享接口来进行存储数据交换，从而导致网络和存储流量（在某些情况下甚至控制流量）相互竞争。这会影响性能和安全性。

# 另一种联网方法Diamanti #

Diamanti凭借其独特的网络体系结构解决了常见CNI插件中发现的大多数缺点。

Diamanti的Kubernetes数据平面解决方案内置了对L2网络的支持，并且硬件卸载了智能NIC。这允许将真正的L2 MAC地址分配给外部可路由网络上的每个Pod，从而使联网更加容易。它还支持使用OVS的L3overlay networking(覆盖网络)，流量隔离，VLAN/VXLAN分段，多宿主网络，静态端点配置，网络感知调度，有保证的SLA以及许多其他独特功能。

你可以在[Diamanti网站][Diamanti]上查看有关Diamanti网络体系结构的更多详细信息。

Kubernetes中的网络堆栈是企业生产部署中最重要的架构决策之一。在为基础架构选择CNI插件时，需要注意其局限性，并确定最适合你的插件。

译文链接：[https://thenewstack.io/top-considerations-when-selecting-cni-plugins-for-kubernetes/][https_thenewstack.io_top-considerations-when-selecting-cni-plugins-for-kubernetes]

[kubernetes]: https://www.kubernetes.org.cn/
[Link 1]: https://www.kubernetes.org.cn/8570.html
[Link 2]: https://thenewstack.io/why-those-gaps-in-kubernetes-are-really-a-good-thing/
[CNI]: https://kubernetes.io/docs/concepts/cluster-administration/networking/
[43c0b727b2bdc15ad67f2bd77763e5a1.png]: /images/20221122/f7e932df265344d0ab635bab64d4a5a4.png
[Diamanti]: https://diamanti.com/
[https_thenewstack.io_top-considerations-when-selecting-cni-plugins-for-kubernetes]: https://thenewstack.io/top-considerations-when-selecting-cni-plugins-for-kubernetes/