后 OpenStack 时代，以容器为代表的虚拟化技术将有怎样的演进？

进入 21 世纪后，虚拟机技术进入相对成熟阶段，由于虚拟机的“笨重”，开发者们开始追求一种更加轻便的虚拟化技术。2010 年，由 NASA 和 Rackspace 联合开发的开源平台 OpenStack 诞生，帮助服务商和企业实现云基础架构服务。它将开源、开放的思想带到了云原生领域，并为云原生发展掀开了新篇章。

2020 年，OpenStack 基金会更名为开放基础设施基金会 OIF，OpenStack 从“云”拓展到了“开放基础设施”。

紧接着，OpenStack 从最初的虚拟化管理 Nova 和对象存储 Swift ，逐渐发展到包含虚拟化管理、SDN、SDS 服务编排和容器管理等功能覆盖全面的开源项目集合。同时紧跟云原生技术演进潮流，与容器、Kubernetes、AI 相关的更多开源技术紧密合作。2021 年 11 月，OIF 基金会宣布了开放基础设施的新标准 LOKI —— Linux、OpenStack、Kubernetes 等组成的开放基础设施管理软件。

在今年 4 月，OIF 发布了 OpenStack Yoga 版本，并宣布，待下一个被称为终结者的 Zed 版本发布之后，OpenStack 将以稳定的状态成为企业 IT 的生产级工具。这意味着云原生逐渐进入后 OpenStack 时代，2017 年起，各大云厂商都陆续开始包装和提供容器的商业化服务，提供基于 Kubernetes 的商业服务产品，容器技术逐渐走向成熟和标准化、商业化，成为虚拟化的新代表产品，围绕容器发展的云原生逐渐走向普适的阶段，已经应用容器的企业正在进行着云原生的新一轮技术演进。

一、后 OpenStack 时代的 Kubernetes ：从“解决难用”到“用的好”

数字化转型的加速增加了企业对于云原生的需求，容器技术覆盖率提高，IDC 预测，容器软件市场在近几年呈爆发式增长，并且未来五年仍然会保持超过 40% 的复合增长率。

进而，企业对容器管理的需求会直线提升，容器管理成为企业数字化转型的主战场。据 Gartner 预测，到 2025 年，成熟经济体中 85% 的大型企业将更多地使用容器管理。

如今在大多企业的业务场景中，企业组织需要确保多个容器可同时协同工作，这方面的工作大部分都是又编排引擎完成。随着 Kubernetes 的兴起与演进，目前已经克服了容器编排过程中许多技术挑战。

或许因为 Kubernetes 想要解决的问题太多，所以导致其复杂度很高，于是不少企业也在应用其他容器管理解决方案。然而市场数据证明，Kubernetes 依旧是大多企业的选择。CNCF 最近的一份报告显示，Kubernetes 在全球已拥有近 600 万个企业用户，成为云上应用程序主要的部署模式。

尽管 Kubernetes 覆盖率高，但这也并不意味着已经在应用它的用户满意，常被吐槽“难用但还很需要”。在 Kubernetes 的实际使用过程中，经常会遇见一些“难用”问题，比如创建容器时间过长、低吞吐量 / RPS / 突发并发、容器扩展速度慢、集群扩展速度慢、Sidecar 资源开销、资源利用率低等，为此，英特尔提出了创新的“SW+HW 功能解析”解决方案，开发工作主要集中在资源编排（Orchestration）和可观测行（Observability）两方面：

• 基于快照 + 热代码块来创建容器；

• 分片式多调度器；

• 弹性 POD 的自动扩展；

• 基于遥测的快速预测，用于实时扩展的决策；

• 动态插入 / 删除 POD 中的 Sidecar 容器；

• 链接设备的亲和调度 / 分配 (NUMA, GPU+Smart NIC 等)；

• 实时 “节点资源变化” 反馈给 Kubernetes 调度器。

以上提到的这些技术都符合 Kubernetes 的 API 规范并可与现有的 API 兼容，确保用户在不修改已有 Kubernetes 代码的情况下便能安装使用。为了方便用户测试、评估这些技术，英特尔还直接提供了容器镜像的方式让用户可以通过 Operator 等标准的 Kubernetes 应用部署方法来安装部署。

解决完容器“难用”问题，就要接着考虑如何“用得好”的问题。“用的好”的前提是选对架构。在后 OpenStack 时代，企业使用云原生架构的目的是追求敏捷、弹性、高性能和效率。要想达到这些目的，单纯依靠软件层面的优化是不够的，以 Serverless 为例，很多部署中会出现的问题，比如函数冷启动等，都需要通过硬件层面的优化来解决。

