酌一杯云之酒，以开源佐之 ——专访灵雀云陈恺

虽然我早就和灵雀云有了联系，也有好几位朋友在灵雀云任职，不过作为国内新锐云原生厂商灵雀云的创始人之一的陈恺，我之前并没有直接接触过。虽然我们是初次相识，但是在聊到了开源，聊到云技术，我们以云做老酒，以开源为佐酒菜，很快就俨然如同老友般进入了旁若无人的状态——旁边的朋友被我们暂时性忽视了，虽然这张合影就是她帮我们照的。 😀

滥觞始于云计算。

缘起

陈恺和左玥等人在创立灵雀云之前，他们都曾在微软 Azure 从事云计算领域的专业研究。回忆起那时候，陈恺说，那时他们也在想象云里面的应用应该长什么样子，设计最早版本的“云服务模型”、“云服务运行时”，而现在回过头看，其实云计算的发展已经千差万别。

2013 年 Docker 出现以后，左玥和陈恺他们第一时间就意识到容器技术会很有影响力，它重新了定义云技术之后发展的路径，这恍然在他们面前掀开了一个新的时代，于是灵雀云诞生了。

云技术领域发展演变的非常快，事实上，在云计算早期并不能预见到如今的云计算格局。“早期我们尝试过很多东西，总的想法是觉得容器就像是一种轻量级虚拟机，一种新的虚拟化技术。就像虚拟机需要虚拟机平台去作为它的管理平台一样，容器也需要一个容器云平台，所以我们早期想做的就是容器云平台，这一点一直没变，现在也是在做企业级的容器平台。”陈恺说，“我们最早的技术选型是 Mesos 技术栈，经历了几次大的改变，包括从 Mesos 转到支持当时的三种主流的调度系统，然后开始倾向于Kubernetes，到最后全面转向 Kubernetes，以及最近在架构上和 Kubernetes全面对齐，把我们的平台做成一个 Kubernetes 原生的平台，技术上一直在做升级。”

云原生吞噬一切，Kubernetes 编排一切

不知不觉之间，云原生已经吞噬了整个世界，如今，云原生已经是技术界最时髦的词汇之一。而应运而生并推动了这一切发生的云原生计算基金会（CNCF）也在不同的时期、不同的场所，对云原生做了不同角度的解读。那么作为一家很早就涉入云计算领域的新锐力量，陈恺对云原生的理解是什么呢？

陈恺说，“CNCF 旗下涵盖这么多云计算的技术、产品和服务，所以它对‘云原生’的定义必然会比较宽泛，但的确，‘云原生’不是一个特定的技术或者一种方法，很难把它精确的定义，也不应该把它和具体的技术对等，比如说把它直接跟 Kubernetes 挂钩，跟 Kubernetes 没关系就不是云原生？跟 Kubernetes 有关系就叫云原生？这两者都是不对的。”

他接着补充说，“我对云原生定义的观点也是比较宽泛的，（云原生）就是让应用能够最大化的释放云计算生产力的一系列的思维方式、最佳实践和技术体系，这里的关键词是让应用去释放云计算最大的生产力。这是关键。所有的云原生我觉得都是首先应该围绕应用的。什么叫‘云原生’？主要是以应用为中心的。‘原生’这个名字看起来起的不是很好，听上去似乎是只有在云上生出来的才叫‘云原生’，或者只有在公有云上才叫‘云原生’，并不是。关键不是说你在哪里跑你的应用，而是你是不是能够释放云的生产力——广义的云的生产力。”

在容器编排市场尚三分天下的时候，很多容器服务商都同时支持三种主流的编排系统，当时有一些观点认为这种三分格局会持续比较久，然而 Kubernetes 迅速崛起，很快就一家独大地统治了容器编排市场。

陈恺说，“我觉得当时 Kubernetes 可以很快的从编排之争当中胜出，并没有那么让人吃惊。为什么我们比较早的时候就开始往 Kubernetes 发力？其实第一个触发的点比较偶然。那时经常会有人问起三种容器编排系统各自的优势是什么？我们做了一些研究，业界有一些对比，当时我印象比较深的是一个细节，我觉得这才是关键——有一项对比的是基于这三种技术有哪些商业版？基于 Docker Swarm 的有一个商业版 Docker EE；Mesos 有一个商业版 MesosPhere；基于 Kubernetes 有好多商业版——这是本质的区别。这一点对它们的社区的发展速度和后续影响很广，因为它是开放式的治理。Kubernetes 虽然是谷歌发明的，但是它是开放式治理，背后有很多商业版。如果从开源软件本身社区发展角度看，很关键一点是上面有多少商业版，商业版越多说明从开源软件里面可以获利的公司越多，这样就有了正向的良性循环，会有更多资源投进来，社区里面参与的人就会更多，最后的发展会更好，生态会很繁荣。当时从这一点我们就觉得这个生态肯定会赢。”

