本文译自 Cloud Native Network Functions Are Here，译者 Jimmy Song。
主要收获
- 云原生网络不是另一种方式的 SDN，它以一种完全不同的方式来看待网络。
- 虽然 SDN 似乎是把物理网络和机器做了虚拟化，但「云原生网络功能」（Cloud-native Network Functions，下文简称 CNF）不仅仅是容器化的网络和虚拟机，它还将网络功能分割成服务，这是 CNF 与 SDN 的一个主要区别。
- CNF 是 OSI 网络模型中的网络功能（越底层实现起来就越困难），这些功能是根据云原生实践实现的。
- 虽然 SDN 数据平面（这里指的是转发数据包）位于硬件 ASIC 上，或在传统内核网络转发的虚拟化盒子里，但 CNF 探索用户平面转发或更新的 eBPF 数据路径转发。
- 在云原生数据中心中，偏向于三层的解决方案，但 CNF 的一大驱动力是电信服务提供商，他们经常下降到二层的功能。
在三类云资源（计算、存储和网络）中，网络似乎最难满足云原生的非功能性需求。例如，计算弹性可以通过虚拟机、容器和编排器合理分配，并通过 CI/CD 管道进行管理。网络弹性似乎在实施中有所欠缺。在这篇文章中，我们展示了云原生网络功能将网络应用引入云原生世界的一种尝试。究竟什么是 CNF，为什么它们很重要？
SDN 重生？我们以前没有试过吗？
不论是在过去还是现在，软件定义网络（SDN）都试图实现网络配置的自动化。CNF 不是另一种 SDN，而是以一种完全不同的方式来看待网络。从某种意义上说，CNF 与 SDN 一样，都是基于软件而非硬件的解决方案。但云原生网络有一套全新的非功能要求，与 SDN 不同。云原生的非功能要求优先考虑弹性，并推而广之，自动化也比 SDN 多得多。这一要求的实现倚重于声明性配置。换句话说，云原生配置应该更喜欢说"想做什么"，而不是"想怎么做"。例如，声明式配置对网络的影响之一是禁止硬编码的 IP 地址。声明式配置允许整个系统自我修复，因为它使人们更容易读懂和回应系统应该是什么样子。然后可以使系统不断地自我修正。云原生系统的其他非功能要求是弹性和可用性，但用扩展冗余而不是扩展技术实现。云原生系统试图通过更高的可服务性和冗余度使子组件具有更高的可用性来解决可靠性问题。例如，在云原生系统中，如果一个顶级组件带有多个冗余的子组件，其中有几个组件是可用的，但有几个组件出现故障，这比一个紧密耦合但"高度可靠 "的组件更可靠。
超越虚拟化的网络盒子
在某种意义上，"网络功能"并没有被解耦。虚拟网络功能（VNF）开始是网络硬件的虚拟化。VNF 有一个硬件与虚拟化硬件的一对一对应关系，小到网卡、特定应用集成电路（ASIC），大到整个交换机。虽然 SDN 似乎采取物理网络机器并将其虚拟化，但 CNF 不仅仅是容器化的网络虚拟机。CNF 是关于进一步解耦网络功能的。CNF 根据敏捷产品团队的发布周期，将网络功能分组为具有类似变化率的组件，这就摆脱了大公司的大型发布周期。由产品团队发布的软件[^4] 可以被认为是微服务的"厚"定义。微服务的 “薄” 定义是指作为容器内的单一进程类型交付的软件。通过跟踪开发软件的产品团队，我们发现厚微服务在实践中往往看起来薄微服务很像。
为了管理微服务，出现了编排器。编排器负责微服务的调度、启动、停止和监控（生命周期）。有许多编排器，其中 Kubernetes（K8s）是最受欢迎的，但也有特定领域的编排器，如电信领域的编排器。云原生生态系统的早期承诺之一是使编排器 K8s 不被"碎片化"。由 CNCF 维护的官方K8s 认证，确保 K8s 的任何分叉版本都能支持社区规定的 API 和最佳实践。
究竟什么是云原生网络功能？
云原生网络功能（CNF）位于 OSI 模型的第六层，它出现在了云原生足迹图中。CNF 在堆栈中的位置越低，良好的云原生实现就越困难。这可能是因为网络需要与编排器和底层主机集成，同时保留其云原生属性。这也可能是因为将以前的网络功能（如转发平面的功能）从共享内存/线程模型中分离出来，形成一个无共享的进程模型，如果不仔细操作，会降低性能。
为了理解网络功能解耦的影响，了解一下网络层背后的原因是有帮助的。OSI 层的发展使网络创新得以发生，同时保持堆栈上下各层之间的互操作性。在网络层，IP 协议最终成为一个大赢家。在数据链路层，ARP 出现了。多个供应商在每一层的协议层面进行迭代，创造新的协议和协议的新实现。CNF 有机会作为库内的协议、微服务内的协议，甚至作为网络应用内的一组微服务来实现。
Network Service Mesh项目的 Ed Warnicke 曾经说过，对于网络服务来说，"数据包就是有效载荷"。这意味着网络应用或服务实际上是对网络数据包或帧进行操作（转换、路由或分析）。以下是 OSI 模型各层的网络功能的一些例子：
- 第七层：CoreDNS
- 第六层：NFF 数据包检查器
- 第五层：Rsocket
- 第四层和第三层：Envoy/Network Service Mesh/各种CNI插件
- 第二层：基于 VPP 的 VSwitch
对于云原生网络应用，或跨越多层的高阶 CNF，例如 MATRIXX 软件公司的5G 融合计费系统和PANTHEON.tech公司的BGP 服务器使用案例。
云原生足迹图在一定程度上描述了云原生应用程序的成熟度。当我们深入研究云原生道路上的每一步时，事情就会变得更加复杂，比如网络、策略和安全。这就是说，在帮助你实现云原生的工具中存在着云原生的反射性。当把它应用于 CNF 时，我们最终不得不像其他云原生应用一样实现网络功能。这方面的总结如下：
CNF 数据平面
有了 CNF，数据平面（也被称为转发平面）与传统硬件的距离更远。由于云原生原则重视扩展而不是扩大，这意味着拥有更多的同质化商用节点比拥有更少的异质化和专业化节点更受欢迎。正因为如此，出现了一种分解运动，用商用服务器来代替专门的网络交换机的特定应用集成回路（ASIC）。这样做的一个好处是，出现了支持更敏捷的变化速度的数据平面。虽然 SDN 数据平面（这里我们说的是字面意义上的转发数据包）停留在硬件 ASIC 上或传统内核网络转发的虚拟化盒子里，但 CNF 已经开始探索用户数据平面（如VPP）、eXpress Data Path（XDP）的扩展伯克利包过滤器（eBPF）和 SmartNIC 转发等技术。
三层网络升华
在云原生数据中心中，有一个偏向于三层的解决方案。能够声明性地指定和自动配置三层网络，这是发展 Kubernetes 网络模型的决定性因素。这些新的云原生网络依靠 IP 地址来连接集群的节点和应用，而不是第二层的 MAC 和 VLAN。然而，这主要是编排器及其应用程序的网络故事。数据中心有多个移动部件，在这个故事中的变化率不同。这三层可以说是在编排器下面（有 SONIC 等网络操作系统，Terraform 等配置工具），在编排器（如 Kubernetes）本身，以及在编排器上面但在容器（如 CNF）内。编排器下面的网络基础设施结构，如数据中心的架顶交换机（可能是分解的），继续拥有第二层配置。电信领域是采用 CNF 的主要驱动力，也继续有无法避免的第二层用例，如多协议标签交换（MPLS）。第二层结构的故事仍在用新的交换软件实现来书写，如SONiC。
总结
网络的配置、部署和自动化是难以实现弹性的一些原因，而弹性是云原生环境的主要优势。这可能是转移到超级服务器（如亚马逊）的决定性因素，即使是在需要更多定制部署的时候。这与电信领域特别相关，因为他们有定制的网络协议，他们可能想为企业客户提供支持（如 MPLS）。CNF 通过基于变化率的网络功能解耦来解决这些部署问题，一直到粗粒度的镜像和进程（如容器）级别。这就避免了网络容易出现的传统的锁步式部署问题。
CNF 是网络功能，也就是传统上认为位于 OSI 堆栈上的功能，遵循云原生实践来实现，它与云原生生态系统耦合。网络，尤其是电信网络，对非功能的要求由来已久，比如说弹性。电信服务提供商以 911 电话为例，将其作为一个要求极度弹性和可用性的关键任务系统。即便如此，云原生生态系统的非功能属性也得到了服务提供商的关注。这些属性，如可用性（云原生型）、易于部署和弹性，促使电信服务提供商对电信设备供应商（包括物理和软件）施加压力，使其更加云原生。这就要求这些新的网络组件遵循云原生基础设施的最佳实践，以便成为云原生生态系统中的成熟解决方案。这并不容易，因为要把传统上紧密耦合的、对性能有严格要求的组件（如网络数据线）解耦，是非常困难的。
CNF 空间中的数据平面是一项正在进行的工作，有许多解决方案。仅仅是数据平面的概念就使对 CNF 的理解变得复杂，因为 CNF 不仅仅是一个物理盒子的虚拟化表示。在一个微不足道的层面上，云原生数据中心的网络可以通过集中于默认的内核网络和第三层 IPv4/IPv6 网络来避免这种复杂化。这对于电信公司的用例或网络结构的实施通常是不可行的。这些问题是网络软件解耦的自然发展的一部分，所以没有办法避免。如果 CNF 做得好，就会带来以前没有意识到的可部署性、弹性、易配置性和弹性的新水平。
要了解更多关于云原生网络功能的信息，请加入 CNCF 的云原生网络功能工作小组。
