当然，打包了诸多的工具，随之带来的就是镜像的庞大，镜像的体积也不可遏制的从几百兆增长到了GB级别。而借助于工具链的标准化，镜像的种类就被缩减为了几种。考虑到创建容器的速度，我们采用了镜像预分发的方式，将最新版本的镜像及时推送到计算节点上，虽然多占用了一些磁盘空间，但是有效防止了容器集中创建时，镜像中心的网络、磁盘读写成为瓶颈的问题。
使用已有工具链也意味着丧失了docker容器的一些优良特性。比如应用的发包升级上线仍然通过既有的自动部署系统，而无法利用docker的镜像分层。工具链之间的壁垒也制约了平台的集成能力，难于实现一键部署的效果。容��的弹性和迁移也只能以一个空壳容器本身的伸缩迁移体现，而不是应用层级的伸缩迁移。
弹性与迁移弹性主要包括横向伸缩和纵向伸缩。横向伸缩主要是指调整应用容器的数量，这个主要通过创建/销毁容器进行实现。纵向伸缩主要是对单个容器的资源规格进行改变。因为容器对于CPU和内存的限制，主要是通过cgroup实现的。因此纵向的伸缩主要是通过修改cgroup中对应的值进行。
容器的迁移还是冷迁移的方式呈现。由于公司相关业务的要求，容器的IP要尽量保持不变。因此我们在neutron中做了定制，可以在迁移后保证容器的ip地址不变，这样对外启动后呈现的服务不会有变化。
容器的运维目前运行有大量容器，部署在多个机房，分为多个集群。如此大规模的容器运维，实际集群的运维人员并不多。主要原因是对于运维的权限进行了分割。对于物理机、容器生命周期的管理，由集群的运维负责。而各个线上应用的运维，由各个应用配合的垂直运维(又称为应用运维)负责。一般问题，如物理机下线，因为涉及到应用下的该实例需要下线，由集群运维查看该物理机上的容器所属的应用，需要通知垂直运维，配合容器迁移，而后重新上线提供服务。二新增机器或者集群，对机器部署了容器平台系统后，即可交付集群运维，用以创建容器实例，并进而根据应用的申请，分配给各个应用。相较于一个应用的平台，很多操作还有一些手工的成分，因此还需要投入相当的人力在集群管理上。