Kubernetes 一统容器编排市场的今天，业界一些专家对此有所忧虑，担心这种垄断会形成市场压制。从长期来看，如果 Kubernetes 的发展会形成类似 Android 一样的巨头化，那么作为下游厂商，灵雀云是如何看待和应对这种发展变化的呢？

陈恺说，“回到垄断这个问题，如果是商业软件的话会有垄断这个问题，如果是开源软件的话，它的治理模式有可能是封闭式的，也有可能是开放式的，而 Kubernetes 是一个开放式的治理模式，会有一些厂商有更大的影响力，但不是被一家完全控制，所以我觉得从这个角度来说，谈不上垄断，更多的是一个标准。它可能更多像 Linux 而不像是 Android。从标准的角度来说，肯定是利大于弊，而且是远大于弊。因为有了标准，大家都围绕着标准做投入，风险就大大降低，可以放心去投入，也就会有越来越多的技术厂商会向它靠拢。”

灵雀云的 Kubernetes 生态

灵雀云在围绕 Kubernetes 生态方面也做了自己的发行版，他们是如何在符合 Kubernetes 标准的基础上形成差异化的服务和产品的呢？

“Kubernetes 发行版首先必须是跟 Kubernetes 兼容的。在 Kubernetes 上可以增加各种各样的能力，但它本身的第一属性一定是一个真正的 Kubernetes。如果为了做差异性，把它做得不像 Kubernetes，不兼容会是个很大的问题。”陈恺说，“我们走的比这个更深一步，我们的 ACP 2.0 是把整个平台都做成 Kubernetes 原生的，因为 Kubernetes 本质上是声明式 API 加上基于控制器模型的架构设计范式，容器编排相当于它的一个副产品，是它基于这个架构的一种应用，当然也可以把这种架构应用到对任意资源的编排。前一段时间有一篇很多人转发的《Kubernetes 编排一切》的文章，讲的就是这个事情，它不光可以用来编排容器，可以做各种各样的事情。我很赞同这个观点。”

灵雀云是从 2017 年底的时候决定这样做的，当时的做法是一些新的产品开始在新的架构上做一些实践，比如 DevOps 平台、基于 Istio 的 Service Mesh 等产品，完全基于新的架构来做。今年年初，灵雀云认为所有方面都成熟了：第一，方向肯定没问题，Kubernetes 编排一切；第二，对如何基于 Kubernetes 的架构构建上层产品有了更多的经验和体会。灵雀云于是把以前产品上的所有功能都逐渐迁移到 Kubernetes 原生架构上，重新融合到统一的架构里面，这就是 ACP 2.0。在此之上灵雀云还做了一些差异化。

灵雀云在这里的技术栈分为三层：

最底层的产品是一个 Kubernetes 发行版，Kubernetes 是一个开源的技术，并不是一个平台，大多数企业做不到直接把它当一个平台用。灵雀云的做法是将 Kubernetes 技术变成一个企业就绪的 Kubernetes 发行版。

再往上是 ACP 层，定位是云原生应用赋能平台。包含有三个子产品：容器平台、DevOps 平台和基于 Istio 的 Service Mesh 产品。容器平台和发行版最接近，但对发行版进行了大量扩展，比如在发行版之上增加了多集群管理和企业级多租户。ACP 把单一的 Kubernetes 集群变成企业平台级的产品，经过了三年多 100+ 企业客户生产环境的考验，而且考虑到更多开发者的场景。DevOps 也基于 Kubernetes 原生，用 Kubernetes 去编排所有的工具，定位是一个开放式 DevOps 工具链集成和编排的平台。

在此之上还有一层是灵雀云新的 ACE 3.0，它的定位是一个企业级的 PaaS 平台，或者用现在更时髦的说法，可以称之为企业技术中台，集成了更多企业需要的其他服务，比如第三方的中间件、开发框架等。它是个完整的技术中台，以容器平台为底座，以云原生黄金三角为核心，其他服务在上面做成一个个插件。这部分主要是和生态合作伙伴合作，国内外的一些最优秀的 PaaS 类服务都可以放在里面，为企业提供完整的解决方案。

云原生之于微服务和 DevOps

