分析公司Gartner预测，到2023年，70%的组织将在生产中运行三个或更多容器化应用程序。容器、Kubernetes和微服务应用模式是企业IT创新和数字化转型的三大驱动力。很多公司已经采用这些技术，发挥其在应用程序开发和部署方面的优势。
在Gartner公司展望2023年的容器应用前景之时，以下是我们在最新的《容器现状以及Kubernetes安全》调查报告（文末附有报告下载方式）中发现的六大容器应用趋势。
1. 各组织正在率先对其应用进行容器化
这项调查的数据显示，应用的容器化出现大幅增长。自我们六个月前的上一次报告以来，将半数以上的应用程序容器化的组织比例从23%上升到29%，增长率为22%。与此同时，将不足10%的应用程序容器化的组织数量从32%下降到21%。
2. 各组织在生产环境的容器化应用比六个月前要多得多
各组织不仅仅是将更多应用程序容器化，而且还在生产中运行更多这些容器化应用。在过去6个月里，生产中运行半数以上容器的组织的百分比从22%上升到29%，增长率为32%。与此同时，运行不到10%的容器的组织的生产从39%下降到28%。
3. 在云部署方面，AWS继续占据主导地位，但第二名的竞争升温
不出所料，亚马逊网络服务（AWS）继续主导容器市场，但关于第二名的角逐争夺正在加剧。虽然微软Azure仍然位居第二，但谷歌云平台（GCP）第三位的地位从6个月前的28%增长到今天的35%。GCP如此紧密地与Azure竞争，也许并不意外，因为 Google是最早大规模在自己的产品使用容器的企业之一，创建了Borg（Kubernetes的前身）来管理容器，并开发，且最终在将其捐献给云原生计算基金会（CNCF）之前开源。此外，Google Kubernetes引擎（GKE）是市场上功能最丰富的托管型Kubernetes服务之一，尤其是在集群管理领域，这在很大程度上要归功于谷歌在大规模编排容器方面的深刻经验。
4. Azure用户的容器成熟度滞后于GCP和总体
Azure用户往往比在AWS或GCP上运行的组织更早开始采用容器。但只有20%的Azure用户已将其一半以上的应用程序容器化，这大大低于所有非Azure用户的33%。与之相对应的是，只有22%的Azure用户将超过一半的容器化应用部署在生产环境中，而所有非Azure用户的这一比例为34%。
与Azure用户不同，GCP用户在容器采用方面走在了前面。近三分之一（31%）GCP用户已实现将一半以上的应用程序容器化，略高于所有非GCP受访者的27%。同样，更多的GCP用户有超过一半的容器化应用程序部署在生产环境中，比例为31%，而非GCP用户只有29%。
5. 容器需要并促进DevOps和安全部门之间的更紧密协作
考虑到安全性仍是容器策略的首要关注点，解决容器安全性挑战的好消息是DevOps和安全团队已经更加紧密地合作了。考虑到容器和Kubernetes本身有助于统一曾经非常独立的基础设施和安全规程，这种趋势是有意义的。对于容器和容器协调器（如Kubernetes），控件是基础设施的一部分，使组织能够在实现“安全即代码"方面取得进展。
6. 组织越来越希望DevOps在保护容器化应用程序方面起带头作用
在所有运维角色中，DevOps被认为是最应该负责管理容器安全的一方，81%的受访者选择该角色，其次是安全部门，为51%。然而，当涉及到容器和Kubernetes安全，需举全村之力。我们看到负责安全的不同角色之间有相当多的重叠。例如，81%的受访者认为DevOps应该在管理容器安全方面起带头作用，又有近半数的受访者（48%）选择了安全部门（该问题允许多选）。下面的维恩图显示了容器安全责任在不同团队和角色之间的共享程度。因此，容器和Kubernetes安全工具必须促进不同团队之间的密切协作，从安全到DevOps再到Ops和开发人员，而不是让常常困扰组织的孤岛持续存在。
对容器和Kubernetes安全的影响
各个组织在生产环境中快速采用容器，并且经常在本地和公共云环境中（通常在多个云中）采用容器，因此，无论云原生资产在哪里，安全性都必须始终如一地应用运行。鉴于大多数组织都希望DevOps或DevSecOps团队运行容器安全平台，因此安全工具必须将安全性左移（即在开发过程中尽可能早地保证安全性），并在整个生命周期中无缝地保护容器，来帮助连接安全团队和DevOps团队。
原文链接：https://www.stackrox.com/post/2020/03/6-container-adoption-trends-of-2020/
扫描下方二维码关注公众号分布式实验室，回复『安全』获取调查报告。

				

