写点什么

从Docker运维看知乎容器平台的优雅整合

2016 年 7 月 26 日

传统的部署是安装、配置和运行;而 Docker 的出现革命性地改变了传统模式,部署被简化为复制和运行两个步骤。因此,越来越多企业使用 Docker 提高分布式应用的构建与交付;但是与此同时,Docker 带来了很多不可避免的挑战,其中运维需要克服的挑战尤为突出。知乎曾经在 QCon 上与大家首次分享 Docker 架构和经验,也即将在 CNUTCon 全球容器技术大会详细讲述容器平台的实战历程。本次 InfoQ 就在 Docker 整合入原有架构过程中,如何实现的 Docker 运维对知乎两位专家进行了采访。

受访嘉宾介绍

林晓峰:知乎技术平台团队负责人。负责建设知乎各类基础设施平台、抽象各个基础设施的服务,以及为业务开发提供统一的基础设施平台接入。高性能 Linux 网络协议栈实现 Fastsocket 协议作者。

张阜兴:知乎平台架构工程师。负责知乎内部弹性计算平台,以及知乎容器平台搭建实施和各业务容器化进程。在高性能网络流量处理和分布式存储系统方面有过多年实践经验,目前致力于构建统一资源调度框架,分布式系统设计等方向。

InfoQ:可以简要介绍下知乎现在的 Docker 研发及使用情况吗?

林晓峰:知乎平台架构团队,采取研发和运维一体的 DevOps 模式;其中容器平台项目组目前的人数是 2.5 人。知乎几乎全部业务和服务(100+)都运行在容器平台(Bay)上,服务器资源申请已经对业务部门关闭。在业务峰值时段,平台整体容器数量会动态扩容到接近万个。

InfoQ:是在怎样的情况下,知乎选择了 Docker?它是否帮你们实现了所有的预期目标呢?为什么知乎认为使用容器方案是“重要决策”?

林晓峰:随着知乎业务的增长和微服务化的演进,越来越迫切的需要解决三个问题:

1. 环境隔离:在物理机时代,由于每个业务依赖的系统环境不同,服务器之间无法通用,服务器负载也各不相同;各个业务都需要独立管理服务器容量,处理服务器故障,对业务开发造成较大负担。
2. 精细资源隔离: 服务隔离要求按照服务接口对进程物理隔离,防止因为某一个接口而影响整体服务的问题,同时也需要根据不同接口的特性,设置不同的进程数、CPU 和内存配置,实现更加精细的资源管理。
3. 资源动态调整: 业务需要快速自动适应流量负载的变化。在负载高峰期快速增加资源,保证业务服务质量;在负载低峰期释放资源给其它服务,提高集群资源利用率。

上述问题抽象出来,其实需要一套高效的资源管理和调度系统

容器技术可以帮助我们实现应用环境的封装隔离以及 CPU、内存等资源限制;结合集群管理方案,能够实现资源的统一调度和动态调整:由此解决上述三个问题。从而实现业务开发人员可以专注开发业务逻辑,而资源调度和管理、负载监控、服务器故障等处理统一交于平台自动处理或者在必要时人工干预。

知乎容器平台(Bay)建设和实践到现在,从最初“邀请”业务迁移到容器平台,到现在业务要求使用容器平台,间接证明容器平台实现了预期目标。总体来说,容器平台有力的支撑了知乎的微服务化和迅速增大的业务规模,已经成为知乎基础架构的重量级组成。

InfoQ:能否介绍下知乎在搭建 Docker 平台架构时,是怎样考虑 Docker 运维模块的?

林晓峰:在搭建 Docker 平台时,我们的一个主要理念是 DevOps,通过这种模式来解决各个层面的运维效率问题。

  1. 对业务用户层面,容器平台明确业务开发能够完成的工作都由业务开发人员来操作,如日常的服务发布、配置变更。通过这种方式,既充分满足业务开发人员操作的便捷性,同时也减轻平台维护人员的日常工作量。
  2. 对平台内部层面,也是通过开发的思路来解决运维问题,即日常的处理尽量自动化完成。 以下面三类情况举例说明:
  • 容器集群扩容:在新服务器安装系统时,会运行 Salt 配置、安装并运行 Docker 相关后台进程和 Mesos-Slave 节点,这样机器就自动加入到了容器集群。
  • 服务运行的容器数量:可以通过预定义的指标实现自动的伸缩,业务流量增长和正常的流量波动无须人工调整资源。
  • 个别容器或者服务器故障:我们认为它是一种日常的、节点级别的“正常现象”,对其进行自动处理,而不是作为异常情况报警等待人工干预。相对的,容器组和集群整体的健康情况才是平台维护人员的关注对象,具体细节可以参考 QCon 北京 2016 知乎关于容器云平台分享的 Slides 和视频。

