重生的 SDN？云原生网络功能介绍

2022 年 9 月 6 日 InfoQ

作者 | Wavell Watson

译者 | 明知山

策划 | 丁晓昀

在三类云资源（计算、存储和网络）中，网络似乎最经得起云原生非功能性需求的考验。例如，计算弹性是通过虚拟机、容器和编配器合理分配的，并通过 CI/CD 管道进行管理。网络在实现方面似乎缺乏弹性。在本文中，我们将试图通过云原生网络功能将网络应用程序引入云原生世界。但究竟什么是 CNF，为什么它们如此重要？

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

软件定义网络（SDN）在过去和现在都是网络配置自动化的一种尝试。云原生网络功能并不是重生的 SDN，它以一种完全不同的方式看待网络。在某种意义上，云原生网络功能类似于 SDN，因为它们是基于软件而不是基于硬件的解决方案。但是，云原生网络有一组完全不同于 SDN 的非功能性需求。云原生非功能需求优先考虑通过弹性、自动化【脚注 1】，等等，比 SDN 要多得多。这个需求的实现依赖于声明式配置。换句话说，云原生配置更倾向于说它想要完成“什么”，而不是“如何”完成。例如，有一个禁止硬编码 IP 地址的网络声明式配置。声明式配置让整个系统具备了自愈的能力【脚注 2】，因为这样更容易读取和并做出适当的响应。然后，系统可以不断地进行自我修正。云原生系统的其他非功能需求是弹性和可用性，并通过横向扩展而不是垂直扩展技术来实现。云原生系统试图通过让子组件具有更高的可服务性和冗余性来解决可靠性问题。例如，在云原生环境中，拥有一个包含多个冗余子组件的顶级组件（其中几个组件可用，但少数组件出现故障）要比一个紧密耦合但“高可靠”的组件更可靠【脚注 3】。

2 超越虚拟化网络

在某种意义上，“网络功能”并不是解耦的。虚拟网络功能（VNF）始于网络硬件的虚拟化。VNF 的硬件与虚拟化硬件是一一对应的，下至网卡、特定于应用程序的集成电路（ASIC）或整个交换机。SDN 似乎是将物理网络机器虚拟化，但 CNF 不仅仅是容器化的网络虚拟机，它对网络功能进行进一步的解耦。CNF 根据敏捷产品团队的发布周期，从大公司的大发布周期中脱离出来，在功能上把网络分成具有相似变化速度的组件。由产品团队发布的软件【脚注 4】可以被认为是“厚”微服务。“薄”微服务是指作为容器内的单个进程类型【脚注 5】交付的软件。通过作为产品团队来开发软件，我们发现，在实践中，厚微服务常常看起来很像薄微服务。

编配器的出现为管理微服务带来了福音。编配器负责微服务的调度、启动、停止和监控（生命周期）。现在有许多编配器，其中 Kubernetes（K8s）是最流行的，但也有特定于领域的编配器，例如电信领域的编配器。云原生生态系统早期的一个愿景是防止编配器 K8s 被“割据”。这是通过提供官方的 K8s 认证来实现的，该认证由 CNCF 维护，以确保 K8s 的分支版本都将支持社区要求的 API 和最佳实践。

3 究竟什么是云原生网络功能？

云原生网络功能存在于 OSI 网络栈【脚注 6】之上，已从云原生轨迹图中移除。CNF 在网络栈的位置越低，就越难有好的云原生实现。这可能是因为网络需要与编配器和底层主机集成，同时保留其云原生属性，也可能是因为如果不小心将以前的网络功能（比如转发平面）从共享内存 / 线程模型分离到无共享进程模型【脚注 7】会降低性能。

要理解解耦网络功能的影响，就有必要了解一下网络分层背后的逻辑。OSI 网络栈允许网络出现创新，同时保持层之间的互操作性。在网络层，IP 协议最终成为大赢家。在数据链路层，出现了 ARP。供应商们在每一层的协议层进行迭代，创建出新的协议和新的协议实现。云原生网络功能可以实现为包含在开发库、微服务中的协议，甚至可以作为网络应用程序中的一组微服务来实现。

网络服务网格项目的 Ed Warnicke 曾经说过，对于网络服务来说，“数据包就是有效载荷”。这意味着实际操作（转换、路由或分析）网络数据包或数据帧的是网络应用程序或服务。以下是 OSI 模型各层网络功能的一些例子。

第 7 层：CoreDNS；
第 6 层：NFF 包检查器；
第 5 层：Rsocket
第 4 层和第 3 层：Envoy/Network Service Mesh/Various CNI 插件；
第 2 层：基于 VPP 的 VSwitch。

对于云原生网络应用，或更高阶的跨多层云原生网络功能，例如 MATRIXX Software 的 5G 融合计费系统和 PANTHEON.tech 的 BGP 服务器。

云原生轨迹图在一定程度上描述了云原生应用程序的成熟度。当我们深入研究云原生化道路上的某一站时，事情会变得更加复杂，就像网络、策略和安全性一样。这就是说，帮助你走向云原生的工具中有一种原生云自反性。如果讲这些也应用在云原生网络功能上，那么我们最终必须像其他云原生应用程序一样实现网络功能。总结如下。

第 1 步从粗粒度的部署开始，通常用容器来实现。
第 2 步是使用无状态和声明式配置将服务或应用程序部署到 CI/CD 管道中。
第 3 步是支持部署在同构节点上的编配器（例如 K8s），用于管理服务的生命周期。
第 4 步确保网络功能具有遥测功能，包括指标（例如，Prometheus）、跟踪（例如，Jaeger）和兼容事件流的日志（例如，Fluentd）。
云原生成熟度的第 5 个步骤是服务发现，集群内部甚至外部的其他消费者可以用它来发现网络服务。
为了方便声明式配置，第 6 步概述了策略的重要性，特别是网络和安全策略。
第 7 步是分布式存储，适用于使用有状态工作负载的地方，以确保兼容云原生环境。
云原生消息传递、注册表、运行时和软件分发是云原生成熟度的其他阶段，这些阶段将完成应用程序的整个旅程。

4 CNF 数据平面

有了 CNF，数据平面【脚注 8】（也称为转发平面）更进一步地远离了传统硬件。由于云原生更重视横向扩展而不是垂直扩展，这意味着拥有更多同构商业化节点比拥有更少的异构专门节点更可取。正因为如此，出现了一种使用商业化服务器来取代专用网络交换机 ASIC 的呼声。这样做的一个好处是出现了一种支持更敏捷的变更速度的数据平面。SDN 数据平面（这里我们讨论的是真正转发数据包的东西）位于硬件 ASIC 或传统内核网络转发的虚拟机上，而 CNF 已经开始探索像用户数据平面（例如 VPP）、带有快速数据路径（XDP）的扩展 Berkeley 包过滤器（eBPF）和 SmartNIC 转发等技术。

5 Layer 3 提升

云原生数据中心偏向于 Layer 3 解决方案。能够声明式地指定和自动化 Layer 3 网络配置已经成为 Kubernetes 网络模型发展中的一个决定性因素。这些新的云原生网络依赖 IP 地址来连接集群的节点和应用程序，而不是 Layer 2 的 MAC 和 VLAN。然而，这是编配器及其应用程序的主要关注点。数据中心有多个移动部件，它们具有不同的变化速度。这三个层是这样的：在编配器之下（例如网络操作系统 SONIC、配置工具 Terraform）、在编配器中（例如 Kubernetes）、在编配器之上但在容器中（例如 CNF）。编配器之下的网络基础设施结构，例如数据中心中的机架顶部交换机，仍然具有 Layer 2 配置。电信领域是采用 CNF 的一个重要驱动因素，它仍然不可避免地继续使用 Layer 2，例如多协议标签交换（MPLS）。Layer 2 的故事仍在通过新的交换软件（如 SONiC）实现来续写。

6
结论

网络的配置、部署和自动化是难以实现弹性（云原生环境的一个主要部分）的部分原因。这可能是影响向超规模（如 Amazon）迁移的决定性因素，即使可以保证更定制化的部署。这与电信领域尤其相关，因为他们可能希望为企业客户提供自定义网络协议支持（例如，MPLS）。云原生网络功能根据变化速率解耦网络功能，细化到粗粒度镜像和进程（例如容器）级别，解决了这些部署问题。这避免了网络容易出现的同步部署问题。

CNF 是一种网络功能，传统上被认为是位于 OSI 网络栈上的功能，只是在实现方面遵循了与云原生生态系统耦合的云原生实践。网络，尤其是电信网络，有很长一段非功能性需求的历史，比如弹性。电信服务供应商以 911 呼叫系统为例，它就是一个要求极端弹性和可用性的关键任务系统。即便如此，云原生生态系统的非功能属性已经引起了服务供应商的注意。这些属性，例如可用性（云原生类型）、易于部署和弹性，已经促使电信服务供应商向电信设备供应商（物理和软件）施加压力，要求它们更多地采用云原生。这要求这些新的网络组件遵循云原生基础设施最佳实践，以便在云原生生态系统中成为成熟的解决方案。但这并不容易，因为对于具有高性能要求的传统紧耦合组件（如网络数据平面）来说，要将它们解耦是非常困难的。

CNF 数据平面是一项正在进行当中的工作，有许多解决方案。光是数据平面概念就足以让 CNF 变得难以理解，因为 CNF 不仅仅是一个物理服务器的虚拟化表示。简单地说，云原生数据中心中的网络连接可以通过专注于默认的内核网络和 Layer 3 IP4/IP6 网络来避免这种复杂性。这对于电信来说通常是不可行的。这些问题是解耦网络软件的自然进程的一部分，所以没有办法避免它们。如果 CNF 做得好，就能达到以前没有达到的更高水平的可部署性、弹性、易于配置和弹性。

要了解有关云原生网络功能的更多信息，请加入 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 出版）。

作者简介：

Wavell Watson 已有 30 年从事软件开发的经验。为了追求软件协作的完美组织结构，他花了数年时间研究博弈论和其他商业专业知识。他还创立了 Austin Software Cooperatives，并将 Vulk Coop 作为团队开发软件的另一种方式。他拥有多元化的背景，包括在海军陆战队担任计算机程序员，以及在多个行业（包括国防、医疗、教育和保险）开发软件。在过去的几年里，他一直在开发补充性的云原生系统，比如 cncf.ci 仪表盘。他目前从事与云原生网络功能（CNF）认证和云原生网络功能测试套件相关的工作。

原文链接：

https://www.infoq.com/articles/cloud-native-network-functions/#theCommentsSection

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！

今日好文推荐