华为工程师预测十年后的Kubernetes

钟成 / 华为高级工程师

嘉宾介绍：Zlog 日志函数库作者。从 2014 年开始设计研发容器集群和产品，目前致力于 Kubernetes 的性能和可扩展性优化，以及 PaaS 产品形态的探索和设计。

大家好！非常感谢才云给我提供机会，来到技术论坛和大家分享一下十年后的 Kubernetes。大家听到现在应该比较累了，我想这应该是一个比较轻松的话题。我今天想谈的其实是一个比较偏轻松的话题，也是一个比较长远的话题。再过十年之后，Kubernetes 这个项目或者这个生态会往哪个方向发展。

目  录

先自我介绍一下，大家对我不太熟悉。我是 Zlog 的作者，以前写过一些开源软件，个人也喜欢在社区里玩，然后物理系毕业，对中医、云计算、人工智能都有一定的兴趣，喜欢折腾各种软硬件系统。目前在华为搞 Kubernetes 和 Etcd 相关云计算产品，我做 Kubernetes 已经有三年了。今天我分享的话题希望从三个方面谈谈 Kubernetes 这个生态的后续的发展方向，包括通用系统、人机接口、互联网产品。

通用系统

开发者角度：当前的分布式系统研发过程首先，我想提一个问题，现在 Kubernetes 非常火，十年之后，它会怎么样？ 我说的这些东西可能都是扯淡，不代表公司的看法，仅仅是个人想法和思考。

我想谈的话题就是从开发者的角度来看，现在分布式系统的研发过程。现在分布式研发过程比较长，作为一个开发者，要做一个分布式系统还是很困难。也就是说，这里列了几个步骤，如果要做分布式系统，要做几个拆分。要有一个大的拆分，有的模块是商务，有的模块是做业务，还有审计，还有日志分析等等。模块拆分之后，就要写程序。写完单机程序之后要做测试，测试过程中由于拿不到别的系统的环境，就效果做打桩和集成测试。接下来会部署到真实的线上环境，有一个真实的线上业务进来，会做真实的调试。

调试完之后会做部署上线的发布，发布之后又会是一个系统的工程再往后就是说可能要解决运行过程的问题。前面还只是开发，后面是做运维。要做运维关心的实行更多，要解决配置、流程熔断、授权认证、日志聚合等等，整个过程非常长也非常繁琐。如果我想要知道未来世界到底会怎样发展，很简单不需要思考未来，只要看现在和历史就可以了。整个计算机在发展早期的时候，如果写一个单机的程序是怎样的，那时候就非常简单。我的操作系统就是一个可以编译，可以构建，可以发布的完整系统，这就是一个系统的环境。写完程序以后，在单机上一测试，二机制一执行，执行了就可以跑了。

从这个角度来说，我认为目前的整套生态系统，它在慢慢简化，但万里长征只走了一步。Kubernetes 解决了运行的问题，但并没有解决前面流水线的问题。前面像马道长也 Focus 这个问题，其实整个链上还有很多东西要做。这个系统发展到最后，可能做一个分布式应用，就和现在开发一个单机应用和现在一样的方便和简单。作为开发者来说，随时可以启动在 1000 个节上跑的分布式应用，这是我对未来的想法，中间肯定要经历很多过程。

如果开发系统或者计算机系统往这个方向发展，会到怎样的状态呢？我个人认为它有点像现在的 Serverless，已经在往这个方向走了。它提供的是可以直接执行一些语言函数。对于用户来讲，只要编写函数，直接在分布式上就可以跑。

但当前的 Serverless 有几个问题：第一个问题，依赖于现在的关系数据库，依赖于云平台；第二个它并不是非常通用的标准，现在已经有一个 Serverless 的项目在 GitHub 上，做得也挺好的。但它还是依赖于各个软件平台，并不是通用的操作系统，依赖于各大公司的一个产品。我个人更希望能看到有一种通用的范式，就是任何一个人拿到这套东西之后，可以在 1000 台机器上就可以跑自己的应用，这是我个人的希望。这样带来一个什么问题呢？假定现在这个平台是依赖于各个大的云厂商，这个标准库无法积累，就是一个语言一套东西要慢慢的发展，一定需要积累。就像现在 Kubernetes 正在积累自己的扩展库，现在 Serverless 的发展没法往下扩展。

我认为，容器是一个中间状态，说起来这句话有点不是很合适，但是我还是想讲这句话，容器这个东西做了一个非常好的折中。它在前面的区域级应用和可打包的应用上做了一个非常漂亮的折中。我认为并不是终极形态，如果真的可以直接在所有的机器上跑应用，不用直接打包成一个容器，直接在一个运行器或者是解析器上跑就完了，没有必要再通过容器。这个是我的看法。