InfoQ:Docker 的使用都给知乎运维带来了哪些挑战?可否介绍下针对这些挑战,知乎采取了怎样的措施?

张阜兴:总结而言有三大挑战:

  • 容器平台的工作负担加重
  • 系统的整体复杂性增加
  • 某些异常情况出现

首先,原本由业务本身负责的系统运维工作转交给了容器平台(如业务资源变更,物理机异常处理等),加重了容器平台的工作负担。对此知乎的解决方案是:一方面通过设计集群的容错机制,自动处理物理机故障,避免人工响应;另一方面,总结业务通用的需求,例如业务容量的动态调整,开发新的平台功能来满足。

其次,Docker 集群方案引入了一些其他系统组件,如 Consul,HAProxy,Cadvisor,Graphite 等,增加了系统的整体复杂性。同时 Docker 本身还在快速发展,存在各种不稳定因素,相比于成熟的物理机运行环境需要处理的异常更多。为了解决此问题,知乎采用的措施是:针对容器平台的特点,合理使用这些系统组件,简化调用方式,例如在使用 Consul 做服务发现时,使用了 Consul 的 kv 功能来实现实例的批量注册和反注册对于 Docker 自身的问题,一方面借助社区力量修复 BUG,另一方面通过开发一些工具来处理。例如 Docker 网络方案在使用 Iptables 时会存在配置清理失败的情况,我们分析原因后,定制了 Iptables 系统包,避免了这种情况。

最后,随着容器平台集群规模的增大,某些异常情况出现的概率大大增加,某些组件的性能瓶颈逐渐暴露。对此,知乎的解决方案包含三个部分:一是在设计阶段尽量避免性能单点,如 Docker Registry 默认为单机版,我们改用 HDFS 作为其存储后端,实现了 Registry 的分布式水平扩展。二是在预估的集群规模下进行充分的压力测试,例如验证单机能够容纳的容器数以及启动速度;三是监控集群性能,在接近性能瓶颈时及早报警发现。

InfoQ:现有 Docker 几个监控开源方案,比如 Prometheus、Sysdig、cAdvisor,你们有研究或使用过吗?如果有,可否评论下这些开源方案?

张阜兴:在使用容器前,知乎已经有了一套比较完善的监控系统,采用的是 Statsd(采集)+ Graphite(存储)+ Grafana(图表展示)+ Halo(自研报警系统)。这套系统已经能较好的满足知乎业务运维需求,因此容器平台监控主要是采集指标与这些已有的系统进行整合

对于这三个监控开源方案:

  • Prometheus 的指标存储,展示,报警等功能与知乎已有系统重合,整体替换风险较大,所以未做考虑。
  • Sysdig 是一个将各种调试工具集成在一起快速诊断应用行为的方案,但是不适合做常规指标监控使用。
  • 我们采用了 cAdvisor 作为容器指标收集工具,并根据业务需求对 cAdvisor 进行了定制开发,实现了容器指标与已有监控系统的整合。

InfoQ:知乎是如何实现的 Docker 及 Docker 集群的监控呢?

张阜兴:我们使用 cAdvisor 收集容器指标,存入 Graphite,前端使用 Grafana 展示,通过自研报警系统 Halo 发送报警。

具体监控指标分为如下几类:

  1. 业务容器实例监控:容器的 CPU、内存、网络、磁盘;
  2. 业务容器组监控:容器组内容器重启次数,容器组内健康容器比例等指标;
  3. 平台层面监控:Mesos 集群指标,Docker 进程及附属组件状态等监控;
  4. 服务器层面监控:服务器的 CPU、内存、硬盘、网络等指标。

监控的意义在于及早发现问题,要避免和减少监控对服务的影响。作为一个 DevOps 式的平台,应该将合适的监控报警发送至合适的人员,比如业务层面的指标会通知业务开发人员处理;而平台和服务器层面的报警发给平台维护人员,同时还应该设置合适的报警阈值,避免无效报警带来的干扰。

InfoQ:能否说明当一个 Docker 容器服务发生故障时,平台的处理流程?

张阜兴:对于在线调用的 RPC 服务,一个容器发生故障时,服务反向代理 HAPrxoy 会通过健康检查发现该容器故障,并将流量转发到其它容器;同时 Mesos 探测到容器故障后会在服务发现上解注册该容器,并在集群中重新启动该容器:整个过程都是自动完成的。

InfoQ:自动扩容的流程又是怎样的呢?

张阜兴:用户开启了自动扩容功能后,监管进程会定时采集应用容器指标,如 CPU 利用率,根据一定算法设置合适容器数目,进而完成自动扩容或者缩容。在实际应用中,为了避免定时间隔的滞后效应和负载的震荡,一方面我们会控制定时间隔,另一方面我们采用了“快增慢减”的策略,在负载升高时快速的增加容器,在负载降低时缓慢的减少容器。