随着数据逐渐扩散至边缘场景，越来越多的企业期望通过云原生架构实现云边端一体化协同的基础设施，英特尔一直在为此做出努力，聚焦企业发展不同阶段的不同需求，针对性提出架构优化方案。

其次，企业部分广泛存在的 AI 诉求也对“用得好”提出了挑战。如今几乎每个应用功能都离不开 AI，然而 AI 模型从开发进入到生产部署阶段面临着多重困难和挑战。一般而言，AI 模型需要经过大量的调试和测试，通常需要 2-3 天才能部署上线；而且 AI 线上服务计算资源通常较固定，对于突发需求资源响应慢，又面临着业务扩展难的问题。

作为云原生的核心技术， Kubernetes 能够管理云平台中多个主机上的容器化应用，能够完成 AI 资源的统一部署、规划、更新、维护，有效提高 AI 资源管理率。此外，在基于  Kubernetes 的 AI 开发平台建设实践中，使用 CPU 服务器可有效利用空置资源、空闲时间，并通过  Kubernetes 的弹性资源调度分配给其它应用。而且 CPU 作为通用算力提供者，在采购成本、使用难度等方面有着重要优势，不仅支持 AI 运算，还可用于其他应用负载。

在 Kubernetes 发布初期，针对 CPU 和内存的管理与分配做的比较简单，随着新版本的发布，逐步有一些新的功能加进来（如 CPU Manager、Topology Manager 等），但 Kubernetes 缺省的 CPU Manager、Topology Manager 仍无法了解服务器级硬件的复杂内部架构和 CPU 本身的能力，这就可能会导致 CPU 的资源分配决策和计算性能无法达到最优。对于英特尔® 至强® 可扩展处理器来说，其架构复杂、功能强大，如果想要在上面部署 Kubernetes 集群来高效支撑云业务，就需要对其拓扑结构和 CPU 的强大功能暴露给 Kubernetes 集群，这时 CRI-RM 因此而生。

在英特尔研发团队的不懈努力下，如今英特尔® CRI-RM 助力下的 CPU 在 AI 场景中能够更显威力。CRI-RM 是英特尔初创的一个开源项目，其目的是通过在节点上的动态划分系统资源，配合 Kubernetes 调度器，实现在节点层面上的最优任务编排，把英特尔平台的特性完美的适配到 Kubernetes 的集群环境里。

浪潮在 AIStation V3 中应用了英特尔® CRI-RM 组件，该组件可以插在 Kubelet 和 CR 之间，截取来自 Kubelet CRI 协议的请求， 扮演 CR 的非透明代理，跟踪所有集群节点容器状态，能够更好 地将处理器、内存、IO 外设、内存控制器等资源分配给应用负载。在 Tensorflow 等测试用例中，这一优化被证明能够实现高达 57.76% 的性能提升。这意味着在未对硬件配置进行更新的前提下，CRI-RM 的应用会带来大幅度的性能提升，使得用户无需在进行硬件投入便能够获得可观的 AI 训练性能提升，从而提高基础设施的利用效率，并节约了总体拥有成本。

通过浪潮的实践，我们基本就能够看出，英特尔的软件开发和创新的起点就是充分利用硬件资源潜能来优化应用，加速应用负载使其在英特尔平台上以达到更好的开发和用户体验。又比如 QAT 加速卡，在云原生领域的各种网络传输模块中，它便有效提速了安全加解密（TLS）和压缩 / 解压缩的处理性能，从而帮助软件获得更好的性能。

二、企业当下需要的是“一站式”容器解决方案

用过 OpenStack 的人都知道，版本升级是 OpenStack 商业化应用的最大痛点。每年两次版本升级令企业真的有点吃不消，旧操作系统无法满足新版本的升级需求，用户轻易不敢进行升级。虽然说 OpenStack 将在 Zed 版本之后，从“A”开始重新命名，每年两次大版本升级改为每年一次大版本升级，但这依旧满足不了如今企业在数字化转型过程中上云的需求。

随着技术发生变革，用户需要的是一套能从产品端到服务端的一站式解决方案来满足需求。因为这些需求的存在，越来越多的团队会基于 Kubernetes 构建上层抽象，增加更多的扩展能力，以“应用”为中心构建高可扩展的云原生平台。

