在目前的云计算模型里，IaaS层接管硬件，在上面提供数据库、缓存、大数据等PaaS的应用，也提供了对象存储等SaaS类的服务。应用除了业务逻辑，还要有监控、日志处理、部署和交付、自动化运维、高可用、链路追踪等等，但是它们和业务逻辑没有太大关系。

　　所有应用能否都由云平台支撑?很难。因为每个应用程序的监控、日志、部署、架构需要的性能都不一样，当这些都能统一的时候，才能由云来支撑。而容器正是为此而来。

　　就如它的名字一样，容器像集装箱似的能够装载所有应用，不管是重量级的应用还是轻量级的应用。容器把应用容器化、版本化以及标准化，从而彻底地改变了软件构建方式和交互方式。对于广大开发者而言，容器大大简化了管理和部署应用程序的任务。

　　接踵而来的并不是开发者的拍手联欢，而是衍生了新的问题。在网络层，因为容器本身要做一层虚拟网络，IaaS本身提供了虚拟网络，这两层虚拟网络应该如何交互?存储也一样，IaaS本身提供了云硬盘，容器也需要，两者如何结合?备份和容灾机制如何结合等等。

　　那么下一代云该是什么样?

　　青云QingCloud容器平台负责人谈到，开发者希望开发出来的应用程序在本地和线上是一样的方式部署和运行，这样应用迁移的成本、开发成本、测试成本都会降低;软件服务提供商则提供了云上的软件服务，他们希望服务能否在其他云上以同样的方式进行部署和提供，关注的是跨云的环境是否是一致的;企业用户更关心的是本地机房环境和云上的环境能否保持一致，无论是私有云迁到公有云，或是做混合云，应用迁移和转换都非常方便。

　　而从标准的角度来看，开发者希望云是面向API的标准，这样所有都可以按照自动化的方式，提供足够的API，就能把所有事情自动化;软件服务商希望标准能屏蔽后面的细节，跟各种发行商没有任何关系;企业用户则希望避免厂商锁定。

　　所以下一代云应该是：云上的容器编排引擎和本地的容器编排引擎是一致的，API也是一致的，在其他的云上的API也是一致的。而本质上变成了容器编排引擎的调度器，下面接管了硬件资源，上面提供各种XaaS。

　　至于谁会成为容器编排引擎的标准，青云QingCloud容器平台负责人认为应该满足这几点：一是开源。闭源的编排引擎很难得到用户以及大多数厂商的支持;二是对商业化要友好，仅是开源肯定不够，还需要有很多商业支持、推广，才能落地到众多环境里面; 三是社区与厂商的支持;四是 API 跟应用规范的标准化程度，专注于标准，才能真正地为用户屏蔽技术细节;五是扩展性。当环境趋向标准，也带来了同质化的问题。因此，足够的可扩展性才能有自己的优势。

　　而这些，都指向了Kubernetes。

　　Kubernetes是开源的，有社区和厂商的广泛参与，允许第三方厂商以盈利模式提供服务，而不会以某一家厂商独占。重要的是，Kubernetes专注于API以及应用规范的制定，实现方式和应用性能可以不一样，但面向用户的API和规范是一样的。Kubernetes有灵活的扩展性，但同时又有避免社区分裂的机制。

　　青云QingCloud的Kubernetes路线

　　首先，作为云计算提供商，青云QingCloud把Kubernetes的规范与平台做整合，并开源相关的插件，同时在青云QingCloud AppCenter提供一致的Kubernetes服务。用户可以直接使用青云QingCloud提供的Kubernetes服务，也可以自己搭建Kubernetes并安装青云QingCloud开源的插件。

　　第二，在云上提供Kubernetes的集群应用，目前已经上线，并且最新版的1.7.4也将在9月初上线。

　　第三，青云QingCloud会尝试扩展Kubernetes规范，让Kubernetes支持更多的应用。现在的困境在于大多数应用是在Kubernetes之前产生的，很难快速迁移到Kubernetes上。这个过程需要QingCloud AppCenter对应用熟悉的的黏合剂或者解决方案，以便不同模式的各种应用和Kubernetes的规范快速融合，从而让Kubernetes支持更多的应用。

　　其实在QingCloud Insight大会上，青云QingCloud就已推出了Kubernetes容器集群管理与编排应用，通过QingCloud AppCenter交付，5分钟内即可完成部署，并与QingCloud IaaS平台深度集成，充分整合SDN和SDS能力，提供极致的底层性能保障。此外，Kubernetes容器服务完全兼容原生API语法，将用户的学习和迁移成本降至最低。

　　当然，青云QingCloud并没有打算死磕Kubernetes，未来青云QingCloud的容器服务也将全面支持Mesos、Cloud Foundry、Swarm等主流平台，接驳更多应用类型。

　　责任编辑:DJ编辑