摘要：无论公有云还是私有云厂商，都认识到了将虚拟化的隔离性和容器的高效运维特性相结合，是云原生平台发展的必然趋势。

容器是如何解决隔离问题的

众所周知，容器技术的出现有两个关键原因：

1.  软件运行过程中的资源和环境的隔离。

2.  软件因为运行环境多样带来的打包和配置的复杂性。

而对于软件运行环境的隔离需求，从计算机出现之初就已经开始了，多任务分时操作系统和虚拟地址的引入，都是为了解决多个任务在同一主机上运行，并且让任务本身认为自己独占机器。当然这样的隔离是远远不够的，当今软件，根据不同的层级，可以将隔离技术分为以下三类：

1.  进程级别的隔离

2.  操作系统级别的隔离

3.  虚拟化级别的隔离

操作系统以进程作为程序运行过程的抽象，进程拥有独立的地址空间，进程的执行依靠操作系统的调度。但是进程共享了文件系统，函数库等资源，程序之间出现互相干扰的可能性很大。这个层级的隔离适合在相同主机上运行单个用户的不同程序，由用户自己保证程序之间的资源分配。

上世纪70年代出现了chroot，进行文件系统的隔离，21世纪初开始，随着计算硬件的性能提升，软件隔离的需求更加强烈，这时候开始出现如jail，cgroup，namespace等各种不同资源的隔离技术。我们将这些技术统一划分到操作系统的隔离技术，这类隔离技术可以实现软件在诸如硬件资源、文件系统、网络、进程号等方面的隔离，但是不同的应用依然是运行在相同的操作系统内核上，对于恶意的利用漏洞攻击的场景，这种隔离技术依然会捉襟见肘。但是这种级别的隔离带来的额外资源消耗较小，适合相同的组织内不同用户的应用在相同主机上运行。

虚拟化技术的出现，让相同的物理机上也能运行多个不同的操作系统。操作系统对硬件的接口，由虚拟机管理程序(VMM)负责模拟。运行在不同系统中的程序，内核也是隔离的。硬件资源则通过各种硬件辅助手段进行划分，虚拟机上的程序很难突破虚拟化层加上的资源限制。并且因为内核的隔离，资源的可见性也做到了很强的隔离性。即使是恶意的用户，也很难突破这层虚拟化的限制，已达到攻击物理机，或者相同主机上其他虚拟机的目的。

以上三种隔离是按照层级一步一步加强的，同时带来的理论损耗也是逐步递进的。虚拟化由于需要模拟各种设备，带来的资源损耗比其他两种隔离方式要大很多。



 

什么是“安全容器”

容器概念出来的时候，最初大家做隔离的思路，几乎都是操作系统级的隔离，也就是基于内核提供的namespace、cgroup、seccomp等机制，实现容器内的资源、文件、系统调用等限制和隔离。这种隔离方式更加高效，损耗更小。但是随着容器的大规模使用，尤其是各种容器编排系统，如k8s的深入使用，人们逐渐发现这样的隔离级别往往不能满足要求。在公有云场景下，相同主机如果需要运行不同租户的应用，因为这种隔离级别依然采用了共内核的机制，存在这广泛的攻击面，容器的隔离级别完全不能满足要求。所以最初的公有云上的容器服务，都是配合虚拟机的使用来完成的，首先是用户需要创建一批虚拟机作为运行容器的节点，形成一个私有的集群，然后才能在其上创建容器应用。虚拟化级别的隔离已经被各种公有云的实践证明，是一种安全的隔离技术。



自从云计算的概念提出开始，虚拟机一直是云平台的基础，无论是平台本身服务还是用户的使用，都是从IaaS平台创建通用虚拟机开始的。一般都是创建相应的规格的虚拟机，使用一个完成操作系统镜像启动一个完整的操作系统，随后在其安装，配置，运行软件和服务。包括我们上节提到的公有云容器服务的提供形式也是如此。