现在肯定不可能，在工业界也不可能，不具有可操作性，但我认为未来肯定会往这个方向走。后面是我认为理想中的分布式计算的形态，它可以在多机上直接进行构建部署，测试运行。如果说做这个事情，前面业界已经做了很多的尝试，包括 Golang。或者是一种分布式的编译器，完全可以直接通过这个语言，在各个机器上直接运行，我可以提供所有的工具链的环境。

人机接口

UI及人机交互: pilotage的尝试这是我个人做的关于人机交互的尝试，我启动了 Kubernetes 的集群，我希望在人机交互上做一定程度的改进。大家可以看到，我启动了一个 Kubernetes 的集群，这和前面不一样，我希望在人机交互方面可以进行改进。启动了一个 Kubernetes 的集群，启动了一个 Pilotage 的工具，这个工具可以进入一个 Shell 的环境，然后我可以把 Kubernetes 的资源，全部都在一个文件的树上进行表示。

我进入一个 Name 就可以直接操作下面的资源，这个项目已经在 GitHub 开源了，大家有兴趣可以就扫一下这个二维码，它采用了树型结构，用基本的命令行操作有的资源，包括 Pod，Node，这样就可以直接看到这个容器里所有东西。这样就可以在一台终端里操作所有的资源，这就是我做的一个 Demo 的项目。

后面我会对它进一步深化，就是集成更多的资源或者说提供一些更通用的手段，做一个顶层的 Shell。

UI及人机交互: 手机端操作及包依赖另外的想法是服务端的软件一般都是基于命令行操作，但我认为因为有很多数据要填，发展到最后肯定会类似于手机的 APP 一样，可以通过像手机 APP 拖动进行安装和卸载的方式，就像苹果的操作方式进行安装了卸载。因为手指的习惯更符合人的自然习惯，现在我们花了很多时间，填了很多参数，搞了很多包，把这个系统搞得很复杂，今后肯定有很好的方式做这个事情。

实际上，苹果做这套系统有一个前提，底层有一个比较好的包管理工具。这个包管理工具是传统的 Linux 的 DEB 或者是 Apt 的工具，我觉得这个工具非常好。现在的社区包就是 Helm，是静态的依赖，它有点类似于 Windows 安装方式，就是把所有的东西打到一个地方，把技术栈上的东西打到一个包上面进行部署。这样有一个问题，这不符合分布式的习惯，运行是互相依赖的。比如说有一个数据库，A 技术栈要用，B 技术栈也要用，打两个包，我会把两个后端数据放在同一个地方。现在还缺乏一种语言或者工具描述这种关系，就是它展现的是一种运行式的依赖，这个东西有点类似于现在Linux里的 SystemD，可以动态的展示所有的关系，可以看出每个服务的启动时间。

安装方面没有什么改进的空间，Docker 本身就可以分层，Charts 我觉得安装依赖没有可以做一些尝试和探索，但这还是初步的想法，我还没有仔细考虑过这些问题，这里面有很多的空间可以做。

互联网产品

接下来我想谈谈这个平台本身的命运。这个平台或者一套操作系统，命运取决于到底有多少人使用它的目前对企业应用或者是微服务类的应用，已经有一些固定的范式，想迁移上来比较困难，传统都比较喜欢用虚拟机的方式进行操作。包括阿里云，我和他们交流过，他们把容器做成虚机，几个容器之后就直接登录到虚机，也是张磊所驳斥的方法，里面写一个 SystemD 就直接在上面监控。

但有很多传统的应用或者已经成熟的应用想迁过来很难，我认为为 Kubernetes 这个生态系统肯定是面向未来的，如果它想发展壮大，一定要拥抱新的应用、新的产品。这些新的应用和新的产品，可能是 AI，可能是大数据，这可能是未来的发展趋势。

微软的 Windows 为什么会成功，是因为有了 Office 这个工具。用户用得好，就会带动平台的发展。对 Windows 来说是 Office，对 Linux，就是 PHP 或者是 Apache 这样的 Web 服务器，让 Linux 得到壮大。对 Kubernetes 系统来说，AI 或者是大数据会成为将来的主流，带动这个平台的发展。

作为开发者和程序员，编写程序的时候，虽然现在还没有这个环境，但可以考虑，不要把思想局限在单一的服务器上，可以去考虑未来的分布式应用，这个应用本身就是分布式，怎么设计它，实现它。可以做新的程序，和以前的程序完全不一样，充分利用现在大规模并行计算能力，因为现在的规模越来越大，各个行业没有办法完全解决这个问题，这是我的观察点。

其实今天我的演讲比较简单。后面有时间可以开放性地讨论一下。

内容来源：2017 年 10 月 15 日，华为高级工程师钟成在 “首届Kubernetes 中国用户大会” 进行的《10 年后的 Kubernetes》为主题的演讲分享。「K8sMeetup 中国社区」经演讲者审阅授权发布。