Docker在春晚中的实际表现

2015年3月3日 16:02

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

首先介绍一下微博平台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的技术提供了可能性，但整体解决方案我们也还在摸索，我们希望能够听到你的声音