最近做基于docker技术的管理系统有一段时间了，对Docker技术的理解、部署实施、问题解决也算是有了一定的功力，纠结了好久该不该耗些时间写点什么，终于在这个躁动不安的夜晚决定下来，需要为自己的付出留下些痕迹；

说到docker，这个当前大热的虚拟化技术，业界也有很多声音，从源码解析、到部署管理系统、再到上层应用方案，各种资料都挺多的；对于docker，业界也有很多宏观的看法，很多文章都有指导docker可以怎么用、应该怎么用，实际有很多文章谈的很虚，个人不喜欢在那些虚的东西上浪费口舌，因为没有真正去做过的人，怎么说、说什么都是可以的，只有立场，没有行动，可做参考，但没实际意义，只有真正去做了，深入细节挑战过后，才能炼出精华；

docker本身是基于LXC container技术发展起来的，核心是cgroup、namespace，个人觉得对比LXC的优势主要体现在集成管理以及更丰富完善的周边支撑，其实Docker已经是款产品了，但就docker 本身而言，产品形态比较简单，但是它的产品特性是依附于集群式部署与流程化管理，需要基于它之上的管理系统支撑，才能很好的铺开并服务于上层业务，真正的产品化；

首先谈谈当前开源基于docker比较火的集群式部署管理系统：Kubernetes(简称k8s)，它是基于Docker技术的nat网络模式构建的，个人觉得它有优有劣，从三个角度来说说：

1、部署和管理。-

优势：以管理者的角度看，因为k8s的集群环境相较于实际生产环境，算是比较纯粹干净（特别是业务线比较长的公司），且使用的nat模式，横向扩展可以很方便，可以轻易的扩展部署和迁移，结合docker快速上下线的技术特性，使得动态调整部署很方便，是一套比较不错的高效部署管理系统；

劣势：k8s架构本身基于三角稳固体系，且中间有嵌套，逻辑比较重，为了连贯整套体系，保证服务质量，架构中间的辅助性支撑节点偏多，使得k8s要维护本身的框架所消耗的资源成本偏高，简单举例：k8s架构基于三个基本的管理对象（pod、service、replicationController），典型的三角稳定模型，相互关系类似于我们熟知的执法、立法、司法，其中pod对象也是有自己的架构，也是基于三角模型的管理对象（container、kubelet、proxy），通过这套集群管理系统接入一个业务，整套流程下来，至少要经过两趟嵌套式的管理架构，最后才能实现真正的docker container的落地使用，如果业务体系本身的架构比较轻可以支撑，但是一旦业务本身的架构比较重，假设分接入、逻辑和存储，各层次中间还有均衡容灾，用k8s部署管理，会导致这整套体系中间的支撑逻辑会非常重，架构成本会很高；

2、与实际生产环境的兼容结合

优势：纯粹干净的集群环境，适合新的业务部署，结合镜像的使用方式，可以将开发、发布、部署封装成一条龙流程，实现高效快速的开发迭代和发布部署；

劣势：相较于大部分公司的业务系统都是基于IP为状态做的发布、部署、管理、监控，基于nat无状态模式运营管理k8s其实很难兼容铺开使用，它更强调依赖底层单纯干净的集群资源环境，它有一套自己的发布、部署、管理、监控的体系，与大部分公司已有的体系比较难融合，如果是小公司还比较好，业务范围不广，运营压力不大，从开发、发布到运维的整条生产线，直接迁移到nat模式或许可以接受，但是如果公司业务比较多，业务架构比较重，要迁过去或做兼容成本是非常大的，甚至可能是颠覆性的改革，而且改革结果是不确定性的，很多公司其实是很难接受的，简单举例：假设A公司已有一套基于IP为状态比较完善的业务系统，上游的发布工具、中游的资源管理和部署调度系统、下游的监控告警系统，整套流程都比较好用，如果让k8s支撑这套业务，需要把这套东西都改为支持nat模式，所有的流程中间都必须有一层nat转换，上层无法得知映射后面具体的IP，就算知道了，IP也是复用不唯一，会导致之前基于以IP为状态做的管理、调度、监控、告警会全部瘫痪掉，简直就像武侠小说里说的欲练此功必先自宫，代价太大；

3、成本

优势：如果公司打造了一套纯粹的基于k8s 集群部署环境，能快速的批量扩缩容，集群本身弹性扩展比较方便，能很高效的实现运维人员追求的部署流程傻瓜自动化，从人力角度来评价，还是很省成本的，很高效；

劣势：如果从设备资源的角度考虑，由于相较于其他模式的管理集群，对容器的使用方式都一样，k8s本身不能提供更高级的可智能学习迭代优化机制，而且也没基于系统层级对硬件使用做优化策略，所以在容器对资源使用这块不会有成本优势，相反，由于nat模式本身就耗设备性能，如果一台机器部署几台容器，当业务请求都上来的时候，性能下降肯定比线性更严重，另外，由于k8s本身架构繁重，为支撑并保证集群稳定运行，还会耗用一些资源，且集群越大，成本越高，可拓展性预期比较差；