进入21世纪后，虚拟机技术进入相对成熟阶段，由于虚拟机的“笨重”，开发者们开始追求一种更加轻便的虚拟化技术。年，由NASA和Rackspace联合开发的开源平台OpenStack诞生，帮助服务商和企业实现云基础架构服务。它将开源、开放的思想带到了云原生领域，并为云原生发展掀开了新篇章。
年，OpenStack基金会更名为开放基础设施基金会OIF，OpenStack从“云”拓展到了“开放基础设施”。
紧接着，OpenStack从最初的虚拟化管理Nova和对象存储Swift，逐渐发展到包含虚拟化管理、SDN、SDS服务编排和容器管理等功能覆盖全面的开源项目集合。同时紧跟云原生技术演进潮流，与容器、Kubernetes、AI相关的更多开源技术紧密合作。年11月，OIF基金会宣布了开放基础设施的新标准LOKI——Linux、OpenStack、Kubernetes等组成的开放基础设施管理软件。
在今年4月，OIF发布了OpenStackYoga版本，并宣布，待下一个被称为终结者的Zed版本发布之后，OpenStack将以稳定的状态成为企业IT的生产级工具。这意味着云原生逐渐进入后OpenStack时代，年起，各大云厂商都陆续开始包装和提供容器的商业化服务，提供基于Kubernetes的商业服务产品，容器技术逐渐走向成熟和标准化、商业化，成为虚拟化的新代表产品，围绕容器发展的云原生逐渐走向普适的阶段，已经应用容器的企业正在进行着云原生的新一轮技术演进。
一、后OpenStack时代的Kubernetes:从“解决难用”到“用的好”
数字化转型的加速增加了企业对于云原生的需求，容器技术覆盖率提高，IDC预测，容器软件市场在近几年呈爆发式增长，并且未来五年仍然会保持超过40%的复合增长率。
进而，企业对容器管理的需求会直线提升，容器管理成为企业数字化转型的主战场。据Gartner预测，到年，成熟经济体中85%的大型企业将更多地使用容器管理。
如今在大多企业的业务场景中，企业组织需要确保多个容器可同时协同工作，这方面的工作大部分都是又编排引擎完成。随着Kubernetes的兴起与演进，目前已经克服了容器编排过程中许多技术挑战。
或许因为Kubernetes想要解决的问题太多，所以导致其复杂度很高，于是不少企业也在应用其他容器管理解决方案。然而市场数据证明，Kubernetes依旧是大多企业的选择。CNCF最近的一份报告显示，Kubernetes在全球已拥有近万个企业用户，成为云上应用程序主要的部署模式。
尽管Kubernetes覆盖率高，但这也并不意味着已经在应用它的用户满意，常被吐槽“难用但还很需要”。在Kubernetes的实际使用过程中，经常会遇见一些“难用”问题，比如创建容器时间过长、低吞吐量/RPS/突发并发、容器扩展速度慢、集群扩展速度慢、Sidecar资源开销、资源利用率低等，为此，英特尔提出了创新的“SW+HW功能解析”解决方案，开发工作主要集中在资源编排(Orchestration)和可观测行(Observability)两方面：
●基于快照+热代码块来创建容器;
●分片式多调度器;
●弹性POD的自动扩展;
●基于遥测的快速预测，用于实时扩展的决策;
●动态插入/删除POD中的Sidecar容器;
●链接设备的亲和调度/分配(NUMA,GPU+SmartNIC等);
●实时“节点资源变化”反馈给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和内存的管理与分配做的比较简单，随着新版本的发布，逐步有一些新的功能加进来(如CPUManager、TopologyManager等)，但Kubernetes缺省的CPUManager、TopologyManager仍无法了解服务器级硬件的复杂内部架构和CPU本身的能力，这就可能会导致CPU的资源分配决策和计算性能无法达到最优。对于英特尔至强可扩展处理器来说，其架构复杂、功能强大，如果想要在上面部署Kubernetes集群来高效支撑云业务，就需要对其拓扑结构和CPU的强大功能暴露给Kubernetes集群，这时英特尔CRI-RM因此而生。
在英特尔研发团队的不懈努力下，如今英特尔CRI-RM助力下的CPU在AI场景中能够更显威力。英特尔CRI-RM是英特尔初创的一个开源项目，其目的是通过在节点上的动态划分系统资源，配合Kubernetes调度器，实现在节点层面上的最优任务编排，把英特尔平台的特性完美的适配到Kubernetes的集群环境里。
浪潮在AIStationV3中应用了英特尔CRI-RM组件，该组件可以插在Kubelet和CR之间，截取来自KubeletCRI协议的请求，扮演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企业版在优化后的IntelMultus解决方案的助力下，实现了更强大、更多元的网络管理和扩展能力，支持用户在创建应用负载时可以自定义选择多块网卡，同时支持网卡资源池管理。
图：应用负载选择多网卡
此外，为了检测KubernetesCluster中每个Node的特性能力，英特尔还开发了NFD(NodeFeatureDiscovery)，而KubeSphere企业版深度集成了NFD，使其节点管理得到增强。KubeSphere企业版通过把节点更详细的Label发送到KubeSphere企业版MasterScheduler之上，应用负载获得了更精准的调度，使其更充分地利用硬件资源。
图：测试结果-NodeFeatureDiscovery启动成功
另外值得一提的是，CPUManager给KubeSphere企业版带来的性能提升表现十分亮眼。当我们测试部署不同的Redispod会发现，开启CPUManager后的Redis的读写性能与开启前的读写性能相比，Redis性能最高可以提升超过9%。
图：Redis性能测试图
三、容器好用，但也需要“注意安全”
虚拟化技术突破了操作系统与物理硬件的局限，在异构资源整合、集中管理、提高硬件利用率等方面具有很强的优势，但这同时也增加了发生系统安全问题的概率，虚拟化的安全直接影响着云原生架构的安全，间接影响着企业数字化转型成果及业务发展。
作为云原生虚拟化常用的技术，容器确实好用，但是容器安全问题也一直是行业内备受诟病的问题。传统的容器基于NameSpace和Cgroup进行隔离，在带来轻量简洁的同时，也带来了许多安全隐患。容器作为一种相对于虚拟机来说更加轻量的虚拟化技术，容器虽然能够提供一个与系统中其他进程资源相隔离的执行环境，但还是与宿主机系统共享内核的，很容易因为隔离性不足而产生安全隐患。尤其是在多租户的场景下，一旦容器里的应用逃逸到内核，后果将不堪设想。
据RedHat公司调查数据显示：有94%的受访者在过去12个月内遭遇过Kubernetes安全事件。而Akamai日前也进行了一项实验，将一个简单的Docker容器蜜罐用于攻击测试，结果显示该容器在24小时内被攻击者用于四起不同的犯罪活动。这些数据都在告诉我们，解决企业容器安全问题刻不容缓。
所以很多厂商在构建企业级容器管理平台时都会着重考虑容器安全问题，像我们刚刚提到的KubeSphere企业版，它的一大亮点就是“安全加固”。在英特尔容器解决方案加持下的KubeSphere企业版，深度集成了KataContainers，用户可以在创建符合自身业务需求的运行时，通过KubeSphere企业版的管理页面进行统一管理。
图：一键选择Kata
KataContainers的核心亮点就是采用轻量级虚拟化作为容器的隔离，使得它兼具容器的速度和虚拟机的安全隔离，这一点解决了长期以来困扰容器发展的安全隔离性不足问题，大大促进了云原生的发展。
作为符合OCI标准的轻量级VM，可无缝地与Docker及Kubernetes对接。KataContainers运行的应用负载具备独立内核，同时借助英特尔VT技术，具备其他轻量级VM所不具备的优异性能。它整合了英特尔的ClearContainers和Hyper.sh的runV，在能够充分利用英特尔架构平台性能优势的同时，还支持其他架构的硬件。
KataContainers的隔离原理就是在请求创建容器实例时，首先启动一个轻量化虚拟机，然后将容器镜像挂载到虚拟机里，从而在这个虚拟机里启动和运行这个容器应用程序。其本质是一个虚拟机实例，但拉起虚拟机的过程和运行在虚拟机里这个事实对用户是透明的，这种方式并不改变用户使用容器的习惯。
Katacontainers可以被用在很多场景，目前云服务提供商CSP们的使用场景主要包括安全容器实例服务、容器运行时的业务隔离等。感兴趣的开发者可以参阅公开的应用案例集：