在 12 月 22 日 ECUG 的下午场 ,七牛云容器计算部技术总监袁晓沛为大家带来了主题为《基于 K8S 的 DCOS 之路》的精彩分享,向大家介绍了七牛容器云目前 K8S 的状况和产品思考。
同时,他在会上讲述了如何通过七牛公有云业务容器化的操作实践,组建 K8S 翻译团队,对《Kubernetes in Action》这本书进行落地的翻译。
以下是演讲内容的实录整理。
大家下午好!我是七牛云容器计算部技术总监袁晓沛, 我今天想分享的是七牛云基于 K8S 的 DCOS 之路,结合一些实践经验,讲一下我们在其中做的事情和产品层面的思考。
我今天会先讲一下七牛云内部业务容器化历程,然后讲基于 K8S 的 DCOS,七牛云在做一个更强大的 K8S 发行版,它体现在三个地方:一是底层技术的稳定性。做一个更强大的 K8S,技术稳定性是用户第一时间关注的;二是功能的扩展性。如果一个系统不满足需求时,就要考虑它的扩展性怎么样,能不能基于开放性接口实现;三是易用性。K8S 是非常复杂的系统,如何保证它的运维、使用非常简便,让终端用户可以快速入门。最后,会简单介绍 K8S 周边的生态,包括上下游及应用生态,以及应用生态丰富性。
七牛云内部的容器历程
七牛云从 2014 年开始做容器,当时启动的项目叫 QCOS,它的全称是「Qiniu Cloud Operating System」。当时我们通读了 K8S 的设计草案,我们认为自己有能力做这样一个系统。然后我们从零开始自研了一套容器集群调度管理系统,这个事情做了两年。2016 年底时再回头看,发现一个容器集群调度管理系统要做的事情非常多,要包含 CPU 和内存调度(计算力调度)、网络管理、存储插件、应用相关处理(日志、监控、告警),这是一个非常大的系统,几乎没有几个公司有能力从零开始做这件事情。当时来看,唯一的可能性是谷歌,因为他们有一套 BORG 服务内部多年,而 K8S 是由 BORG 系统设计理念演化过来的。于是我们在 2016 年底决定全面转向 K8S,而且 100% 兼容 K8S。
现在是 2018 年底,我们近两年做的是七牛云内部的 5 大业务 K8S 容器化:最早是测试系统,现在七牛云的测试已经全容器化;第二个是多媒体转码系统,也是全容器化的;第三个业务是七牛云 AI 业务,AI 有大量 GPU 机器,需要基于大量数据集做 AI 学习和训练,所以我们是基于 Kubernetes 之上做了机器学习的平台,我们为这个平台做了很多扩展功能;第四个是大数据,大数据 Spark 业务在我们的容器应用市场上,作为一个应用,让用户可以快速部署。
我们在本季度正热火朝天做一件事情,把七牛云最核心的对象存储业务搬到容器云上,这个事情已初步验证通过,正在切量过程中。到现在为止,七牛云的几大业务线都有大量应用运行在容器之上。从 2018 年下半年已经对一些外部客户输出容器产品,结合七牛云过去五年容器化经验,把我们好的技术、理念、功能打造成产品开始对外输出。
容器化带来了什么
容器化到底给我们业务带来什么?
第一点,员工开心。交付部署效率大幅提升。原本从一行代码的提交到测试再到生产的上线,可能需要几天甚至几周时间,而且上线之后可能会不稳定要回滚,基于容器技术,可以把整套过程用 CICD 和 DevOPS 理念整合到一起,一行代码提交之后,可以让这行代码变更编译成一个镜像自动跑单元测试,跑完单元测试可以跑代码静态检查,也可以加一些自定义脚本,然后集成测试,最后是 CD 持续部署,线上连接起来。发布周期可以从几天、几周到分钟级甚至秒级。这个过程中,最简单的变化是员工很开心,开发、测试、运维,都可以早点下班,不用等到凌晨四点业务低峰时发布。
第二点,用户开心。运维排错效率大幅提升。一个容器平台默认就提供了容器的监控,系统级别 CPU 和内存监控、入口级别的监控报警,甚至日志也可以自动收集起来。一个写得很一般的后端应用运行起来之后,平台都能为它提供一些基础的日志监控,如果业务做一些适配,业务级的监控也可以被收集到,这些整合起来就是全链路的日志监控和告警机制。如果线上出现问题,基于监控日志和告警,可以大幅降低从错误发现到错误解决的时间,降低 MTTR ,提高应用的可用性。应用的可用性提高了,客户受到的影响就会越来越小,本质上来讲是客户更开心了。
第三点,老板开心。因为机器资源的利用率大幅提升。在一个数据中心里可以用一个 K8S 集群来管理所有物理资源,让所有业务在一个计算资源大池子里做业务混部,然后利用率提升了,从原来不到 20% 的资源利用率,最高可以提升到 60%、70% 以上。对公司来讲,降低了企业 IT 成本。从这一点来看,没有老板会不开心。
基于 K8S 的数据中心操作系统
做了这么多事,我们收获了很多好处,然后就在思考我们本质上在做什么事情。本质上我们是在做一个数据中心操作系统。原来机房里一堆机器的管理,本质上是通过机器 IP 再加一个 SSH 端口号,无论使用什么部署工具,都是把一些应用推上去,更改配置,启动这个应用,是通过 IP 地址和 SSH 端口跟这些机器打交道。但有了容器之后,跟数据中心交互的接口完全发生了改变。我们使用编程化接口,操作和调度数据中心的 CPU 和内存,不用在意业务到底被调度到哪一台机器上,甚至可以用 API 的方式操作日志、监控、报警。所以,我们是在做一个数据中心操作系统。
K8S 已经是一个数据中心操作系统了,而我们是在做一个更强大的 K8S 发行版。
更强大的 K8S 发行版,需要具备什么呢?
我们总结了三点:第一是底层技术的稳定性,商业公司站在背后支持,保证技术是更稳定的;第二是丰富的扩展功能;第三是易用性,对于平台运维来讲是否易部署、扩容、升级,对于终端用户来讲是否容易使用,都是至关重要的。此外,一个完善的操作系统,除了自身功能之外,还需要提供必备的上下游服务和上层应用。
底层技术稳定性方面,我们每天都在迭代。这是我们近一两个月在做的事情,我们在网络模型上,etcd 分离部署,与 K8S etcd 互相不影响,使用 etcd V3 API 作为数据库,性能提升 2 倍;使用 BGP route refletor,关闭 Full Mesh,大幅提升性能。
举例说明,大家可能都不会太关注的点:KubeDNS,社区默认版本性能只有 99.5%,意味着不工作时候可能超过 3 个小时。我们做了一系列改进可以把 KubeDNS 可用性从 99.5% 提升到 99.999%,每个月不可用时间不超过 25 秒。实际上过去三个月不可用时间是 0。
有人可能会问七牛云为什么在这么小的事情上较真,做这么多事情。对容器云团队来讲,每一个组件都是这种心态做优化。因为用户打到七牛云的每一个请求,存在我们这里每一个文件,都是对我们的信任。我们对用户有一个承诺,我们要让系统尽无限可能接近 100% 的可用性。
扩展方面,系统层面针对 Nvidia GPU 监控和调度做了优化,定制调度器确保 GPU 的调度性能,开发了 K8S 集成 AlluXIO 存储插件,通过这个插件可以让 AI 训练使用 AlluXIO 缓存海量文件。第二,我们在静态本地磁盘上启动了一个新的 Kubernetes SIG,基于这个很多人可以一起贡献代码,把静态本地磁盘供给做好。在网络上基于 vlan/vxlan 实现 SDN,支持二层网络隔离。
这是基于 CLI 的日志自动收集方案。主要原因是一个容器往往需要往多个目录打日志。但按照容器标准,只能往标准输出和标准错误里打日志,这样很难收集扩展多个目录的日志。CLI 是 Container Logging Interface 的缩写,它让整个方案能够对接任何现有的日志方案,比如可以对接七牛云的 Pandora,也可以支持 ELK、Splunk。
这是日志收集方案的使用方式。
作为一个容器平台或者数据中心操作系统,很关键的一点是易用。
平台的运维很关键,很多容器产品关注的是这个产品很好用,但实际上容器平台的运维更难,因为 K8S 管理着整个数据中心,业务大了之后,K8S 平台自身的运维更重要。
第一是部署、扩容、升级的便捷性。我们的目标是 5 分钟部署一个新集群,秒级扩容一个新节点。K8S 是开源生态,开源有很多安全性问题,我们如何在升级新版本时,让当前集群上的业务不会影响,这是一个非常关键的因素。
第二是集群信息可视化,包括宿主机、系统关键组件,L7、L4 入口的监控、日志、告警。如何通过平台监控信息发现机器或者系统组件、入口层面的问题,通过平台快速定位业务问题,这都是集群可视化要做的事情。
第三是常见故障自动化处理,我们实现了一种机制,可以让故障自动探测、一键解决。
这是平台运维管理界面。
这是具有自动化运维处理机制的工具,每一台节点上都会运行这个工具,它能做到自动化探测,插件方式都是自动化探测已知现象,把这些上报到 K8S api-server,采取措施自动修复一些问题。
从用户使用层面讲易用性,我们是以项目为中心,对用户有强大的管控能力。传统项目都是先有虚拟项目再有人,然后是机器和软件。我们完全按照这样的方式管理项目,把 K8S 资源空间当做一堆资源,往项目里添加。项目里可能有项管、运维、测试、开发,每一个不同的人决策权限不一样。
然后是强大的应用编排能力,很多 K8S 平台为了追求编排的易用性而牺牲了兼容性,等用户对这个平台和 K8S 足够熟悉之后,用户可能就会要求平台和 K8S 完全兼容,意味着通过 K8S API 创建的资源必须通过平台显现出来,或者通过平台创建、编排的资源可以通过 K8S API 操作,正向和逆向都可以,所以我们产品 100% 兼容原生 K8S,并且兼容 kubectl。
最后一个是强大的镜像空间管理能力,国外镜像同步、镜像加速、私有镜像托管;C2I:基于代码、单元测试、静态检查,构建可交付镜像;镜像检查,基于一些工具检查镜像,看它里面是否有存在安全风险的东西。
以上是用户易用性上需要考虑的点。
这是用户使用产品的界面,应用编排、应用列表、应用服务编排。
一个强大的数据中心操作系统,还需要一个比较完善的周边生态。持续部署和 Kubernetes 打通,上面可以通过 HELM,右上角是 ISTIO,基于 ISTIO 做流量管理功能,比如灰度发布、熔断、链路追踪,帮我们快速发现问题。
七牛云基于 K8S 实现了常见的数据库中间件服务,包含 MySQL、MongoDB、Redis、RabbitMQ。这些运维工具本质上就是由 Operator 实现的高可用服务,支持一键部署,能做定期备份和恢复,保证数据的可靠性。本质上是把公有云的 RDS 服务搬到 K8S 上,让非公有云用户使用高质量的数据库服务,大幅度减轻 DBA 的工作负担。
这是七牛云当前在 K8S 社区的全球排名,我们排第 26 名。可能会有人问,到底有多少人在开源,我的回答是我们没有一个人专职做开源,也没有把做开源当成很刻意的事情,是在维护 K8S 的稳定性、扩展功能、提高产品可用性的过程中,贡献一些东西。因为我们受益于开源,所以这些改进,新的功能我们都尽量直接贡献到开源。但我们不做三件事情:不去改拼写错误、增加单元测试、改注释。
这是七牛容器云团队和七牛云内部一些小伙伴翻译的一本书,书的名字是《Kubernetes in Action》(中文版购买链接:https://item.m.jd.com/product/12510666.html),主要教我们如何在 Kubernetes 上部署分布式容器应用,这本书的作者是 Marko Luksa,他是红帽 OpenShift 工程师,这本书由七牛云 CEO 老许亲自作序。翻译过程中,七牛容器云团队根据实际应用经验,把这本书翻译得尽量准确,并且通俗易懂。
Kubernetes 是希腊文,本意是舵手,带领一条船到达正确的地方,希望这本书像舵手一样,能在大家学习 K8S 的过程中带来一些帮助。