在三种类型的云资源（计算、存储和网络）中，网络似乎对云原生非功能性需求的抵抗力最强。例如，计算弹性通过虚拟机、容器和编配器进行合理分配，并通过CI/CD管道进行管理。在实施过程中似乎缺乏网络弹性。在本文中，我们展示了云原生网络功能是将网络应用程序引入云原生世界的一种尝试。但究竟什么是CNF，为什么它们很重要？

SDN重生？我们以前没试过吗？ 

软件定义网络（SDN）过去和现在都试图实现网络供应的自动化。云原生网络功能不是SDN的重生，而是从根本上不同的角度看待网络。从某种意义上说，云原生网络功能与SDN类似，因为它们是基于软件的解决方案，而不是基于硬件的解决方案。但是，云原生网络有一套全新的非功能需求，与SDN分开。云原生非功能需求优先考虑弹性和自动化¹，远远超过SDN。此需求的实现依赖于声明性配置。换句话说，云原生配置应该更喜欢说“它希望做什么”，而不是“它希望如何”完成。例如，网络声明性配置的一个含义是禁止硬编码IP地址。声明式配置允许整个系统自我修复²因为它使系统看起来更容易读取和做出响应。然后，可以使系统不断自我校正。云原生系统的其他非功能性需求包括弹性和可用性，但使用扩展冗余而非扩展技术实现。云原生系统试图通过提高可维护性和冗余性，使子组件具有更高的可用性，从而解决可靠性问题。例如，在云原生世界中，拥有一个具有多个冗余子组件的顶级组件，其中几个组件可用，但少数组件出现故障，这比单个紧密耦合但“高度可靠”的组件更可靠³.

超越虚拟化网络盒

在某种意义上，“网络功能”是不解耦的。虚拟网络功能（VNF）始于网络硬件的虚拟化。VNF具有硬件与虚拟化硬件的一一对应关系，一直到网卡、专用集成电路（ASIC）或整个交换机。虽然SDN似乎将物理网络机器虚拟化，但CNF不仅仅是容器化的网络虚拟机。CNF是关于进一步解耦网络功能的。CNF根据敏捷产品团队的发布周期，将网络功能划分为具有类似变化率的组件，而敏捷产品团队远离大公司的大型发布周期。产品团队发布的软件⁴可以被认为是微服务的“厚”定义。微服务的“瘦”定义是作为单一进程类型交付的软件⁵容器内部。通过将软件作为一个产品团队进行开发，我们发现在实践中，厚微服务通常看起来像薄微服务。 

编配器已经出现，可以帮助管理微服务。编配器负责调度、启动、停止和监控(生命周期)微服务。有许多协调器，其中Kubernetes（K8）是最流行的，但也有特定于域的编配器，例如电信领域的编配器。云原生生态系统的早期承诺之一是防止协调器K8被“割据”，K8s认证由CNCF维护，确保K8的任何分叉版本都支持社区要求的API和最佳实践。

什么是云原生网络功能？

云原生网络功能是位于OSI上某处的功能⁶已从云原生轨迹图中移除。CNF位置越低，一个好的云原生实现就越困难。这可能是因为网络需要与编配器和底层主机集成，同时保留其云原生属性。这也可能是因为将以前的网络功能（如转发平面的功能）分离为无共享的流程模型⁷，共享内存/线程模型会降低性能。 

为了理解解耦网络功能的影响，了解一点网络层背后的推理会很有帮助。OSI层的开发使网络创新得以实现，同时保持层间的互操作性。在网络层，IP协议最终成为大赢家。在数据链路层，出现了ARP。多个供应商在每个层中的协议级别进行迭代，创建新的协议和协议的新实现。云原生网络功能有机会在库内、微服务内实现为协议，甚至在网络应用程序内实现为一组微服务。

Ed Warnicke在网络服务网格项目曾表示，对于网络服务，“数据包是有效载荷”。这意味着网络应用程序或服务实际上对网络数据包或帧进行操作（转换、路由或分析）。以下是OSI模型各层的网络功能示例：

• 第7层：CoreDNS
• 第六层：NFF包检查器
• 第五层：Rsocket
• 第4层和第3层：Envoy/Network Service Mesh/Various CNI 插件
• 第二层：基于VPP的vSwitch

对于云原生网络应用程序或跨多个层的更高阶云原生网络功能，以下是一些示例：MATRIXX Software的5G融合充电系统和PANTHEON.tech公司的BGP服务器。

