您的位置:首页 > 运维架构 > Docker

Docker集群部署管理(一)初谈

2016-01-13 23:57 666 查看
最近做基于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本身架构繁重,为支撑并保证集群稳定运行,还会耗用一些资源,且集群越大,成本越高,可拓展性预期比较差;
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: