摘要:马拉松会匹配每个和提供的资源,然后通过将任务下发下去。对外暴露的就是负载均衡的某个服务,后面自动将流量转发到某个容器的端口上。还有一直办法是用内网的,这个会维护现有的容器列表端口,并且返回任意一个的端口,页实现了负载均衡和服务发现功能。
回顾Java的发展轨迹看容器技术演讲嘉宾
数人云COO 谢乐冰
在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。
因为我自己写了十几年的Java,经常把容器和十年前的Java做比较。一个公司说自己是做“Java”的,实际上涵义是背后一整套企业IT基础架构。软件一般都是各个集成商(东软、文思)大量码农兄弟们开发,主要还是用Windows。打成了WAR、EAR包之后交付给甲方,就可以在Linux环境下跑起来。同样Weblogic WAS这些中间件在底层计算集群之上,实现了企业服务的大规模运行。
中间件之下是IOE昂贵的高性能硬件,虽然也是集群化,主要依靠Scale up来提升性能。虽然中间件理论上实现了应用和硬件资源解耦,但实际上依然对硬件有非常苛刻的要求,特别是跑数据库的部分。
整个架构为了向上实现SOA的架构,虽然现实中90%以上顶多做到了“面向对象”,但并不妨碍Java(J2EE)作为企业服务交付的“通用”形式,成为了开发单位和运行单位共同接受的标准。所以Java背后代表的不仅仅是一个语言,还是一个完整的IT基础架构和产业链 —— 昂贵的高性能硬件、闭源的中间件软件、Java作为交付接口、SOA架构和开发与运维分离的模式。
背后还有两个隐性的英雄,一个是北大青鸟这样的培训机构,大量产出Java程序员。另外就是Oracle数据库,当然这些年轻程序员写的代码效率不太高的时候,全靠数据库来救场了。当然这一切还是传统的企业业务决定的,例如ERP、CRM等等,并发较低、强事物性和强一致性、逻辑和关联关系复杂。
如今时代发展到了蓝色的部分,云计算时代的IT架构底层不再是几台小机或者一堆刀片,更多的是企业私有云甚至是公有云,IaaS实现了资源层管理的自动化和标准化。
容器就像当年的Java一样,成为了开发和运维共同认可的接口。容器成为了应用上“云”的标准交付方式,不管是Java、Python还是C,只要用Docker打包,就可以丢到这个那个“云”上跑起来。
当然在底层各种计算资源(公有云、私有云甚至物理机)之间,也需要一个中间件来作为容器的大规模运行环境。下面是成千上万的主机,上面是乌央央的容器,中间的云计算中间件实现了两者的解耦。上面支撑的软件架构是“微服务”架构,就像当年的SOA。整体上也是实践了Devops一套运维开发方式。就像传统中间件包括了运行环境、消息队列、ESB(服务发现)和数据抽象等等,云计算中间件也都有类似的服务,例如Mesos、K8s这些容器运行环境,就对应着跑EJB的Weblogic Application Server。
总之,“容器”背后不是单个技术,而是完整的以开源软件为主的云计算IT基础架构和相应的开发和运维流程。当年虚拟机出现让大家尝到一点点云的滋味,但是毕竟局限于资源层,对开发、业务和软件架构没有影响。如今容器影响这么大,大家终于成为了应用上云的突破口,将对大家未来的职业生涯产生巨大的影响。就像今天很难招聘到懂EJB的大学毕业生,过两年很快容器和背后的互联网开源技术栈就会成为主流。
有关Mesos与K8s的老生常谈言归正传,下面我来一步一步地介绍Mesos的实战。说起Mesos,大家往往第一个问题是Mesos和K8s有啥区别,哪个更好。我觉得这两个就像iOS和安卓,已经成为了新一代轻量调度框架的主流。两者都是源于Google的Borg,但Google自己没有使用任何一个。K8s胜在开发者多,用Go语言开发,社区活跃。Mesos是Apache项目,已经诞生了7年,目前有过超过万台规模的部署。总体上我们认为Mesos比较适合目前阶段的大规模生产环境部署,K8s目前还处于快速更新的阶段,两者都有很好的未来。当然Mesos也能兼容大数据等框架,未来目标是逐步把各种集群化的应用(Kafka集群例如)都搬到Mesos上来,实现一键安装和自动扩展。
下面是一点点Mesos的科普,其实市面上类似的文章已经不少,这里我特别推荐平安科技余何老师的《PaaS实现与运维管理:基于Mesos +Docker+ELK的实战指南》,内容非常详细。
用两句俗话说Mesos和K8s的原理,就是像使用一台电脑一样使用整个集群,类似集群的操作系统。单机的操作系统是管理单机的计算、存储和IO,集群操作系统是管理管理一堆机器的资源。目前聚焦在计算和内存之上,存储部分需要多带带的分布式存储(例如Ceph和GlusterFS),网络需要SDN的支持。不过传统上IOE也是各管一摊了。
原理看起来也不复杂,Mesos 在每台Slave主机上安装一个Agent,不断地把剩余资源上报到Master。报告内容类似 { (node1, <2 CPUs, 4 GB>),(node2, <3 CPUs, 2 GB>) },这样Master就知道各个机器的剩余资源情况了,非常简单。
Master上面有很多框架Framework,例如Docker和Spark。你就可以把他们理解为Linux里面安装的JRE和Golang、C的运行类库。你想在Mesos上跑啥“语言”,就要部署个框架,例如跑Docker的框架就是Marathon。Mesos会把整个集群的资源按照一定的算法分配给各个框架,这个就是所谓资源调度的过程。因为Slave上报资源情况是不断更新的,所以就是所谓动态资源调度。
每个框架收到分配的资源之后,会自行决定将任务和资源匹配,然后通过Master将任务下发到Slave上执行。Slave上面有每种任务的执行器(Executor),就是运行环境。例如Docker任务的执行器是Mesos预装,其他类型任务执行器可能会实时下载。所以通过安装不同的框架+执行器,就可以支持各种“分布式”的任务系统。请注意这里说的一定是集群化的系统,如果是单点部署一个MySQL之类的就意义有限了。
以管理Docker任务的Marathon框架为例,它收到了Master提供的资源之后,一个是负责进行任务调度,而且还能够通过Health Check监控任务是否还活着,发现失败就重新下发任务。
这些都是常规性的解释,下面我们看看Mesos集群,看看如何一步步搭建。初始一般需要准备3台主机承载Master节点,任意多的Slave,这里建议也是3台。还有几台机器存放log等等。下面的一些图片来自前两天数人云公众号(dmesos)翻译的文章《初次微服务体验:从Docker容器农场说起》。
第一步 部署Zookeeper,负责整个集群的分布式一致性,例如Master领导选举
第二步,部署Mesos本身。我们的分布部署了3个Master,管理3个Slave节点。大家注意到,配置Mesos的时候最重要的参数就是Zookeeper,不但Master要通过ZK来进行领导选举,而且Slave也可以通过ZK来知道谁是活跃的Master.
到这一步,理论上已经可以用Mesos来管理集群下发任务了,大家看见下图里面资源(Slave)、任务(正在执行的已经介绍的)。
甚至还能看到该任务的Stdout输出,就和SSH进去操作一样。
不过仅仅有Mesos,还要自己来编写框架调用接口发布任务,非常不方便。所以需要一个框架来跑容器任务,那就是马拉松(Marathon)。顾名思义用来跑各种长时间运行的服务,类似Linux里面的Inti.d,例如各种网站服务。马拉松是用Scala编写的,本身提供自己的Web管理界面,通过这个界面我们可以“遥控”Mesos来下发并保证Docker任务长久稳定执行。
马拉松的界面也非常直接,大家看看发布Docker任务的界面,基本就是填入Docker Run后面的那些参数,然后告诉马拉松要发布多少份。马拉松会匹配每个Task和Mesos提供的资源,然后通过Mesos将任务下发下去。
结果
服务发现
服务发现是个比较晦涩的翻译(Service Discovery),大概不妨粗略地理解成负载均衡算了。例如马拉松下发了100个网站的容器,每个容器有自己IP(一般是宿主机)和端口。显然前面需要挡一个负载均衡来分配流量。对外暴露的就是负载均衡的某个服务URL,后面自动将流量转发到某个容器的IP+端口上。
我们这里用HAProxy来做负载均衡,有个服务叫Bamboo会不断从ZK读出Mesos状态并且更新HAProxy的配置文件。这样新发下来的Docker会自动添加上HAProxy,而死掉的会被移除。
还有一直办法是用内网的DNS,这个DNS会维护现有的容器列表(IP+端口),并且返回任意一个的IP+端口,页实现了负载均衡和服务发现功能。不过目前Mesos DNS还不太成熟,我们一般用HAProxy。
几百个Docker撒出去,绝对不可能再登到主机上去找看日志。日志必须集中收集,并且提供检索功能,才能有效的Debug。解法也不新奇,无非是ELK。请注意Docker日志可以直接从API读出,另外需要增加一些应用、主机和容器有关的Meta Data。
此外分布式系统不能没有监控,黑盒子等于无法运行,所以监控要分为如下三个层面。
主机监控:这个并非Mesos的关注点,因为主机是资源层,本身也有自己的监控体系
容器层面的监控,主要是用cAdvisor,包括CPU、内存和IO
最最重要的是应用层监控,因为PaaS本身对外提供服务,所以监控的关注点应该是全局最终结果和逻辑正确性,而不是太纠结于个别主机和容器的
这个是分布式系统和传统系统最大的区别,关注点不再是个别容器和主机,而是业务本身。这种系统设计本来就是希望软件脱离对特定和单点硬件的依赖,通过集群化实现大规模系统的高性能和高可用。所以监控不再是着眼于“源头”,而是看重效果。很多时候平台的自愈机制甚至“埋没”了底层的一些故障,那么就让他被埋没了,只要最后效果能够得到保证。
分布式系统在应用层监控要求远远大于普通的IT系统,例如下面是一个HTTP返回状态吗的直方图,这样能很快发现是否出现大规模异常,并且通过日志系统来定位问题。
分布式系统和传统IT区别,就像市场经济和计划经济一样,不是要处处完全可控有计划,在最终结果保持可控情况下,突出灵活性、自由度和弹性,支持业务多变和快速发展。
这样一个基本的分布式系统就搭建完毕,当然如果是生产级别还需要有大规模集群运行调优、集群化HAProxy,监控和报警对接、多租户管理、F5的对接、和Openstack等等的IaaS对接等,这样就需要数人云这样的商业化开源方案来支持了。
此外经常有用户问到,啥样的应用可以上云呢,下面的表格回答了这个问题。
可以看到,这个问题的回答并不是黑白分明。最理想的当然是完全的微服务架构,可以发挥全部的作用。当然90%应用目前还是有状态应用,所以可以快速扩张,但是无法收缩,需要实现Graceful Stop功能,慢慢地收缩。所谓的无状态化改造,无非就是很标准互联网架构,不要用J2EE内置的Session就好。
本来今天还要展示一个我们的客户案例,如何将一个分布式系统迁移到Mesos之上,因为时间关系,下次再分享吧。
精彩问答 QQ群Q1:当初刚接触Linux的时候,最开始是在Virtualbox等虚拟机这种模拟环境里面摸索 Linux,代价低,比较容易动手和入门。对有一定基础的运维人员(但刚接触容器集群),你建议用什么配置的环境测试做 方便入门(比如测试 Mesos+ZooKeeper+Marathon+Docker)
A1:虚拟机就可以,VARGANT
Q2:Docker的数据持久存储采用何种存储,用Ceph之类?
A2:对,各种分布式存储,例如Glusterfs
Q3:我想问一下K8s+Docker 现在用作生产的话够成熟吗? K8s能达到高可用了吗?
A3:小集群的话可以倒腾倒腾,K8s的源码有浙大张磊老师的书
Q4:还有就是Mesos能否和Openstack结合起来,生产环境有没有Docker和Openstack结合的案例
A4:必须可以,我们就和Openstack厂商一起合做生产系统部署了。可以这么说,完整的DCOS是包括IaaS+PaaS,如果企业要对底层资源严格管理,就需要IaaS
Q5:我想问下Docker的性能,尤其是网络部分,比物理机和普通虚拟机差很多么,用集群性能会不会好些呢
A5:如何是Host模式,Docker网络性能和物理机一样,具体可以看 这里有一篇IBM的论文,讨论了差别:
http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf
Q1:一直想问Doceker会不会一定成为下一代虚拟化。
A1:反正Docker已经基本成为了开发和运维和厂商都比较接受的上云交付形式。
Q2:容器算不算虚拟化的一种,一台服务器,上边跑很多虚拟机怎么更好的提升性能。
A2:最好不要把容器当成虚拟机,虚拟机的意思是和特定IP或者宿主机绑定,而容器特点是在云上飘来飘去。例如经常有需求是给容器分配IP,其实就是当虚拟机了
Q3:有开源版供学习吗?
A3:Mesos这些都是开源的,可以参考平安余何老师的著作,数人云管理平台本身是不开源的。
Q1:ELK本身也是Docker来部署么?
A1:目前有状态的服务很多都有Mesos框架,但是在生产环境中产品化还不多。我们目前不建议客户数据库等应用放上来。背后逻辑也是这些服务,一般还不太需要动态扩展和更新,就算实在互联网公司里面。下一步我们也会推出企业应用商店,会把一些经过测试已经产品化的集群化组件放出来,这个还需要一些时间。
Q2:首先说一下我还没有完全拜读完,这个话题很热,我也很感兴趣。我想问的问题,不是具体的技术问题。我是想问一下:传统的数据中心和传统的企业业务,如何在这场技术大潮中转移到新的技术架构。例如我们现在的数据中心怎样转移到您今天分享的这种架构上来?
A2:四个字“业务驱动”,不上云就宕机,或者看着满地黄金捡不起来,就自然有动力了。
一般说来是7个字,新业务上新平台。互联网的成功在于不是顶层设计,而是消费者的业务驱动。
当然,对于技术水平较高的大型企业,未来交付形式普遍容器化之下。他们引入容器的核心目的是推进自身架构云化改造。
Q3:你们回答的是什么应用适合上云还是容器云?
A3:首先“容器”是应用上云的Gateway,所以可以说泛指上云的应用,云端应用最好都符合Cloud Native架构。当然IaaS也是云,传统有状态应用理论上无需改造也能上虚拟机。不过传统应用强烈和底层硬件特定能力绑定,而虚拟机网络IO不一定满足需要,所以上云的过程同样需要改造。例如数据库分片来减少单节点压力等等。
Q4:安全性呢,公司有的业务不敢轻易放上去,这方面的问题如何解决
A4:适合内部私有云,公有云需要底层IaaS协助网络和虚拟机层面隔离
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/26553.html
摘要:容器跟虚拟化是解决不同问题的,从这一点来看与有相似之处,我认为虚拟化解决的一个重大问题是隔离和安全的问题,而容器则解决的是快速交付的问题。同时也可以应用一些虚拟化比较成熟的技术,包括容器的容器的热迁移,现在也都具备一些初步的方案。 5月26日,数人云产品战略发布会在北京万达索菲特酒店举行,发布会最后一个环节圆桌论坛可谓大咖云集,小数为大家在第一时间带来了实录分享,快来感受下容器生态圈的...
摘要:分享实录云计算技术源于互联网公司,现在云计算已经是下一代企业级的发展趋势。如何做云计算一直是云计算技术的领导者。互联网公司的快速发展,已经印证了云计算技术和云原生应用相比传统构架的巨大优势。 今天小数又给大家带来一篇干货满满的分享——来自KVM社区线上群分享的实录,分享嘉宾是数人云CEO王璞,题目是《云计算与 Cloud Native》。这是数人云在KVM社区群分享的第一弹,之后还有数...
摘要:今天小数给大家带来一篇技术正能量满满的分享来自社区线上群分享的实录,分享嘉宾是数人云肖德时。第二级调度由被称作的组件组成。它们是最小的部署单元,由统一创建调度管理。 今天小数给大家带来一篇技术正能量满满的分享——来自KVM社区线上群分享的实录,分享嘉宾是数人云CTO肖德时。 嘉宾介绍: 肖德时,数人云CTO 十五年计算机行业从业经验,曾为红帽 Engineering Service ...
摘要:刚才听了谢乐冰的演讲我觉得很多东西和我们的思路非常像,从我回国到现在大概有一年多的时间。在看来,一个业务应用应该是分层的,每一层都是一个所谓的服务,刚才谢乐冰讲的所谓服务化和异步化,不会把这些东西从前到头搅在一起,这样非常难以扩展。 本文是数人云深圳技术分享课上Coding CTO 孙宇聪的演讲实录,小数带你走近这位诙谐幽默的大牛,领略他深入的见解和丰富的实践经验。 非常感谢今天有这个...
摘要:今天,小编给大家分享大会第二期干货。田琪深入理解容器技术首先大家肯定要清楚容器和的本质区别,通过内核提供的这个东西,能够让你完成进程级别的隔离的效果。 showImg(http://sharlyne-lee.qiniudn.com/ecug2.png); 今天,小编给大家分享ECUG Con 2014大会第二期干货。 下面是田琪(京东资深架构师)、何全(多备份技术总监)、马全一(d...
阅读 2832·2021-10-14 09:43
阅读 1602·2021-09-29 09:34
阅读 1724·2021-07-28 00:16
阅读 2941·2019-08-30 15:53
阅读 2878·2019-08-30 13:59
阅读 2907·2019-08-30 13:57
阅读 1062·2019-08-26 13:38
阅读 1856·2019-08-26 13:25