比如青云科技开源的 KubeSphere 项目，在 Kubernetes 之上构建的面向云原生应用的分布式操作系统，完全开源，支持多云与多集群管理，提供全栈的 IT 自动化运维能力，简化企业的 DevOps 工作流。它的架构可以非常方便地使第三方应用与云原生生态组件进行“即插即用”的集成。此外，KubeSphere 还开源了 KubeKey 帮助企业一键在公有云或数据中心快速搭建 Kubernetes 集群，提供单节点、多节点、集群插件安装，以及集群升级与运维。

基于对企业用户的需求洞察，青云科技在发展 KubeSphere 的社区的同时，还围绕 KubeSphere 这一核心产品开发了企业级容器平台—— KubeSphere 企业版。目前已经在金融、运营商、工业、教育、能源、交通物流、零售电商和政府等行业积累了大量成功经验。像中金苍穹容器平台、易方达基金 PaaS 平台、云天化集团容器云平台、中移金科容器云平台都是 KubeSphere 企业版的优秀实践。

为了真正帮助企业更好地落地云原生应用场景，青云科技广泛联合云原生生态体系各层面合作伙伴，打造开放共生的云原生生态圈。硬件层面的生态合作是其中重要的一部分，因为在当前的云原生生态环境下，云原生容器化平台上的软件应用效率和硬件技术之前的关系更加紧密，其运行更需要调动硬件的加速能力。于是拥有独特硬件黑科技优势的英特尔成为了青云科技的合作伙伴，为 KubeSphere 企业版提供了许多支持。

英特尔帮 KubeSphere 企业版实现了网络功能增强，通过开发并开源 Multus 的 CNI 插件、提供“将多个接口添加到 Pod”的功能，成功解决了因 Kubernetes 缺乏支持多个网络接口能力，而受制于单一网络解决方案的企业用户的需求。如今的 KubeSphere 企业版在优化后的 Intel Multus 解决方案的助力下，实现了更强大、更多元的网络管理和扩展能力，支持用户在创建应用负载时可以自定义选择多块网卡，同时支持网卡资源池管理。

图：应用负载选择多网卡

此外，为了检测 Kubernetes Cluster 中每个 Node 的特性能力，英特尔还开发了 NFD（Node Feature Discovery），而 KubeSphere 企业版深度集成了 NFD，使其节点管理得到增强。KubeSphere 企业版通过把节点更详细的 Label 发送到 KubeSphere 企业版 Master Scheduler 之上，应用负载获得了更精准的调度，使其更充分地利用硬件资源。

图：测试结果 -Node Feature Discovery 启动成功

另外值得一提的是，CPU Manager 给 KubeSphere 企业版带来的性能提升表现十分亮眼。当我们测试部署不同的 Redis pod 会发现，开启 CPU Manager 后的 Redis 的读写性能与开启前的读写性能相比，Redis 性能最高可以提升超过 9%。

图：Redis 性能测试图

三、容器好用，但也需要“注意安全”

虚拟化技术突破了操作系统与物理硬件的局限，在异构资源整合、集中管理、提高硬件利用率等方面具有很强的优势，但这同时也增加了发生系统安全问题的概率，虚拟化的安全直接影响着云原生架构的安全，间接影响着企业数字化转型成果及业务发展。

作为云原生虚拟化常用的技术，容器确实好用，但是容器安全问题也一直是行业内备受诟病的问题。传统的容器基于 NameSpace 和 Cgroup 进行隔离，在带来轻量简洁的同时，也带来了许多安全隐患。容器作为一种相对于虚拟机来说更加轻量的虚拟化技术，容器虽然能够提供一个与系统中其他进程资源相隔离的执行环境，但还是与宿主机系统共享内核的，很容易因为隔离性不足而产生安全隐患。尤其是在多租户的场景下，一旦容器里的应用逃逸到内核，后果将不堪设想。

据 Red Hat 公司调查数据显示：有 94% 的受访者在过去 12 个月内遭遇过 Kubernetes 安全事件。而 Akamai 日前也进行了一项实验，将一个简单的 Docker 容器蜜罐用于攻击测试，结果显示该容器在 24 小时内被攻击者用于四起不同的犯罪活动。这些数据都在告诉我们，解决企业容器安全问题刻不容缓。所以很多厂商在构建企业级容器管理平台时都会着重考虑容器安全问题，像我们刚刚提到的 KubeSphere 企业版，它的一大亮点就是“安全加固”。在英特尔容器解决方案加持下的 KubeSphere 企业版，深度集成了 Kata Containers，用户可以在创建符合自身业务需求的运行时，通过 KubeSphere 企业版的管理页面进行统一管理。

图：一键选择 Kata

Kata Containers 的核心亮点就是采用轻量级虚拟化作为容器的隔离，使得它兼具容器的速度和虚拟机的安全隔离，这一点解决了长期以来困扰容器发展的安全隔离性不足问题，大大促进了云原生的发展。