云原生跟踪图描述了云原生应用程序的成熟度。当我们深入到云原生化道路上的一个站点时，事情变得更加复杂，比如网络、策略和安全。这就是说，这些工具中有一种云原生反射性，可以帮助您成为云原生的。当将此应用于云原生网络功能时，我们最终必须像其他云原生应用程序一样实现网络功能。总结如下：

1. 第一步从粗粒度部署开始，通常作为容器实现。 
2. 第二步是将服务或应用程序部署在具有无状态和声明性配置的CI/CD管道中。 
3. 第三步是支持部署在同质节点上的协调器（例如K8s），该协调器管理服务的生命周期。
4. 第四步确保网络功能具有监测功能，这包括度量（如Prometheus）、跟踪（如Jaeger）和事件流兼容日志记录（如Fluentd）。 
5. 云原生成熟度的第五步，即服务发现，允许集群内部甚至外部的其他消费者发现网络服务。 
6. 为了便于声明性配置，第六步概述了策略的重要性，特别是网络和安全策略，因为这些策略是通过服务应用和支持的。 
7. 第七步是分布式存储，适用于使用有状态工作负载的情况，以确保与云原生环境的兼容性。 
8. 云原生消息传递、注册、运行时和软件分发是云原生成熟度的其他阶段应用程序的旅程。

CNF数据平面

使用CNF，数据平面⁸（也称为转发平面）进一步远离传统硬件。由于云原生重视向外扩展，而不是向上扩展，这意味着拥有更多同质商品节点比拥有更少的异构和专用节点更受欢迎。因此，出现了一种分解运动，即使用商业服务器代替专用网络交换机的专用集成电路（ASIC）。这样做的一个好处是出现了支持更敏捷的变化率的数据平面。虽然SDN数据平面（这里我们讨论的是真正转发数据包的内容）驻留在硬件ASIC上或使用传统内核网络转发的虚拟盒子中，但CNF已经开始探索用户数据平面等技术（例如VPP)、带有eXpress数据路径（XDP）的扩展Berkeley包过滤器（eBPF）和SmartNIC转发。

三层提升

在云原生数据中心中，有一个偏向三层解决方案。能够声明性地指定和自动化三层层网络的配置是Kubernetes网络模型开发中的一个决定性因素。这些新的云原生网络依赖IP地址来连接集群的节点和应用程序，而不是二层MAC和VLAN。然而，这主要是面向编配器及其应用程序的网络。数据中心有多个活动部件，在这个场景中变化速度不同。这三个层可以描述为编配器之下（使用网络操作系统，如SONIC，配置工具，如Terraform），编配器内部（如Kubernetes），以及编配器之上但在容器内（如CNF）。编配器之下的网络基础设施结构（如数据中心中的可能分解的顶层交换机）继续具有二层配置。电信领域是采用CNF的一大驱动因素，也继续存在无法避免的二层场景，例如多协议标签交换（MPLS）。二层结构的场景仍在用交换软件的新实现编写中，例如SONiC。

结论

网络的配置、部署和自动化是难以实现弹性的一些原因，弹性是云原生环境的主要组成部分。它可能是迁移到超级规模（如Amazon）的决定因素，即使需要更为定制的部署。这与电信领域特别相关，因为他们有自己的网络协议，可能希望为企业客户提供支持（例如MPLS）。云原生网络功能通过基于变化率解耦网络功能来解决这些部署问题，直至粗粒度映像和进程（例如，容器）级别。这避免了网络中容易出现的传统部署锁定问题。 

CNF是网络功能，这是一种传统上被认为位于OSI堆栈上的功能，它是按照云原生实践与云原生生态系统相结合来实现的。网络，尤其是电信网络，长期以来一直存在非功能性需求，例如弹性需求。电信服务提供商以911呼叫为例，将其作为一个任务关键型系统，要求具有极高的弹性和可用性。即便如此，云原生生态系统的非功能属性也得到了服务提供商的关注。这些属性，如可用性（云原生类型）、易部署性和灵活性，促使电信服务提供商向电信设备供应商（物理和软件）施加压力，使其更加云原生。这要求这些新的网络组件遵循云原生基础设施最佳实践，以便成为云原生生态系统中的成熟解决方案。这并不容易，因为很难将具有苛刻性能要求的传统紧密耦合组件（如网络数据平面）解耦。 