虚拟化本身带来的隔离能力是受到普遍认可的，不过IaaS层希望提供的是一个和应用完全无关的基础设施层，它几乎完全不感知应用的任何信息。于是从基础设施到应用运维，中间巨大的鸿沟则是由PaaS和用户自己来填平，这中间依然需要耗费无数的人力和成本。通用的虚拟机服务诚然有它的好处，比如完整的操作系统很适合程序调试，或者作为工作办公环境等等。但是对于多数运行于云平台的软件，它需要的是它独有的运行环境，它的运行环境由它的镜像已经完全定义好了。如果在此之外，又启动一个完整的操作系统，既浪费资源，也增加了运维的成本。为什么不能直接将虚拟化级别的隔离引入到容器技术中呢？结合虚拟化的安全性和容器在软件生命周期管理方面的优势，是不是可以给软件开发运维带来巨大的便利呢？

也就是在这个时间，docker和coreos等一起成立了OCI组织，其目的是将容器的运行时和镜像管理等流程标准化。OCI标准定义了一套容器运行时的命令行接口和文件规范，docker将其RunC捐给OCI作为运行时标准的一个参考实现。2015年Hyper.sh开源了RunV，则是一种基于虚拟化的容器运行时接口的实现，它很好地结合了虚拟化的安全性和容器的便利性。后来RunV和ClearContainer合并成立了kata项目，kata提供了更加完整的基于虚拟化的容器实现。我们把这种基于虚拟化的容器实现称作安全容器。

除kata之外，还相继出现了多个安全容器的实现方式，比如google的gVisor、AWS的firecracker-containerd、IBM的Nabla、VMware的CRX等等，其原理不尽相同，但共同反应了一个趋势，就是将容器的便利和虚拟化的安全隔离结合起来，让虚拟化直接和应用运维结合，成为云原生技术的大势所趋。下面对这些“安全容器”的实现技术进行简要的介绍和对比。

Google gVisor

相比于其他几种实现，gVisor的显著不同之处在于，它通过拦截容器中应用的系统调用，模拟了一个操作系统内核，因此gVisor实际上没有虚拟化，而是在用户态实现了一个操作系统。这种方式可以降低因为虚拟化带来的模拟设备内存损耗。gVisor提供的runsc符合OCI标准，可以直接对接docker、containerd等容器平台，同时它也完全兼容docker的镜像格式。但是由于不是一个标准linux内核，因为应用的兼容性有较大问题。另外拦截系统调用带来的巨大的性能损耗也是阻止其广泛使用的一个阻碍。

 

图片来自https://gvisor.dev/docs/

 

IBM nabla

nabla是继承于unikernel的隔离方式，应用采用rumprun打包成一个unikernel镜像，直接运行在一个专为运行unikernel定制虚拟机(ukvm)中。应用直接打包首先可以降低很多内核态和用户态转换的开销，另外通过ukvm暴露非常有限的主机上的syscall(只剩7个)，可以大大缩小主机的攻击面。它是这些安全容器实现中，最安全的。不过由于它要求应用打包成unikernel镜像，因此和当前docker的镜像标准是不兼容的。另外，unikernel应用在诸如支持创建子进程等一些常规操作上都有很难解决的问题。

 

图片来自https://unit42.paloaltonetworks.com/making-containers-more-isolated-an-overview-of-sandboxed-container-technologies/

 

 AWS Firecracker

最初firecracker是为AWS的Lambda打造的高密度轻量级虚拟化组件。由于它是从头开始构建虚拟化，带着轻量化的目的，因此他抛掉了qemu这种通用虚拟化组件的大部分功能，只留下运行容器和Function必要的一些模拟设备。因此它的内存开销非常小（小于5M），启动速度非常快（小于125ms），一秒钟可以在一个节点上运行150个轻量级虚拟机。

为了让firecracker-microvm更好的运行容器，AWS启动了firecracker-containerd项目，firecracker-containerd是containerd-shim-v2的一个实现，不符合OCI标准，但是可以直接对接containerd启动容器，也就很容易通过containerd对接k8s的CRI接口。containerd-shim-v2是containerd定义的新的runtime接口，它是对最初shim-v1的一个简化，可以大大精简runtime的组件和内存使用。containerd是一个全插件化的代码框架，扩展性非常好。firecracker-containerd在该框架下，实现了一个snapshotter作为镜像插件，负责块设备镜像的生成；实现了一个shim-v2的runtime，负责容器的生命周期管理。另外还有个fc-control-plugin作为虚拟机的管理插件，提供grpc接口供runtime调用。在轻量级虚拟机内部，有一个agent负责监听runtime传进来的vsock，接收runtime的指令进行虚机内部真正的容器生命周期管理操作，它是直接调用runc来管理容器的。

 