InfoQ:对于 Docker 日志处理,你们采用的是什么技术栈呢?

张阜兴:Docker 日志处理分为两部分:

  1. 业务日志由进程直接写入 Kafka,其他组件通过订阅 Kafka 实现更丰富的日志处理。例如,使用 Flume 订阅 Kafka,并将日志写入 HDFS 和 ElasticSearch。
  2. 容器的标准输入输出则通过 json 文件写到本地磁盘,从而在进程异常时候,能够通过 Mesos 提供的 url 获取故障信息。Mesos 可以定时帮助我们清除过期容器日志,不用担心磁盘空间占用的问题。

InfoQ:在整个 Docker 平台的实践中,两位有什么感触最深的经验或者建议可以分享给其他的 Docker 使用者们?

林晓峰:Docker 作为一种容器技术,为企业提高产品研发效率和改善基础设施提供了新的思路和方向,应该是作为一个组件融入到企业整体的研发体系中,而不是“革现有研发体系的命”;引入 Docker 让某个解决方案变得优雅,而不是为了 Docker 而 Docker。实践 Docker,应该在充分理解业务需求和现有基础设施后,找到适合自己的 Docker 的使用姿势,这样才能真正让 Docker 技术在企业内落地,并服务于业务,实现 Docker 的价值。

张阜兴:在平台搭建过程中,由于 Docker 本身还在快速发展,不可避免的会存在一些不稳定因素,需要通过上层的容错机制来降低影响

InfoQ:非常谢谢两位接受采访,同时很期待张阜兴在全球容器大会即将带来的分享!


感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016 年 7 月 26 日 23:058746
用户头像

发布了 58 篇内容, 共 37.6 次阅读, 收获喜欢 12 次。

关注

评论

发布
暂无评论
发现更多内容

随手记备忘录的好习惯

changyou

很不幸,自动化测试永远只能是必要非充分条件

刘华Kenneth

DevOps 敏捷 自动化 测试 金字塔

知乎开发了一个搜索引擎

红泥小壶

搜索引擎 百度 知乎

敏捷开发 | 张三与需求管理

Worktile

敏捷开发 需求管理

终极 Shell

池建强

Linux Shell

漫谈哲学与编程

keelii

编程 哲学

浅谈负载均衡

Damon

Java 负载均衡 Kubernetes 微服务架构 Spring Cloud

理性主义和实证主义

王泰

理性主义 实证主义 哲学 软件工程

小论互联网项目管理

南方

项目管理 互联网 个人成长 碧海潮生曲

敏捷(组织)转型的6个准备条件

Bob Jiang

团队管理 敏捷 组织转型

基于Kubernetes的多云和混合云

倪朋飞

云计算 架构 Kubernetes 微服务架构 Service Mesh

写作平台使用感受

小天同学

产品 体验 反馈

Zoom的加密算法,到底有什么问题?

范学雷

算法 编码习惯 产品设计 安全 编程语言

最近的一些人生感悟

小智

人生 哲学

程序员陪娃漫画系列——修龙头

孙苏勇

生活 程序员人生 陪伴 漫画

Facebook在用户增长到5亿时的扩容策略

Rayjun

团队管理 扩容

软件工程的史前时代 -- Therac-25 事件

王泰

质量管理 软件工程 软件危机 软件测试

软件世界中的个人英雄与团队协作

王泰

团队管理 软件工程 团队协作

「超级右键」

非著名程序员

macos 程序员 效率工具 软件 Mac

死磕Java并发编程(6):从源码分析清楚AQS

七哥爱编程

Java Java并发 并发编程 AQS

在谈判中,你有哪些属于自己的独特的方法和技巧?

Yolanda

揭秘|为何程序员们能一直保持高收入?

丁长老

学习 程序员 写作 高薪

有关Kotlin Companion 我们需要了解到的几个知识点

王泰

Java 编程 kotlin 编程语言

加班能解决交付的期望么?

拖地先生

项目管理 领导力 管理 时间管理

Disruptor为何这么快

Rayjun

Java Disruptor

克制文章长度

changyou

Java并发编程系列——线程

孙苏勇

Java 并发编程 线程

如何阅读源码?

武培轩

Java 源码 面试 进阶 后端

聊聊苹果公司技术部门的宫斗和冷战

赵钰莹

程序员 外包 apple

我敢说 80% 的程序员都掉进了「老鼠赛跑」的陷阱

非著名程序员

读书笔记 程序员 程序人生 提升认知

回"疫"录(2):不知者无畏

小天同学

疫情 回忆录 现实纪录

从Docker运维看知乎容器平台的优雅整合-InfoQ