![]()
历史经验告诉我们，网络永远是最后的难题——从大型机到虚拟机，再到现在的容器，而所有这些小实体都必须相互通信。
在过去30年的大部分时间里，我们通过以太网实现了这种通信，其中应用层的不同通信端使用IP地址和端口号相互绑定。但是，当这些计算部分缩小到容器大小时，这是否还有意义呢？
如果两个容器位于同一个物理机上，在相同的虚拟机管理程序上，在同一个Docker实例上，你是否真的需要一直跳到NIC以便于它们之间的通信？应用层寻址是否保持不变？使用overlay来促进这种通信会更好吗？你是用L2还是L3？那么多租户呢？
所有这些问题都说明Kubernetes网络是难题。
Kubernetes网络基础知识
在理解Kubernetes基础知识之前，理解Kubernetes所克服的Docker网络局限性非常有用。这并不是说Docker网络本质上是“邪恶”的，只是容器引擎的范围往往是单个物理机或虚拟机，因此当考虑一系列容器引擎时，自然会出现问题。
Docker model默认情况下使用主机—私有网络，创建一个虚拟网桥和一系列映射，以便容器在同一台机器上对话。但是，不同机器上的容器需要端口分配和转发或代理以便相互通信。
随着应用程序的规模不断扩大，并且利用基于微服务的应用程序体系结构，这种体系结构需要许多容器（如果不是数百个容器分布在多台机器上），伸缩性就不尽如人意了。而且，这个网络方案是为了在单台机器上运行而出现的，它确实支持CNM模型，可以实现多主机网络，但考虑到它的初衷，它不适合集群。
“Kubernetes model”不仅要解决核心集群问题，而且还要允许针对不同情况有多种实现并后向兼容单节点。这种模式的基本原理是所有的容器和节点都可以在没有NAT的情况下相互通信，一个容器看到的自己的IP地址与别的容器或节点看到的相同。
Kubernetes术语中关于pod的基本定义是：它是“一组具有共享存储/网络的一个或多个容器，以及如何运行容器的规范”。
因此，位于同一个pod中的容器共享相同的IP和端口空间，并且可以使用本地主机彼此访问。这满足了单容器引擎的后向兼容性设计目标。
然而，更常见的是，应用程序中的微服务运行在不同的pod中，因此它们必须以更复杂的方式发现并访问彼此，而不是简单地使用本地主机。这种机制在Kubernetes中被抽象出来，有多种实现方法——最流行的是使用overlay、underlay或native L3。
overlay方法使用的是与底层物理网络去耦的虚拟网络。这个虚拟网络上的pod可以很容易地找到彼此，这些L2网络可以彼此隔离，必要时需要它们之间的L3路由。
underlay方法将L2网络连接到节点的物理NIC，从而将该pod直接暴露给底层物理网络而无需端口映射。在这里可以使用桥接模式来使pod能够在内部进行互连，以便流量在不是必要时不会离开主机。
native L3方法在数据平面上不包含overlay，这意味着利用节点主机和外部网络路由器做出路由决策，pod-to-pod的通信发生在IP地址上。pod-to-pod的通信可以利用BGP peering来不离开主机，如果需要的话，NAT可以用于输出流量。
应用程序的需求和规模（包括可能需要在集群外使用的其他资源）将决定哪种网络方法适合你，并且每种方法都有各种开源和商业实施方案。
但Kubernetes不是在“真空”中运行
Kubernetes集群很少在纯粹的新建环境中部署。相反，它被部署用于支持业务线开发团队的快速迭代工作，以便将创新注入到现有服务中。
举个例子，在选择overlay方法时，虚拟机主机上的容器需要与物理网络中其他位置的服务进行通信，现在它要跳过多个层，每层都可能带入不同数量的、可能会降低性能的延迟。因为这些基于微服务的应用程序并不常在”真空”中运行，所以在选择方法和实施时需要仔细考虑，并且在同一组托管应用程序中为一个应用程序所做的选择可能与另一个应用程序不同。
为什么基于策略的Kubernetes网络管理很有意义？
开发人员喜欢微服务，因为它使他们能够构建具有更小的、更隔离的组件的解决方案，这些组件可以通过API对话。只要这些API没有改变，它们就充当组件之间的”契约”，而且这些组件可以彼此独立地部署，使发布更容易、更快。
但正如所有其他底层基础设施的管理一样，复杂性的增加会造成管理难题。你的集群应该有多少个节点？当你后来改变主意时会发生什么？如何管理因为运行的多个应用程序有不同的需求而一个集群使用overlay网络，另一个使用native L3的情况？你采取了哪些管理措施来保持一致性和安全性？
这些问题摆在了管理Kubernetes集群的团队面前，而答案与解决其他基础架构管理难题的一样：策略。
管理员在管理软件定义网络和其上的虚拟机时发现，手动管理的“东西”的数量在某些时候难以继续增加。Kubernetes集群管理会使得，要管理的“东西”的数量大幅增加，并且在这个新的容器集群中人工干预不可持续。通过基于策略的管理实现自动化管理并实施最佳实践，成为一个明确的选择，无论单个应用程序的具体Kubernetes网络方法是什么。 因此，你可能正在管理越来越多的基于微服务的应用程序，无论这些应用程序是需要overlay、underlay或native L3网络，请确保你选择的任何实施方案都提供了通过使用合适插件的策略管理Kubernetes集群网络的选择。否则，在集群中实施变更并保持一致性将很快变得不可能。但通过策略自动化管理意图，你可以随时准备好满足应用的需求。
本文转移K8S技术社区-拿什么拯救你 Kubernetes网络之殇
