网络功能虚拟化（NFV）是开放网络能力的必经之路，目前主流的方式是通过OpenStack的编排能力实现NFV的快速自动化部署。随着容器技术的快速发展，容器编排能力也在飞速提升，通过容器实现NFV是大势所趋，但前进之路崎岖蜿蜒。路漫漫其修远兮，吾将上下而求索，各大厂商在NFV容器化之路上披荆斩棘，取得了不小的进展，这篇文章就是介绍Red Hat的NFV容器化相关的思考。
网络功能虚拟化（NFV）在电信行业和大企业中被广泛采用。NFV的初衷很简单：将之前运行在专用设备上的网络能力虚拟化，并使其运行在通用型服务器硬件上。使用通用型计算基础设施的规模经济效益，至少在原理上远远超过使用专用设备。
通常我们所说的NFV部署指的是在虚拟机中运行网络功能，例如在基于内核或者ESXi的虚拟机上运行网络功能虚拟化，更LOW一点的做法就是在Hyper-V虚拟化层上运行。虚拟机（VMs）提供与主机操作系统完全的隔离，但是性能也会有一定的损耗。尽管较新的一些技术能够减轻内核的工作负载，比如DPDK（Data Plane Development Kit）和SR-IOV（Single Root Input/Output Virtualization）。但是即使是使用支持企业级通信的数据包，并保持高吞吐量性能的情况下，一台物理主机上的虚拟机数量仍然受到限制。
接下来的问题就是，这些网络功能能否被容器化，以满足微服务的模型？容器化之后的网络功能，其性能是否比虚拟机更好？这些容器化的网络功能的扩展性如何？诸如此类的问题还很多。
我们先简要地回顾下什么是容器化。容器化是一个轻量级的机制来实现进程隔离，以便于限制其与指定的资源进行交互。容器在Linux中早已存在，只是最近由于开源项目Docker才变得流行起来。通常每个容器提供单个服务。例如，在NFV环境中，单个服务可以被认为是在容器中运行动态主机配置协议（DHCP）服务器，或者网络地址转换（NAT）功能。您可以运行多个NAT容器，每个客户/租户一个容器为虚拟专用网路（VPN）里面的设备提供网络地址转换能力。
目前为止已经完成的一些POC（proof-of-concept）表明，网络功能容器化之后，通过Linux容器（LXC）、Docker或者Rocket（另一种Linux容器）来运行，相对于通过虚拟机运行优势是非常明显的。然而，当规模较大的时候，结果就很差强人意。例如，一个提供商希望为每个服务器部署超过1000个虚拟客户端设备（vCPE）容器，但在测试中几乎无法达到100个。
我相信某些网络功能通过容器化的形式更好，但是其他的某些功能仍然适合通过虚拟机部署。谈到容器，我们才刚开始研究，但是通过虚拟机部署，我们已经至少两年前就开始了。对于容器化某些特定网络功能还是抱有极大兴趣的，比如vCPE、NAT、个人防火墙、应用防火墙、IP地址管理，甚至是控制层面的一些功能，比如基于LTE（VoLTE）网络的IP多媒体子系统（IMS）/语音的呼叫会话控制功能（CSCF）。这其中的一些工作正在进行中，可能越来越多的供应商会首先将其容器化，然后对容器的性能进行调优。
Red Hat从Red Hat Enterprise Linux 6.0开始支持Linux容器，差不多六年了。OpenShift是Red Hat的平台即服务（PaaS），是默认的容器管理引擎。最近发布的OpenShift 3.0，Red Hat增加了对Docker容器的支持。红帽还与一些大型服务提供商合作，尝试和运行概念验证（POC）容器化NFV用例，如IMS VoLTE和vCPE。随着这一变化，我希望读者能够了解NFV和容器的进展，也许可以提供有关未来容器上VNF性能的详细文章。
现在容器化是NFV的一个有趣的概念，它仍处于实验阶段。在接下来的12个月中，将有更多的POC和试验将提供有价值的反馈，以提高NFV容器的性能。并不是网络功能容器化本身阻碍了NFV中的微服务，而是容器的性能和规模。随着性能和规模的提高，VNF容器将会被更广泛地采用。
在此期间，您可以参加本周的旧金山Red Hat Summit 2016，了解有关容器，NFV和VM性能的很多信息。
【3天烧脑式微服务架构训练营 | 上海站】本次培训涉及：DevOps？微服务？需要解决的问题、回归、微服务那些事儿、Spring Cloud简介、服务发现：Eureka、客户端负载均衡：Ribbon、声明式的客户端：Feign、使用断路器实现微服务容错：Hystrix、微服务网关：Zuul、统一配置管理：Spring Cloud Config、微服务跟踪：Spring Cloud Sleuth、Spring Cloud常见问题总结等，点击下面图片即可查看具体培训内容。
点击阅读原文链接可直接报名。
