Docker在春晚中的实际表现

Docker成功的为1.02亿小伙伴刷微博,抢红包提供了可靠的服务。接着上一篇文章《大规模Docker集群助力微博迎接春晚峰值挑战》,这里给大家分享Docker在春晚实战中的实际表现,以及对于后续发展的的思路,由于篇幅有限这里仅点到为止,如果大家希望了解更多干货,我在QClub:Docker专场等着你。

首先介绍一下微博平台Docker集群规模情况:

  • Docker集群规模达到1000节点
  • QPS峰值达到800K
  • 整体服务SLA达到150ms四个9
  • Docker化部署共覆盖23个服务
  • 春晚共调度近300节点完成服务动态扩容

在分享之前,先抛出一个问题:当部署规模达到万级别的时候,最大的技术挑战是什么?欢迎大家留言探讨。下面言归正传,介绍一下微博平台目前Docker部署环境采用的技术:

  • 宿主机CentOS 6.5,考虑到目前生产环境现状和CentOS 7的安全性、稳定性、兼容性等方面的问题
  • Docker采用1.3.2版本,需要注意1.3.2依赖的一些lib版本与CentOS 6.5默认安装的有冲突
  • 网络采用宿主机模式,NAT和默认Bridge方案都不能满足平台的诉求,OVS+Vlan的方案还在研发中,所以生产环境采用的是-host方式
  • cAdvisor + Elastic Search + Kibana + Graphite作为容器监控方案
  • 文件系统采用devicemapper,建议指定一个格式化的分区给devicemapper,否则建议根据根据应用情况,通过dm.basesize,dm.loopdatasize调整稀疏文件配额
  • Registry用的是docker-registry 0.9.1版本,较老的版本存在压缩时假死问题

在容器编排方面,参考业界实践并结合自身业务特点和现有基础设施,实现了适合平台业务的定制化的解决方案:

  • 一容器一进程,一是方便监控服务生命周期,二是方便进行资源隔离
  • 日志采用数据卷挂载,一是避免容器内产生大量数据,踩devicemapper稀疏文件的坑,二是方便通过容器做数据采集与压缩
  • 容器生命周期管理,实现类似Fig/Composer的功能,同时增加了大规模并发调度的能力
  • 服务发现,实现参考了Kubernates的Pods和Service概念,但是没有采用自上而下的治理方式(Replication controllers),而是采用自主上报的方式,方便灵活调度。
  • 无缝对接,重点解决Docker模式与普通进程模式并存情况下,运维管理的复杂度问题,确保Docker集群可以与其他运维子系统(例如降级子系统、上线发布子系统等)无缝对接
  • 可量化,从QPS,服务SLA,系统负载,存活率等多个维度衡量各服务Docker集群的冗余情况

对于Docker在平台的演进,也是对应上面提出的问题,个人认为当部署规模达到万级别后,最大的技术挑战有下面几个,平台也会在这几个方面继续探索,也希望能够把经验回馈给社区:

  • 网络瓶颈,万级别的容器部署,势必会挑战现有的网络基础设施,需要通过SDN等技术来解决网络规模问题
  • 与原设施的整合,可能是大多数团队在推进Docker落地时遇到的最头疼的问题之一,我们希望能够提供一些标准化的解决方案使迁移过程更加平滑
  • 一切皆容器,但仍存在一些技术问题需要解决,例如在容器内管理容器的稳定性问题,短生命周期的容器管理等等
  • 目前我们还处于“社会主义初级阶段”,一切都还要靠“中央”下达指令,无法管理万级别的动态集群,Kubernates、Mesos、Swarm的技术提供了可能性,但整体解决方案我们也还在摸索,我们希望能够听到你的声音
Written on March 5, 2015