点击联系发帖人云原生应用程序的时代，引入了思考网络架构的新方法。
Kubernetes网络被设计为一种干净的，向后兼容的模型，从而消除了将容器端口映射到主机端口的需求。为了支持这一点，Kubernetes引入了许多围绕网络的基本结构，例如Pod网络，服务，集群IP，容器端口，主机端口和节点端口，这些将用户从底层基础结构中解放出来。
尽管Kubernetes中有许多网络基础的构建，但Kubernetes仍然存在许多以使其与基础架构无关。网络中的这些空白大部分由网络插件填补，这些插件通过容器网络接口（CNI）与Kubernetes交互。
Kubernetes使用插件模型进行网络连接，使用CNI来管理集群上的网络资源。大多数常见的利用overlay networking(覆盖网络)，该网络在现有第2层（L2）网络之上在集群内部创建了私有第3层（L3）网络。
使用这些CNI插件，专用网络只能由集群中的Pod访问。在节点之间甚至在集群外部交换数据包的过程在很大程度上取决于iptable规则以及专用和公用IP地址的网络地址转换（NAT）。
每个可用于Kubernetes的网络CNI插件都有其优缺点。让我们探讨一下CNI插件的一些常见限制：
在L3网络中，外部访问总是通过暴露节点本身上的接口或端口来完成的。在这种情况下，如果请求通过错误的节点，则Pod和外部通信可能会产生额外的hop，从而影响性能和延迟。
在许多情况下，该应用程序可能需要用于Pod网络的多个接口，以便它可以连接到不同的隔离网络/子网。目前，大多数CNI插件均不支持多个接口。
Kubernetes中的Pod IP是动态的，并且在Pod重新启动时会更改。大多数CNI插件不支持为Pod分配静态端点或IP。
这意味着只能通过服务公开Pod，这对于某些类型的部署可能不是理想的选择。
在同一节点上运行多个应用程序时，来自每个应用程序的流量都流经同一网络管道。如果一个应用程序行为不正常，则可能会影响其他应用程序的性能。
大多数CNI插件不支持在应用程序级别提供网络性能保证。
高可用性对任何组织都至关重要，并且已成为生产Kubernetes部署中的要求。
拥有对多区域集群的网络支持非常重要，该支持可将应用分布在不同的域中。
11. 存储流量无分隔
大多数CNI插件无法区分存储流量和常规流量。他们使用相同的共享接口来进行存储数据交换，从而导致网络和存储流量（在某些情况下甚至控制流量）相互竞争。这会影响性能和安全性。
