标签 灵雀云 下的文章

在云原生技术实践峰会召开前夕,匆匆奔赴北京的我,见到了刚刚从美国飞回来,却毫无时差之扰的陈恺——灵雀云的 CTO。

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

滥觞始于云计算。

缘起

陈恺和左玥等人在创立灵雀云之前,他们都曾在微软 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 编排一切》的文章,讲的就是这个事情,它不光可以用来编排容器,可以做各种各样的事情。我很赞同这个观点。”

陈恺在云原生技术实践峰会 2019 上演讲

灵雀云是从 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 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访,将为大家介绍中国开源领域中一些积极推动开源,谙熟开源思想的技术人,并辨析其思考、挖掘其动因,揭示其背后所发生的事情,为关注开源、有志于开源的企业和技术人标出一条路径。

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