在三类云资源（计算、存储和网络）中，网络似乎最经得起云原生非功能性需求的考验。例如，计算弹性是通过虚拟机、容器和编配器合理分配的，并通过 CI/CD 管道进行管理。网络在实现方面似乎缺乏弹性。在本文中，我们将试图通过云原生网络功能将网络应用程序引入云原生世界。但究竟什么是 CNF，为什么它们如此重要？
软件定义网络（SDN）在过去和现在都是网络配置自动化的一种尝试。云原生网络功能并不是重生的 SDN，它以一种完全不同的方式看待网络。在某种意义上，云原生网络功能类似于 SDN，因为它们是基于软件而不是基于硬件的解决方案。但是，云原生网络有一组完全不同于 SDN 的非功能性需求。云原生非功能需求优先考虑通过弹性、自动化【脚注 1】，等等，比 SDN 要多得多。这个需求的实现依赖于声明式配置。换句话说，云原生配置更倾向于说它想要完成“什么”，而不是“如何”完成。例如，有一个禁止硬编码 IP 地址的网络声明式配置。声明式配置让整个系统具备了自愈的能力【脚注 2】，因为这样更容易读取和并做出适当的响应。然后，系统可以不断地进行自我修正。云原生系统的其他非功能需求是弹性和可用性，并通过横向扩展而不是垂直扩展技术来实现。云原生系统试图通过让子组件具有更高的可服务性和冗余性来解决可靠性问题。例如，在云原生环境中，拥有一个包含多个冗余子组件的顶级组件（其中几个组件可用，但少数组件出现故障）要比一个紧密耦合但“高可靠”的组件更可靠【脚注 3】。
在某种意义上，“网络功能”并不是解耦的。虚拟网络功能（VNF）始于网络硬件的虚拟化。VNF 的硬件与虚拟化硬件是一一对应的，下至网卡、特定于应用程序的集成电路（ASIC）或整个交换机。SDN 似乎是将物理网络机器虚拟化，但 CNF 不仅仅是容器化的网络虚拟机，它对网络功能进行进一步的解耦。CNF 根据敏捷产品团队的发布周期，从大公司的大发布周期中脱离出来，在功能上把网络分成具有相似变化速度的组件。由产品团队发布的软件【脚注 4】可以被认为是“厚”微服务。“薄”微服务是指作为容器内的单个进程类型【脚注 5】交付的软件。通过作为产品团队来开发软件，我们发现，在实践中，厚微服务常常看起来很像薄微服务。
编配器的出现为管理微服务带来了福音。编配器负责微服务的调度、启动、停止和监控（生命周期）。现在有许多编配器，其中Kubernetes（K8s）是最流行的，但也有特定于领域的编配器，例如电信领域的编配器。云原生生态系统早期的一个愿景是防止编配器 K8s 被“割据”。这是通过提供官方的 K8s 认证来实现的，该认证由CNCF维护，以确保 K8s 的分支版本都将支持社区要求的 API 和最佳实践。
云原生网络功能存在于 OSI 网络栈【脚注 6】之上，已从云原生轨迹图中移除。CNF 在网络栈的位置越低，就越难有好的云原生实现。这可能是因为网络需要与编配器和底层主机集成，同时保留其云原生属性，也可能是因为如果不小心将以前的网络功能（比如转发平面）从共享内存/线程模型分离到无共享进程模型【脚注 7】会降低性能。
要理解解耦网络功能的影响，就有必要了解一下网络分层背后的逻辑。OSI 网络栈允许网络出现创新，同时保持层之间的互操作性。在网络层，IP 协议最终成为大赢家。在数据链路层，出现了 ARP。供应商们在每一层的协议层进行迭代，创建出新的协议和新的协议实现。云原生网络功能可以实现为包含在开发库、微服务中的协议，甚至可以作为网络应用程序中的一组微服务来实现。
网络服务网格项目的 Ed Warnicke 曾经说过，对于网络服务来说，“数据包就是有效载荷”。这意味着实际操作（转换、路由或分析）网络数据包或数据帧的是网络应用程序或服务。以下是 OSI 模型各层网络功能的一些例子。
有了 CNF，数据平面【脚注 8】（也称为转发平面）更进一步地远离了传统硬件。由于云原生更重视横向扩展而不是垂直扩展，这意味着拥有更多同构商业化节点比拥有更少的异构专门节点更可取。正因为如此，出现了一种使用商业化服务器来取代专用网络交换机 ASIC 的呼声。这样做的一个好处是出现了一种支持更敏捷的变更速度的数据平面。SDN 数据平面（这里我们讨论的是真正转发数据包的东西）位于硬件 ASIC 或传统内核网络转发的虚拟机上，而 CNF 已经开始探索像用户数据平面（例如 VPP）、带有快速数据路径（XDP）的扩展 Berkeley 包过滤器（eBPF）和 SmartNIC 转发等技术。
（免费订阅,永久学习）学习地址: Dpdk/网络协议栈/vpp/OvS/DDos/NFV/虚拟化/高性能专家-学习视频教程-腾讯课堂
更多DPDK相关学习资料有需要的可以自行报名学习,免费订阅,永久学习,或点击这里加qun免费
领取,关注我持续更新哦! !
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）实现来续写。
网络的配置、部署和自动化是难以实现弹性（云原生环境的一个主要部分）的部分原因。这可能是影响向超规模（如Amazon）迁移的决定性因素，即使可以保证更定制化的部署。这与电信领域尤其相关，因为他们可能希望为企业客户提供自定义网络协议支持（例如，MPLS）。云原生网络功能根据变化速率解耦网络功能，细化到粗粒度镜像和进程（例如容器）级别，解决了这些部署问题。这避免了网络容易出现的同步部署问题。
CNF 是一种网络功能，传统上被认为是位于 OSI 网络栈上的功能，只是在实现方面遵循了与云原生生态系统耦合的云原生实践。网络，尤其是电信网络，有很长一段非功能性需求的历史，比如弹性。电信服务供应商以 911 呼叫系统为例，它就是一个要求极端弹性和可用性的关键任务系统。即便如此，云原生生态系统的非功能属性已经引起了服务供应商的注意。这些属性，例如可用性（云原生类型）、易于部署和弹性，已经促使电信服务供应商向电信设备供应商（物理和软件）施加压力，要求它们更多地采用云原生。这要求这些新的网络组件遵循云原生基础设施最佳实践，以便在云原生生态系统中成为成熟的解决方案。但这并不容易，因为对于具有高性能要求的传统紧耦合组件（如网络数据平面）来说，要将它们解耦是非常困难的。
CNF 数据平面是一项正在进行当中的工作，有许多解决方案。光是数据平面概念就足以让 CNF 变得难以理解，因为 CNF 不仅仅是一个物理服务器的虚拟化表示。简单地说，云原生数据中心中的网络连接可以通过专注于默认的内核网络和 Layer 3 IP4/IP6 网络来避免这种复杂性。这对于电信来说通常是不可行的。这些问题是解耦网络软件的自然进程的一部分，所以没有办法避免它们。如果 CNF 做得好，就能达到以前没有达到的更高水平的可部署性、弹性、易于配置和弹性。
要了解有关云原生网络功能的更多信息，请加入 CNCF 的云原生网络功能工作组。这里可以找到有关 CNF 认证计划的信息。
脚注参考资料:
作者简介：
Wavell Watson 已有 30 年从事软件开发的经验。为了追求软件协作的完美组织结构，他花了数年时间研究博弈论和其他商业专业知识。他还创立了 Austin Software Cooperatives，并将 Vulk Coop 作为团队开发软件的另一种方式。他拥有多元化的背景，包括在海军陆战队担任计算机程序员，以及在多个行业（包括国防、医疗、教育和保险）开发软件。在过去的几年里，他一直在开发补充性的云原生系统，比如 cncf.ci 仪表盘。他目前从事与云原生网络功能（CNF）认证和云原生网络功能测试套件相关的工作。
原文链接：
Cloud Native Network Functions Are Here