我们知道微服务、DevOps 等模式在云原生概念发展起来之前就已经存在，但是随着云原生的发展，似乎给它们注入了更多的活力。

陈恺认为云原生显著地推动了 DevOps、微服务的发展，对于这一现象他还专门用了一个词汇来形容：后 Kubernetes。这是在容器和 Kubernetes 出现之后开始对 DevOps 侧的微服务反过来的助推。

他认为，微服务架构的本质是用运维复杂度为代价去换取敏捷性。企业至少要考虑两件事：第一是否真的有这么高的敏捷性需求，值得用那么大的运维代价去替换，第二，假设你有着敏捷性需求，那么多出来的复杂度怎么办？早期微服务落地会很痛苦，因为大家没有准备好怎么去应付这个复杂度，而且会低估它。这复杂度是未知的，用未知的复杂度去替代已知的复杂度，这通常都是不好的，所以才会有各种各样的治理框架出来。其实它需要底下有一个好的基础设施来支撑它。

容器和微服务天生一对，容器 Kubernetes 的出现，对微服务有非常明显地推动。Kubernetes 作为底层的应用管理平台非常合适，而且很多微服务里面要考虑的与业务无关的能力也可以慢慢推到 Kubernetes 里面去。而进一步，Service Mesh 等其上的技术栈就重新定义了微服务技术栈，微服务治理方式发生了变化，反过来作用到微服务上，形成了新的最佳实践。

因此，要做微服务应该先容器化，才能解决运维复杂度的问题，容器化的服务应该跑在 Kubernetes 之上；如果进一步做服务治理，应该往 Service Mesh 方向走，Service Mesh 是基于 Kubernetes 平台的微服务治理的最佳实践。

云原生之于 DevOps 也是如此。早期大家很多的精力在持续集成上面，比如 Jenkins 最初是作为 CI 工具出现的，而有了容器和 Kubernetes 之后，持续集成变得简化了，最终生成 Docker 镜像就好。重心开始转到部署，转到 CD 上。而且，现在的 DevOps 实践或 CI/CD 通常会把 Kubernetes 作为最重要的部署目标。也就是说CI会围绕容器镜像，CD 会围绕 Kubernetes。这是容器和 Kubernetes 带给 DevOps 的影响，基础设施越强大，对 DevOps、微服务就越有帮助。以 Kubernetes 为核心的基础设施变成新的标准，DevOps 和微服务的一些最佳实践都会围绕它去改变。

源于开源，茁壮于开源

云计算构筑在开源之上，灵雀云的基础设施和服务也构建在开源之上，那么灵雀云是如何拥抱开源和贡献开源的？

陈恺说，“有几个开源社区跟我们是非常相关的，最早的时候是 Docker 社区，现在 Kubernetes 则是跟我们关系最大的开源社区。我们核心的产品是容器、DevOps 和微服务三部分。Jenkins、Istio 等相关开源项目是我们的重点，我们非常重视在开源社区的投入。我们的许多工程师会参与其中，对社区进行贡献，也会开源一些项目，我们在一步一步持续地做这件事情。我们首先会选择一些偏底层的技术或者机制，选择那些有足够亮点，真的被需要的项目和技术开源出来。”

目前灵雀云已经开源了的项目，包括基于 OVN 的网络插件 Kube-OVN，它是把 OVN 的网络和 Kubernetes 所集成的网络插件。现在该项目在国内外都受到关注，也有来自外部贡献者参与。另外一个开源的项目叫 Captain，是一个基于 Helm v3 标准的 Kubernetes 控制器，对 Helm 应用分发进行改进。

后续灵雀云还计划将更完整的东西放出来，比如灵雀云的 Kubernetes 发行版，供社区用户用来管理自己的 Kubernetes 平台，可以达到和使用灵雀云产品接近的体验。另外灵雀云也计划将其 ACP 释放社区版或者开源版本出来。陈恺说，“我们很乐意把它开源出来，因为这是一个标准的产品，我们让它较早期的接触更多用户，也能得到更多反馈，甚至吸收一些外部的贡献者参与进来。”

尾声

我采访过很多技术领袖和技术专家，不过陈恺的这场采访让我有一点不同的感受。一场对话下来，陈恺给我的感觉如同多年的老友一样言无不尽，而他对于我提到的每个话题，都非常认真、仔细的做了阐述，让人感到浓浓的专业技术风格。我想，这就是陈恺的技术初心，也是灵雀云一直以来的风格吧。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。

本文转载来自 Linux 中国: https://github.com/Linux-CN/archive