2016美国QCon观察:容器与调度这么热,未来会是怎样的一个趋势?

  1. 云栖社区>
  2. 阿里云数据库ApsaraDB>
  3. 博客>
  4. 正文

2016美国QCon观察:容器与调度这么热,未来会是怎样的一个趋势?

猫头鹰子嘉 2016-11-09 14:55:26 浏览4640

编者按:今年QCon容器/Docker和微服务几乎占据了会场的半壁江山,大家也都趋之若鹜场场爆满,而且作为一名云计算工程师,对容器/Docker也是格外关注,容器/Docker已经不仅仅是个技术,而是作为一个生态在深刻影响着每一个细分行业,对于每个行业既是机会也是挑战,稍有不慎可能就会被时代抛弃。作为与会者现场聆听大家对容器/Docker的思考和应用,并逐步廓清现状和未来,与大家共同学习。

    容器(Container)是近些年迅速火热的一门技术和话题,容器技术本身和在容器之上衍生的资源编排和调度技术也在飞速发展和演进之中,容器的代表有Cgroup,Docker,VM等,编排调度的代表有Google开源的Kubernetes以及Apache社区的Mesos,有了容器这个基础之后微服务(MicroService)也从一个萌芽和概念逐步变成一个现实,并在生产环境中不断得到应用和验证。

    本次2016 San Francisco大会上Container容器、Scheduler调度器、Resources Orchestration资源编排、MicroService微服务等系列技术成为了整个会场最热门的话题,来分享的既有Amazon、Apple等大公司,也有Mesosphere、Netflix和其它一些行业翘楚。

    提到容器就不得不说Docker,Docker目前几乎成为了容器的代名词,有关Docker的文章汗牛充栋,不再赘述。Kubernetes也是Docker生态中的一员,Kubernetes为应用提供资源调度、部署运行、负载均衡、服务发现、弹性扩缩容等功能,Kubernetes是Docker出现之后Google基于Borg的理念开发的产品,可以理解为Kubernetes = Borg + Docker(实际还是有些差别的),当然Borg是无法开源的,Borg如果开源估计半个Google的技术栈都要开源了,后续讲到的Mesos也是与Borg对标的一个技术产品。

    来自Apprenda公司的Mattew Miller分享了利用Kubernetes实现业务微服务化的实践经验,主讲人分享了Kubernetes的架构和目前在开源社区的活跃程度,当然是极火了,Kubernetes中有Controller、Pod、Services几种概念,Pod是一组提供相同服务的容器的统称,Services是以逻辑或者ip地址对外提供服务的内部服务供应者,Controller是Pod的复制抽象,用于Pod的扩缩容,对于搭建平台的用户来说Kubernetes不但提供可靠的cluster&workload管理、还有丰富的经过实战检验的几种pattern抽象,如:

Rolling Deployents:滚动部署新版本并不中断服务,在新版本部署完成后老版本退出

Sidecars:比如收集已有服务的日志

Ambassador:比如提供访问sharding数据的统一入口

Adatapter:比如将服务日志格式转换成日志系统可以识别的格式

Leader Elector:保证提供单例服务访问

Work Queue:将Service从1:1的关系扩展到1:N,为被访问的Service前置一层代理Agent,用来转发请求

AutoScale:根据收集的业务metric来决定是否需要自动扩缩容

    接下来来自Mesosphere(Mesos的发起者)公司的Zhe Yu分享了Mesos的发展历程和最近的一些改进, Mesos提供资源管理和调度框架抽象的功能,第三方应用需要实现Mesos框架提供的API才能接入Mesos所管理的资源,具体的原理和架构可以自己去google。Mesos近些年发展比较稳健,已经在若干大公司的Production环境使用,目前Mesos最大的部署规模是30000个节点超过25W个容器,Apple的Siri就是基于Mesos来实现,Amazon内部据说也用到了Mesos,主讲人也提到了Mesos的一个优势就是提供flexible的可插拔的scheduler,当然Mesos本来就是为此而抽象的,还有flexible的服务发现机制,包括但不限于DNS/ZK/Chubby等,在此还吐槽了一下基于DNS服务发现的机制,虽然没说具体原因,但是应该和DNS的生效时间不可控有关,而且DNS还会受到本地local绑定、JVM虚拟机缓存DNS解析结果等细节问题的干扰,所以不是一个好的选择。由于Docker实在太火,Mesos也加入到了支持Docker的阵营中,从Mesos 028版本开始支持,Mesos支持的Container种类繁多,甚至tar包也可以被当做一种Container,而且也支持Nested Container,还提供了类似于Docker CNM的CNI(Container Network Interface)方案来更清晰剥离Container和网络。

    听完Mesos的分享感觉Mesos还是感受到了来自Kubernetes的压力,也有人现场提问Mesos和Kubernetes的区别,虽然Mesos和Kubernetes根本不属于一个层面的东西,但是Kubernetes更易用更贴近用户业务,Mesos属于我们所谓的一层调度,主要解决资源管理调度问题并提供抽象的框架API,目前熟知的主要应用领域也是Spark,Marathan,Cassandra等大数据相关的应用,每个应用接入时都要完整实现Mesos的API,也就是我们所谓的二层调度,所以还是有不少开发工作在的,门槛较高;Kubernetes主要用来容器调度和服务发现,没有什么额外的开发工作,而且对于一个需要快速Bootstrap的创业公司来讲,明显Kubernetes是一个更接地气的存在。其实Kubernetes和Mesos是可以共存的,Mesos甚至可以作为Kubernetes的资源提供者,两者解决的本来就不是同一层面的问题,应该说Kubernetes解决了Mesos无法解决的问题,而这些问题是更为普适的痛点。稍后来自Apple的人分享了Mesos的最佳实践,尤其是对Stateful和Stateless的服务的区别管理可圈可点。

    Amazon的人也分享了ECS(EC2 Container Service)的一些基本原理和实现机制,能够让用户方便地管理大规模的容器集群,并通过API的方式来自己编程随心所欲管理Docker和其它各种资源如ELB,当然其它云厂商也有对应的服务,如阿里云的容器服务(Container Service),Azure的ACS等。

    今天还听了一些其他场次,会在其它文章中分析汇总,本文主要聚焦容器和调度问题。