CNF领域的数据平面是一项正在进行的工作，有许多解决方案。仅仅是数据平面的概念就使得对CNF的理解复杂化了，因为CNF不仅仅是物理盒的虚拟化表示。在一个微不足道的层面上，通过专注于默认内核网络和三层IP4/IP6网络，云原生数据中心中的网络可以避免这种复杂性。这对于电信公司用例或网络结构的实现通常是不可行的。这些问题是解耦网络软件自然发展的一部分，因此无法避免它们。CNF做得好，有望实现前所未有的可部署性、弹性、易配置性和弹性。

要了解有关云原生网络功能的更多信息，请加入CNCF的云原生网络功能工作组，了解有关CNCF的信息CNF认证计划。

脚注参考资料:

1. “原生云是指不需要人类做决定的自主系统。它仍然使用自动化，但只在决定需要采取的行动之后。只有当系统无法自动决定该做什么时，才会通知人类。”——摘自“Cloud Native Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic Environment”（作者 Justin Garrion & Kris Nova，由 O'Reilly 出版）。

2. “自愈基础设施本质上是一种智能部署，能够自动响应已知和常见的故障。根据故障的不同，架构具有固有的弹性，并采取适当的措施来纠正错误。”——摘自“Cloud Native Architectures: Design high-availability and cost-effective applications for the cloud”（作者 Tom Laszewski，由 Packt 出版）。

3. “从直觉上看，一个系统的可靠程度取决于它最不可靠的组件（最薄弱的环节）。但事实并非如此：事实上，这是计算领域的一个旧想法，它的前提是在一个不太可靠的底层基础之上构建一个更可靠的系统。”——摘自“Designing Data-Intensive Applications”（作者 Martin Kleppmann，由 O'Reilly 出版）。

4. 跨职能团队将所有负责构建和运行系统某个方面的人员集合在一起，可能包括测试人员、项目经理、分析师、商业或产品所有者，以及不同类型的工程师。这些团队应该很小，亚马逊称之为“两个披萨团队”，意思是团队足够小，两个披萨足以喂饱每个人。这种方法的优点是，人们可以专注于单一的、集中的服务或少量服务，避免了在项目之间处理多任务。由一组固定人员组成的团队比那些成员每天都在变化的团队工作效率更高。——”Infrastructure as Code: Managing Servers in the Cloud”（作者 Kief Morris，由 O'Reilly 出版）。

5. “最好的方法是将容器视为一种打包服务、应用程序或作业的方法。它是一种升级版的 RPM，包含了应用程序及其依赖项，还为宿主系统提供了管理运行时环境的标准方法。我们不应该在一个容器中运行多个进程，而是使用多个容器，每个容器运行一个进程。这些进程成为独立的、松散耦合的实体。因此，容器非常适合用在微服务应用架构中。”——摘自“Infrastructure as Code: Managing Servers in the Cloud”（作者 Kief Morris，由 O'Reilly 出版）。

6. 为了尽量减少专有解决方案，创建网络系统的开放市场，并管理好通信的复杂性，国际标准化组织（ISO）开发了一种开放通信参考模型。这个参考模型被称为 ISO 开放系统互连（Open Systems Interconnection，OSI）参考模型，提出了一个抽象的、分层的网络模型。具体地说，它定义了七层抽象和每一层的功能。但是，它没有定义必须在每一层使用的特定协议，而是给出了与每一层对应的服务和协议的概念。——“Architecture of Network Systems”（作者 Dimitrios Serpanos & Tilman Wolf，由 Morgan Kaufmann 出版）。

7. “进程不共享内存，而是通过消息传递相互通信。消息从发送进程的栈复制到接收进程的堆。由于进程在独立的内存空间中并发执行，这些内存空间可以进行单独的垃圾回收，从而使 Erlang 程序具有非常可预测的软实时属性，即使在持续的高负载下也是如此。……异常发生时进程会失败，但由于没有共享内存，故障通常会被隔离，因为进程处理的是独立的任务。其他处理不相关或不受影响的任务的进程可以继续执行，程序作为一个整体可以进行自我恢复。”——摘自“Designing for Scalability with Erlang/OTP: Implement Robust, Fault-Tolerant Systems”（作者 Francesco Cesarini & Steve Vinoski，由 O'Reilly 出版）。

8. 路由器的数据平面实现了针对典型网络流量的一系列操作。如前所述，这些步骤包括处理已到达数据包的 IP，通过交换机结构传输到输出端口，以及调度对外传输。数据平面中的一个关键操作是确定将数据包发送到哪个输出端口。这个过程称为路由查找……——“Architecture of Network Systems”（作者 Dimitrios Serpanos & Tilman Wolf，由 Morgan Kaufmann 出版）。