作为符合 OCI 标准的轻量级 VM，可无缝地与 Docker 及 Kubernetes 对接。Kata Containers 运行的应用负载具备独立内核，同时借助英特尔® VT 技术，具备其他轻量级 VM 所不具备的优异性能。它整合了英特尔的 Clear Containers 和 Hyper.sh 的 runV，在能够充分利用英特尔® 架构平台性能优势的同时，还支持其他架构的硬件。

Kata Containers 的隔离原理就是在请求创建容器实例时，首先启动一个轻量化虚拟机，然后将容器镜像挂载到虚拟机里，从而在这个虚拟机里启动和运行这个容器应用程序。其本质是一个虚拟机实例，但拉起虚拟机的过程和运行在虚拟机里这个事实对用户是透明的，这种方式并不改变用户使用容器的习惯。

Kata containers 可以被用在很多场景，目前云服务提供商 CSP 们的使用场景主要包括安全容器实例服务、容器运行时的业务隔离等。感兴趣的开发者可以参阅公开的应用案例集：https://katacontainers.io/use-cases/ 目前 Kata Containers 2.0 已经发布，社区正在酝酿 Kata Containers 3.0 的规划和开发，其主要开发方向将聚焦于优化性能、加强安全、提高可用性和稳定性方面。

另外，一个基于 Kata Containers 的典型用例也十分值得大家去了解——机密容器  （Confidential containers），它是一个基于硬件 TEE 的技术方案，目前是 CNCF 的沙箱项目。机密容器是机密计算（Confidential Computing）的一个具体实现，其主要目标是对数据在使用中的保护，随着云计算的大规模部署，机密计算旨在允许将云提供商从可信计算基础（TCB）中移除，以便只有硬件和受保护的应用程序本身在可信边界内，这使租户可以放心地、安全地把业务负载转移到公有云上去。

要知道，英特尔® SGX 一直是业内机密计算方案的主要推动者。英特尔® SGX 在内存空间中“开辟”出了一个可信的、受到严密保护的安全“飞地”，可通过严格的访问控制和加密操作去保障数据完整性、数据机密性和代码完整性，确保主机操作系统、BIOS 等高等级应用和底层基础系统都不能对其随意访问。即便应用、底层基础系统在恶意攻击中受损，“飞地”也可通过基于硬件的、增强型的安全防护来阻断攻击。

同时英特尔® SGX 的鉴权能力可在阻断攻击的同时证明自己的运行未被篡改。如果需要实现数据“可用不可见”，英特尔® SGX 也能以“飞地”机制为机密计算中的数据与代码提供安全岛。

“飞地”空间越大，其能承载和提供保护的应用程序和核心数据也就越多，于是英特尔对 SGX 技术进行了全面强化，在配置了面向单路和双路的第三代英特尔® 至强® 可扩展处理器的系统中，目前双路系统中最高可支持 1TB 容量的“飞地”空间，能够让用户在云上实现更大数据量的机密计算，轻松应对更多安全挑战。

四、写在最后

随着人工智能、大数据等创新技术席卷大多数行业和地域，疫情防护常态化暴露出来的企业“数字缺陷”加快了数字化转型速度。企业想要成功实现数字化转型，构建云原生技术架构，就一定要利用好容器技术。

在后 OpenStack 时代，云原生未来的发展趋势就是将管理基础设施（计算、网络、存储）的负担卸载给云服务提供商（公共云 / 私有云 / 边缘云），以便开发人员可以专注于应用程序的业务逻辑而不是基础设施，从而以更低的资本性支出和管理支出、更快地使应用上市。如果更具象一点，则是将大型复杂的单体应用程序分解为小的模块化执行单元，以便于修改程序或添加功能，更好地代码重用，更少地维护开销。

作为云原生发展的基石，容器技术将再次顺应云原生发展潮流，解决上述的这些需求。随着技术的演进，企业势必会越来越重视如何使容器技术更好地为业务带来价值这件事。那在这个过程中，势必会遇见各种各样的挑战，面对挑战，我们需要的做的就是迎难而上。

对正处在数字化转型关键期的企业来说，在降本增效的大目标下，应用英特尔等厂商提供的商用解决方案也是很不错的选择，不仅能够帮助企业降低人力成本，还能够大大地提高管理效率。

更多云原生技术干货，扫描下方海报二维码，观看英特尔联合国际学术期刊《科学》共同推出的“架构师成长计划”第四期《用架构思维为云原生做减法》精彩回放！