原文发表于kubernetes中文社区，为作者原创翻译 ，原文地址
更多kubernetes文章，请多关注kubernetes中文社区
目录
1. 依赖软件定义的网络(Software Defined Networking)
云原生应用程序的时代，引入了思考网络架构的新方法。
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插件无法区分存储流量和常规流量。他们使用相同的共享接口来进行存储数据交换，从而导致网络和存储流量（在某些情况下甚至控制流量）相互竞争。这会影响性能和安全性。
另一种联网方法Diamanti
Diamanti凭借其独特的网络体系结构解决了常见CNI插件中发现的大多数缺点。
Diamanti的Kubernetes数据平面解决方案内置了对L2网络的支持，并且硬件卸载了智能NIC。这允许将真正的L2 MAC地址分配给外部可路由网络上的每个Pod，从而使联网更加容易。它还支持使用OVS的L3overlay networking(覆盖网络)，流量隔离，VLAN/VXLAN分段，多宿主网络，静态端点配置，网络感知调度，有保证的SLA以及许多其他独特功能。
你可以在Diamanti网站上查看有关Diamanti网络体系结构的更多详细信息。
Kubernetes中的网络堆栈是企业生产部署中最重要的架构决策之一。在为基础架构选择CNI插件时，需要注意其局限性，并确定最适合你的插件。
译文链接：https://thenewstack.io/top-considerations-when-selecting-cni-plugins-for-kubernetes/