Kubernetes联合创作者：电信公司的CNF可能需要其他协调器|5G_新浪财经

　　回调已砸出“黄金坑” 大资金调仓换股正当时？牛市氛围仍在，你还在等什么？点击立即开户，3分钟极速响应，专属通道福利多多！助你“抄底牛市”！

原标题：Kubernetes联合创作者：电信公司的CNF可能需要其他协调器来源：腾讯新闻

导语

VMware的Craig MucLuckie表示，云原生的电信基础架构将受益于Kubernetes原理，但需要大量定制。

正文

VMware的Craig MucLuckie表示，云原生的电信基础架构将受益于Kubernetes原理，但需要大量定制。

改变路线已经改变了企业数据中心的面貌：容器化基础架构。自动部署且不绑定到虚拟机的可移植组件，通常由自Linux以来最普及的新软件工具精心策划：Kubernetes。现在，电信公司正在准备启用容器化网络功能（CNF）-分布在整个云平台上的高度分布式，高弹性服务。与基于虚拟机管理程序的虚拟网络功能（VNF）同类产品相比，它们可能更易于管理，并且升级，维护，安全性甚至运营成本更低。

正如某些人所争论的那样，Kubernetes进入了电信数据中心，并进入了托管现代通信的5G数据包核心的核心。但是，还有其他一些人反对这种观点，他们说企业用来管理Web和云应用程序的业务流程风格不适用于电信业，因为电信业的租约是在更深层次的网络上得到保证的，并且功能分配成片的高安全性。

英特尔5G无线核心基础架构主管Chandresh Ruparel在最近的一次新闻发布会上解释说：“云是5G的基础，它是紧密相连的。” “运营商既要迁移到新的云原生框架，也要同时部署5G基础架构。” “云原生”一词通常描述一种基础架构，其中像Kubernetes这样的容器和协调器是基础。

Ruparel描述了两个英特尔改编的示例，即使用其容器网络接口（CNI）的Kubernetes插件。这些插件专门用于使Kubernetes在电信环境中充当协调器。一种是SR-IOV，它使PCI Express设备公开的物理资源可作为虚拟功能进行寻址。另一个名为Multus的产品利用了英特尔的数据平面开发套件（DPDK）（可在各地的电信环境中使用），使用户平面中的多个物理网络接口可在单个Kubernetes工作流程中寻址。两者均在2018年12月的英特尔文档［PDF］中进行了解释。

但是，在英特尔新闻发布会的同一周，一位首席思科5G工程师提出了令人信服的反驳。其主题的核心是：容器化并不一定要求使用Kubernetes。

思科首席5G架构师Aeneas Dodd-Noble表示：“ Kubernetes是为通用应用程序工作负载而设计的工具。“它不适用于网络应用程序。它们在性能，可用性，连接性，规模和冗余方面有独特的要求。这实际上意味着，那些对运行企业应用程序或Web应用程序有用的出色工具，并不是为运行电信应用程序（尤其是用户平面应用程序）而设计的。

那是什么呢？Kubernetes是重要资源，或者是圆孔中的方钉。至少从这些描述中，肯定不能两者兼而有之。

“我认为答案只是两者兼而有之，”克雷格·麦克卢基（Craig McLuckie）回答。他与Brendan Burns和Joe Beda一起是容器编排的先驱，他使Kubernetes成为Google的工程师。现在，McLuckie是VMware研究与开发副总裁。

“我倾向于这样看待：Kubernetes和云原生模式在5G核心空间中引入了巨大的机会，” McLuckie在接受数据中心知识专访时继续说道。“总的来说，我倾向于引导客户进入虚拟化环境，因为他们受益于资源隔离和安全隔离空间数十年来的工作，一直到硅片。在网络功能虚拟化［NFV］的情况下，显然，那些数据平面工作负载具有相对独特的配置文件。因此，就其运行时的运行时环境以及与调度模块的关系而言，自然将需要相对较高的自定义级别。”

他承认，解锁5G核心需要高度定制化。他认为，软件工程界可以整体解决此问题，以使其可行。

McLuckie补充说：“使它仍然是Kubernetes的是关于核心Kubernetes模式和功能是否仍然存在的问题。Kubernetes作为系统始终被构建为高度模块化，高度可插拔和高度可扩展。我认为这是其成功的基础。尽管您可能没有采取任何现有的Kubernetes上游发行版而没有进行修改，并且希望运行CNF工作负载并没有成功。..我确实相信，忠实于许多Kubernetes核心原则具有巨大的价值，因为它与构建和管理高度复杂的分布式系统有关。所以我的观点是，它介于两者之间。”

McLuckie提出了一个愿景，即基于Kubernetes 原理构建的数据平面工作负载协调器（如果不是系统本身），而是利用适合最初为Kubernetes开发的CNI接口的插件，将在5G核心和围绕它构建的云中普及。完成之后，它可能不会称为 Kubernetes，但最终可能取决于Intel，HPE和Cisco等实施者是否选择调用该映像。