图片来自https://github.com/firecracker-microvm/firecracker-containerd/blob/master/docs/architecture.md

 

VMware CRX

VMware发布的vSphere 7与kubernetes进行了融合，它利用k8s的CRD将其集群的虚拟机、容器、函数等运行实体管理的所有功能都集成到了k8s中。VMware是一个做虚拟化起家的公司，因此虚拟化作为它的老本行，这块的积累是很深厚的。它将虚拟化融合到它的容器runtime CRX中，因此和firecracker-containerd和kata类似，也是一个基于轻量级虚拟化的容器runtime的实现。通过对其虚拟化组件和guest内核的精简，CRX 容器同样做到了很低的内存损耗(20MB)、快速(100ms)的启动以及高密度部署(单个节点大于1000个pod)。

 

图片来自https://cormachogan.com/2019/11/22/project-pacific-vmworld-2019-deep-dive-updates/

vSphere对node上的kubelet组件改造比较大，节点上的Spherelet部分功能和kubelet重合，负责pod的生命周期管理（他们称之为Native Pod），运行在虚拟机中的SphereletAgent则集成了符合OCI接口规范的libcontainer，实现容器的生命周期管理，以及容器的监控日志采集、容器的shell登录(kubectl exec)。Spherelet和虚机中的SphereletAgent交互实现类似于kubelet使用CRI接口管理pod的效果。

 

kata containers

相比于以上几种，kata containers 最大的特点是它专注于实现一个开放的符合OCI标准的安全容器runtime实现，对于对接什么样的虚拟化方案，它抽象了一套hypervisor接口，如今已经对接了多种虚拟化实现，比如qemu、nemu、firecracker、cloud-hypervisor等等。

 

图片来自https://katacontainers.io/

 

通过containerd-shim-v2和vsock技术，kata精简了大量的组件，配合轻量级hypervisor和精简内核，kata可以做到将额外内存消耗降低到10MB以下。容器启动时间降低到100ms以下。后续还会通过rust语言重写等方式，提供更低内存额外消耗。



图片来自https://github.com/kata-containers/documentation/blob/master/design/architecture.md

 现有安全容器技术对比


			
 
			
			

			
实现方式
			
			

			
安全隔离
			
			

			
性能/轻量化
			
			

			
兼容性
			
		

			
Google gVisor
			
			

			
用户态内核
			
			

			
拦截系统调用
			
			

			
IO、网络性能差
			
			

			
OS兼容性差
			
		

			
IBM nabla
			
			

			
Unikernel
			
			

			
裁剪系统调用+虚拟化
			
			

			
暂无数据
			
			

			
和现有镜像不兼容
			
		

			
AWS Firecracker
			
			

			
轻量级虚拟化
			
			

			
虚拟化
			
			

			
高
			
			

			
仅对接firecracker-microvm虚拟化
			
		

			
VMware CRX
			
			

			
轻量级虚拟化
			
			

			
虚拟化
			
			

			
高
			
			

			
仅对接VMware的ESXi
			
		

			
kata-containers
			
			

			
轻量级虚拟化
			
			

			
虚拟化
			
			

			
高
			
			

			
适配多种轻量级虚拟化技术
			
		
 

安全容器技术发展趋势

随着Serverless等技术的兴起，应用部署和运维工作已经下沉到云平台上，人们需要一个更加高效的云原生技术平台。从这几年涌现的安全容器实现技术可以观察到，无论公有云还是私有云厂商，都认识到了将虚拟化的隔离性和容器的高效运维特性相结合，是云原生平台发展的必然趋势。结合当前安全容器实现中遇到的一些问题，我们可以预见到，未来这项技术发展的几个走向：

1. 需要一个为安全容器而生的轻量级hypervisor，当前qemu+kvm是主流的虚拟化技术，但因为qemu是为通用的虚拟机而设计的，其体量过于庞大，而对于安全容器而言，一个模块化可定制的虚拟化实现尤为重要。如果结合gVisor和nabla的实现来看，内核的可定制性也是安全容器场景的必然要求。rust-vmm即是这样一种模块化的虚拟化组件库。linux内核本身的模块化特性可以部分满足容器场景下的内核定制需求，不过也许像gVisor那样实现一个专为容器而生的内核也许是未来的趋势。

