在 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》（中文版购买链接：item.m.jd.com/product/125… Kubernetes 上部署分布式容器应用，这本书的作者是 Marko Luksa，他是红帽 OpenShift 工程师，这本书由七牛云 CEO 老许亲自作序。翻译过程中，七牛容器云团队根据实际应用经验，把这本书翻译得尽量准确，并且通俗易懂。
Kubernetes 是希腊文，本意是舵手，带领一条船到达正确的地方，希望这本书像舵手一样，能在大家学习 K8S 的过程中带来一些帮助。
（Marko Luksa 在 ECUG Con 2018 的现场分享片段）
关注公众号：七牛云 点击本文文末「阅读原文」，获取
Marko Luksa完整版精彩演讲 DEMO！
（为保证视频及时获取，请将「提交成功」页面截图发送至公众号后台）