VNF 和 CNF 之间有何区别？

虚拟网络功能（VNF）是提供网络功能（如目录服务、路由器、防火墙、负载平衡器等）的软件应用。虚拟网络功能以虚拟机（VM）的形式部署，通常是电信提供商从专有硬件上传统网络设备的物理网络功能 (PNF) 进行数字化转型的下一个步骤。 

作为网络功能虚拟化（NFV）架构的关键组成部分，VNF 建立在 NFV 基础架构（NFVI）之上，包括像红帽® OpenStack® 这样的虚拟基础架构管理器（VIM），目的是在 VNF 之间有效分配计算、存储和网络等资源。由 NFV 定义的管理、自动化和网络编排（MANO）组件提供了用于管理 NFVI 和置备新 VNF 的框架。 

虽然 VNF 目前还属于标准网络架构，但随着数字服务提供商转向提供更敏捷的服务，它们仍具有局限性。在从物理要件到 VNF 的最初过渡中，供应商往往只是将嵌入式软件系统完全从设备中提取出来，然后创建一个大型虚拟机。然而，由于没有尝试优化这些虚拟机，他们创造的虚拟设备效率低，只具有单一用途，并且依然很难管理和维护。 

除此之外，很难使用这类传统 VNF 在云环境中实现可扩展性。有些人采取措施改进了他们的初始 VNF 实现方式，很多服务提供商则采用了通用的水平 NFVI 云平台，以简化他们的环境来运行大量 VNF。这些变化有助于使 NFV 成为 5G 或边缘网络的基础技术。然而，对于需要敏捷性、可扩展性和低开销的大规模 5G 或边缘部署来说，虚拟机的“重量”仍然会限制 VNF 的效率。 

采用云原生方法的数字服务提供商（同时使用集中式和

分布式应用位置）可以享受更高灵活性、可扩展性、可靠性和便携性带来的好处。超越虚拟化转向完全云原生设计有助于将所需效率和敏捷性推向一个新高度，从而快速部署市场和客户所需的创新、差异化的产品。

云原生方法的一大重要特点在于，它使用容器而不是虚拟机。容器支持用户将软件（如应用程序、功能或微服务）与运行所需的所有文件打包到一起，同时共享对操作系统和其他服务器资源的访问权限。这种方法便于在不同环境（开发、测试、生产等），甚至云之间，移动所含组件，同时保留全部功能。

云原生网络功能（CNF）从 VNF 演变而来，设计并实现为在容器内运行。对网络架构组件实施的这种容器化支持在同一集群上运行各种服务，并且更容易加入已经分解的应用程序，同时可以将网络流量动态导向正确的容器集。

这张图展示了网络功能的演变，从传统的垂直整合方式，到由通用虚拟机编排平台管理的 VNF，再到由通用容器编排平台管理的 CNF。

采用 CNF 可通过将很多功能转移到容器中来解决 VNF 的一些基本局限性。对网络组件实施容器化，能够在 IT 环境中跨集群管理这些功能的运行方式和运行位置。 

然而，CNF 不只是涉及对网络功能实施容器化。为了在容器打包之外充分发挥云原生原则的所有优势，需要进一步重新构建网络功能软件，如将其分解为微服务，在更新过程中允许多个版本，并使用通用负载平衡器或数据存储等可用平台服务。 

此外，随着对云原生环境的采用不断增加，在过渡期间， CNF 必须与传统 VNF 共存。数字服务提供商必须完全自动执行网络的开发、部署、维护和运营，以有效处理不断增长的需求、加快部署并降低复杂性。对于提供商来说，用于配置和部署的标准化方法、开源社区中成熟的工具以及严格的测试和认证比以往更加重要。

开放且一致的基础可以帮助电信提供商树立信心，让他们无论在哪里，无论业务覆盖范围有多大，都能可靠运行他们的服务。在 NFV 上构建该基础（使用 VNF）尤其是云原生架构（使用 CNF），可以提高灵活性和敏捷性。自动化在保证生态系统轻松高效地规模化运行方面发挥着关键作用，并支持数字服务提供商加快更改和增加服务与功能，以便更好地满足客户的需求和要求。