2. 容器的启动时间是衡量一个云原生平台效率的重要指标，尤其是在Serverless场景下，程序运行时间本身可能很短，这时候启动时间可能占用了其绝大部分，那么这种低效就显得尤为明显。安全容器通过极致的轻量化，可以将容器启动时间降低到100ms以下，但是容器镜像拉取时间过长仍是当前容器部署过程中的一个短板。由于当前容器镜像格式和镜像挂载方式等方面的限制，需要在启动容器之前将容器镜像拉取到本地以后，才能启动容器。而容器启动本身需要的数据只占镜像的6%左右。因此我们亟需一个高效的镜像挂载方式，当前已经有一些免下载和懒加载（Lazy-Loading）的技术原型，后续需要尽快推出一个可商用的镜像下载加速方案。

3. 当前公有云的网络普遍采用原IaaS的网络管理模式，在地址分配，网络配置效率等方面完全赶不上容器快速启停的需求，docker容器采用的veth方式在性能等方面也很难满足高效转发的要求。因此需要一个专为云原生设计的网络管理方案。

4. 我们看到云平台对应用的管理逐步深入，从只管理基础设施的IaaS层，发展到管理应用整体部署和运维的PaaS，再到如今服务网格（Service Mesh）技术将平台管理能力深入到应用内部的微服务级别。同时我们也看到，以K8s容器、Istio服务网格为代表的云原生技术已经和下层的计算/网络虚拟化等技术逐步整合到了一起，比如安全容器即是容器与计算虚拟化的结合，而Istio服务网格也会与虚拟化网络进行深度整合以提供更高的性能与更精细的QoS控制。

5. 当前硬件加速技术在AI和大数据等领域大行其道，安全容器需要与各种计算加速硬件技术进行结合，使得AI、大数据、科学计算等批量计算领域的用户可以利用云平台直接投递其海量的计算任务，可大大降低他们在底层技术上的心智负担。通过硬件加速也是提升云平台本身效率、降低云平台运行成本的有效手段。比如华为云擎天架构在硬件加速方面拥有的技术优势在“安全容器”领域已得到充分的证明，CCE Turbo裸金属容器已经实现了安全容器的部分硬件卸载能力。

总结

未来必然是云原生技术大行其道的时代，我们已经看到很多传统行业也逐渐认识到云原生技术可以给传统企业的IT软件，工业自动化，线上运维和数据管理等带来明显的效率提升。我们将看到通过对底层硬件和上层服务的全栈整合，打造出一个高效智能的云计算技术平台，而这中间，容器将是串联整个技术栈的关键所在。

 

点击这里，了解更多精彩内容

【编者的话】本次将分享的容器化ICT融合平台是一种面向未来ICT系统的新型云计算PaaS平台，它基于容器这一轻量级的虚拟化技术以及自动化的“微服务”管理架构，能够有效支撑应用快速上线和自动扩缩容，最大化IT基础设施资源利用率并降低总体拥有成本（TCO）。未来的网络正在向IT化、云化方向发展，容器与微服务技术，完美契合“网络即服务”、网络切片等发展理念，将有助于实现更加灵活、智能、高效和开放的5G新型网络。



2015年，NFV和容器无疑都是最热门的技术，被很多业内人士认为是未来的发展趋势；2016年，当NFV遇上容器，会碰撞出什么新的火花？当容器化的CT/IT业务在同一平台内融合部署，又会产生怎样新的体验？下面和大家分享一下，从2015年到2016年，我们做的容器化CT-IT融合方面的工作。IT我就不解释了，CT这里主要指的是电信业务。


容器化CT-IT融合系统是一种面向未来ICT系统的新型云计算PaaS平台，它基于容器这一轻量级的虚拟化技术以及自动化的微服务管理架构，能够有效支撑应用快速上线和自动扩缩容，最大化IT基础设施资源利用率并降低总体TCO。未来的网络正在向IT化、云化方向发展，容器与微服务技术，完美契合“网络即服务”、网络切片等发展理念，将有助于实现更加灵活、智能、高效和开放的5G新型网络。


