第二，容器启动速度问题。申请容器时可以开一个相对比较大的KVM，第一个容器启动会有KVM启动时间，第二个容器启动就没有KVM启动时间，你就会立刻体会到容器的好处。
第三，容器的规模问题。大家都开始使用公有云之后，容器规模会迅速扩大，也会导致整个Kubernetes集群迅速扩大，从千节点现在已经到了15000节点。
第四，容器的租户隔离问题。除了CPU、MEMORY的隔离，网络隔离、存储隔离也是一个问题。
网易蜂巢平台及优化
这是基于OpenStack上PaaS平台再往上的容器和编排的平台。在容器这一层我们提供了自己的镜像仓库，因为在国外访问，由于防火墙的问题实在是太慢了，当然本地需要做一个cache，镜像取下来的时间几乎可以忽略不计。微服务场景下，必须要有日志服务，把一个东西拆成了很多个东西以后如果出现了问题，日志挨个看太多，所以日志服务采取类似ELK的方式，把日志收集起来，提供统一的搜索引擎，这样做之后交易的整个过程，哪个环节出了问题都一目了然。再往上就是编排，除了Kubernetes本身带的弹性伸缩和服务发现能力之外，我们做了有状态容器，弥补了从传统的虚拟机到最现代化的容器中间的过渡阶段。还有调度优化，为什么要做调度优化？当集群规模特别大的时候，原来Kubernetes自己的调度机制已经不能满足这么多节点的调度性能。作为一个分布式系统最核心的就是调度系统，这就是为什么很多大型的分布式系统最后都是在修改调度系统，比如OpenStack会把原来的调度系统分成很多的子服务，也是在做调度方面的优化。我们的多租户是全方位的多租户，不光是普通的隔离。
Kubernetes是有多租户的想法和机制的，比如有Namespace，但没有办法隔离节点、网络，网络和存储其实还是需要我们通过自己的机制来进行隔离的。节点的隔离是不同租户是不会共享节点的，这时候需要有一个LABEL做控制。网络隔离是利用IaaS层的能力进行网络间的隔离，不同租户会有自己的VXLAN ID。调度性能优化，Kubernetes本身是串型队列优化，如果都是这个方式，当集群大的时候任务队列会特别多，会有很多人上来提交任务，这个时候一个队列并不能解决问题，我们就改为了多个优先级队列解决问题，这样就可以多线程的处理。集群扩展性，Kubernetes会把数据放到ETCD里，Agent节点会到里面发现自己需要做哪些事情。我们后来发现集群规模大了以后，单独的一个ETCD集群不能放下这么多数据量，根据Pod、Node等资源，当一个用户有一个操作时，我们知道这是属于哪个用户，进行负载量均衡的拆分。
这是虚拟机启动优化做的事情。我们发现虚拟机启动之所以在分钟级就要分析一下，虚拟机启动用了多长时间，并不完全每一次都是一分钟，有时候长有时候短。OpenStack会调用DHCPServer，根据上面拉下来的东西进行本地的初始化，初始化由于各种问题会导致时间非常不可控。其实IP是可以静态化的，比如虚拟机的启动、容器的启动，刚启动的时候数据库就可以给它分配一个IP，Agent就知道将要用哪个IP，就不需要再通过DHCP的方式再分配IP。网卡打到虚拟机，虚拟机里的网卡会再放到Docker的Namespace里面，这样Docker访问网卡就只有一层的虚拟化。有一些传统应用，有些东西是放在虚拟机里的，新的应用是放在容器里面的，它们之间的相互调用不希望用外部NAT方式，因为性能会下降。如果可以统一管理，就可以做到只有一层虚拟化，如果虚拟机、容器里面的应用属于同一个租户的话就可以相互互联了。
蜂巢特色
蜂巢的特色首先就是聚焦应用，客户只需要做好自己的微服务和DevOps就可以了。哪怕不能完全做好，下面有跨主机的二层网络、有状态容器、外部统一存储这三个，并没有意识到用容器的方式和虚拟机有太大差别。公用的监控、镜像、弹性伸缩、持续集成的服务。下面有我们的PaaS层数据库、分布式存储，如果用蜂巢，不需要关心数据库的数据会不会丢失，自己要不要起个数据库，要不要起个DBA，这样就避免了麻烦。你只需要关心微服务化和DevOps，尽快把自己的服务上线，站在风口上就可以了。