通向容器化网络功能之路

【51CTO.com快译】服务提供商和公司企业正在如今基于云的应用软件中大量使用容器和微服务。它们希望使用网络功能虚拟化(NFV)对部署在边缘的通用CPE(uCPE)做同样的事情。

不过如今NFV的局限性之一是使用在虚拟机中运行的整体式虚拟网络功能(VNF)。用户希望与数据中心云中的工作保持一致，这意味着采用云原生方法实现VNF。这意味着将整体式架构分解成微服务架构，并实施到容器中。

这是个宏伟的目标，但技术尚不存在。除了几个少数例外，如今的VNF作为虚拟机中运行的整体式系统来实施，但这没问题!今天，有许多解决方案支持虚拟机和容器，因此没理由等待部署基于NFV的服务。

合适的平台推动创新

如今的VNF适合立即部署动态且具有成本效益的服务。它们提供了从硬件设备到虚拟化解决方案的无缝过渡。如果选择合适的平台，你可以从容地迁移到新上市的容器化网络功能(CNF)。已经有几种CNF实现了加密和测试代理之类的功能，它们可以与VNF共存。

虚拟机会消失吗?

没有理由认为虚拟机会消失。容器和虚拟机可以存在互为补充的关系，如下图所示。

容器的优点是占用较少的内存和磁盘空间，启动速度更快。另外，它们能够实现微服务架构。

但虚拟机在安全性以及对底层操作系统的依赖方面提供了更有效的隔离。此外，VNF实施在虚拟机中司空见惯，它们会存在很长时间。

因此，我们既需要虚拟机也需要容器，而合适的平台两者都支持。实际上，我们看到了虚拟机和容器今天共存的重要原因。

不妨以运营商想要使用容器来实现某些网络功能的托管服务为例。再假设最终用户希望能够运行自己的容器化功能。我与众多运营商有过交谈，他们都声称会使用虚拟机隔离最终用户的容器化应用程序。这将使最终用户应用程序与运营商直接在平台上运行的应用程序分开来。

归根结底，虚拟机和容器都很重要。你可以从今天的虚拟机入手，将来迁移过去，无需更换主机硬件。

但是网络性能如何呢?

CNF在大小和启动时间方面比虚拟机有优势。但是我在测试中看到，两者的网络性能相似。VNF和CNF都可以使用数据平面开发套件(DPDK)和加速vSwitch之类的技术来提供运营商级的性能。

别等了，现在就开始!

如果你有一种适应未来需要的平台，无需等待。你可以从当今众多的VNF入手，根据需要混合使用容器化应用程序。以后你可以从VNF迁移到CNF，无需升级硬件。

原文标题：The Road to Containerized Network Functions，作者：Prayson Pate

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】