下面是从2015年到2016年，我们做的容器化CT-IT融合方面的工作：
2015年，我们首次提出容器化ICT融合方案
2016年初，我们完成容器化ICT融合原型系统
2016年4月8日~4月9日，中国移动召开2016年度技术工作会，容器化ICT融合原型系统首次亮相技术工作会精品展。
2016年6月20日~6月23日，OPNFV Summit在德国柏林召开。在OPNFV PoC战区，中国移动和红帽公司联合展示了容器化ICT融合平台
2016年6月29日，由GSMA主办的2016世界移动大会-上海（Mobile World Congress，简称MWC）在上海新国际博览中心盛大开幕，在中国移动研究院5G展区，我们为参会专家演示了容器化ICT融合原型系统。


最初产生将网元容器化的想法来源于2015年，我们正在进行NFV IMS测试，同时也正在进行容器和DCOS的相关技术研究和验证性工作，关于应用场景，最适合容器化的应用无疑是所谓的云原生应用，或者说是微服务，其主要特点是分布式、无单点失效、无状态，这和我们测试的某些厂商的IMS网元的特征竟然如此地一致，而容器的轻量级、高性能、快速启动等优势，也恰好是网元所需要的，几分钟部署一套核心网元或许真的会从梦想变成现实。于是，一对新的组合诞生了，NFV Container=NFC。


理论+实践才能创造出真理，在理论分析的基础上，可行性验证必不可少，而惊喜总是无处不在，尝试创新的道路也不是总那么孤独，开源的IMS项目Clearwater也在做和我们类似的工作。Clearwater是IMS网元的一个开源实现，其主要目标是开发一套适合在云上（如aws）部署的IMS网元，提供语音、视频、消息服务。Clearwater在架构上就以微服务的方式设计各个组件，并且提供了docker格式的容器镜像，我们将它移植到Kubernetes平台上，平台具有负载均衡、容灾恢复、支持资源监控等特点使其更适合服务化
测试环境
硬件
Red Hat 3D打印演示系统，内含3台服务器。


软件
操作系统：Red Hat Enterprise Linux Server release 7.2 (Maipo)
容器引擎：docker-1.8.2-10.el7.x86_64
容器编排：kubenetesv1.1.0-origin-1107-g4c8e6f4



Clearwater架构
Clearwater架构主要分为六大组件，Bono、Ralf、Sprout、Homer、Homestead、Ellis，如下图所示，其中Sprout作为SIP Router，是核心业务处理模块，也是业务量增加时，需要做动态扩容的主要部分。


NFC测试方案
针对Clearwater中每个组件，定义一个Kubernetes Service，每个服务中包含一个或多个POD，可以通过增加POD个数进行横向扩展。


Kubernetes中服务列表如下图所示：



Kubernetes中POD列表如下图所示。测试过程中，通过基于SIPP的clearwater组件增加并发用户量，系统压力增加，触发sprout服务中POD个数增加。



为实现POD的动态扩展，一方面，利用Kubernetes本身的replication controllers，根据负载增加或减少POD副本数量，另一方面，clearwater sprout是微服务架构，分布式，无状态，数据和应用分离，可通过集群配置，让集群中各个容器共享数据库。


在并发用户数为300个时，sprout模块POD数量一般为2~3个，在并发用户数增加到2000个时，sprout模块POD数量达到11个，如果继续增加并发用户数到3000个，sprout模块POD数量达到15个左右。
CT-IT融合测试方案
在大数据应用中，容器的轻量级、高性能、快速启动等特点同样具有优势，而CT和IT业务融合部署，也是未来发展的一个趋势，在本次测试中，我们在同一个容器平台上，部署了IMS网元和大数据应用。


在CT应用负载比较低的时候，系统主要用于进行大数据应用计算，大数据应用所占系统CPU资源比例较高。如下图资源监控界面所示。



当CT业务量增加，系统负载增大，为满足在线CT业务要求，增加CT业务容器数量，同时减少大数据离线业务占用资源。资源使用情况变化如下图所示。


总结
容器作为轻量级的虚拟化技术，可以降低系统开销，提升系统性能。
CT/IT融合部署：CT和IT应用在同一平台内混合部署，共享资源，提高资源利用率。
统一资源调度：打破应用竖井，统一建设，统一运维，降低TCO
系统性能提升：采用容器技术，轻量级的虚拟化，降低系统开销
微服务架构：分布式、无状态的云原生应用，实现应用于数据的分离
弹性伸缩、自动扩容：支持自定义的资源调度策略，实现根据业务量变化的资源动态调度。

Q&A
Q：网络转发有没有遇到瓶颈？有没有尝试一些加速技术，比如DPDK？
A：因为是控制面网元，目前没有遇到瓶颈，没有用DPDK，我们之前测试过虚拟机的，因为网元特点，也是没有配置DPDK，目前的测试上看，性能上没有问题。
Q：现在数据库也放在容器中吗？
A：是的，但是也是数据库集群，我们正在做将数据库分离的工作。
Q：你们实测的容器运行于虚拟机环境，性能如何，你们容器网络如何实现NFV互联？
A：容器没有基于虚拟机环境，因为是控制面网元，性能没有遇到瓶颈。
Q：容器不会包打天下，与虚机，物理机并存可能是一段时间内的一种常态，我们有没有分析哪些业务适合容器化，哪些业务不宜改变？并且在利用Kubernetes作为容器的编排调度工具时，如何实现容器与虚机应用的互通？
A：其实业务不宜改变不仅仅是技术问题，也和业务厂商是否愿意改变有关，毕竟一些遗留的业务已经在现网运行很久了，很难短期内容器化。另外，我们确实碰到了需要内核优化的业务。我们系统中还没有做容器和虚拟机应用互通。
Q：传统CT网络不仅仅是IMS吧，对于CS、PS，SDN/NFV化，你们有什么思路吗？
A：IMS使我们容器化的第一个尝试，其他的网元也正在研究中，后续也会做相关的测试，如果有兴趣，也欢迎参加我们后面的测试。
Q：你们的资源池，有路由器，安全组，负载均衡之类的功能嘛？路由器，负载均衡器可以被分配公网IP吗？
A：指的是容器的资源池还是我们已有的私有云资源池，已有的私有云资源池是有的，但是容器这个原型系统还没有。
Q：类似Clearwater的开源项目还有哪些？
A：NFV方面的吗，如果是IMS，Clearwater业界用的比较多，NFV其他网元开源项目很多。
Q：你们的虚拟机底层使用什么虚拟化技术支撑？
A：这次演示，底层用的就是Docker，我们的私有云资源池有VMware、KVM也有Xen。
以上内容根据2016年8月16日晚微信群分享内容整理。分享人马轶慧，中国移动通信有限公司研究院私有云项目经理，之前曾任VMware研发中心研发工程师。一直关注并致力于虚拟化、容器、云计算等相关领域。

2017已至，今年的容器圈将会如何发展？编排、基础架构服务和集群都会有怎样的发展趋势？文中观点，欢迎讨论。



容器编排框架的快速采用

随着越来越多的公司开始在生产环境中使用容器，编排框架（Kubernetes、Mesoscale、Cattle和Docker Swarm）的采用量将会大大增加。这些项目在稳定性、社区和合作伙伴生态系统方面发展迅速，对于未来企业更广泛地将容器应用于生产环境，这些项目将成为必要的、有利的技术。



容器基础架构服务的更大创新

尽管目前市场上已有一套强大的容器存储和网络解决方案，但在明年将出现更多的相关产品，来支持生产环境中的容器的工作负载的增长和规模，特别是随着Kubernetes使用的CNI的规格的继续成熟。 StorageOS、Portworx和Quobyte等公司的产品将会被更多地采用。



基础架构集群将以代码形式大量涌现

为了强化“一次编写，随处运行”的能力，编排集群将越来越多地从蓝图变得模板化和实例化，就像将容器化应用程序以Docker Compose文件的形式被部署一样。用户将自行定义他们需要的Kubernetes、Swarm或Mesos部署配置，以及他们需要的任何基础架构服务，然后将其部署到任何他们选择的云或虚拟化基础架构上。用户已经要求这个功能一年多了，最新版本的Rancher采取措施实现这一愿景，使用户能够以模块化、可定制的模板的形式，搭建完整的、container-ready的环境。



Docker将加速ARM服务器的采用

我们可能离真正的“ARM Server之年”有点距离，但容器肯定会加快在数据中心采用ARM的速度。容器在ARM服务器上运行的方式与在英特尔服务器上的运行方式相同，但具有大幅降低成本的潜力。像Packet这样的托管公司现在可以按小时增量提供ARM服务器；在某些特定情况之下，容器和像RancherOS这样的轻量级Linux分发版可以利用这些托管解决方案，让ARM服务器成为工作负载的值得考虑的选项之一。

原文来源：Rancher Labs