云原生理念近年来热度高居不下，CNCF（云原生计算基金会）一直致力于培育和维护一个厂商中立的开源生态系统，使云原生计算具有普遍性和可持续性，通过将前沿的模式*化，让这些创新为大众所用。

CNCF 努力构建可持续生态系统，并围绕一系列高质量项目促进社区的发展，这些年来的迅猛发展有目共睹。在6月25日的 2019 年中国 KubeCon + CloudNativeCon +开源峰会上，我们采访了 CNCF TOC 成员、阿里巴巴的资深技术专家 Xiang Li，跟着他一起了解 CNCF 的最新动态和发展动向，走进阿里巴巴规模的云原生，进一步探讨云原生的普及和发展问题。

嘉宾介绍
Xiang Li 是阿里巴巴的资深技术专家。他负责阿里巴巴集群管理平台，帮助将 Kubernetes 应用于整个阿里巴巴集团，曾创建 etcd 和 Kubernetes 操作模式。

访谈实录
1.首先，恭喜您成为中国首位入选 CNCF TOC 的成员，那么作为 TOC 的一员，您重点关注的领域有哪些？

我先简单介绍一下 TOC 的职责。

首先，CNCF 基金会实质上以项目为中心进行运作，目标是为了让 CNCF 吸纳更好的项目，做出更多创新，进而通过这些项目吸引更多最终的客户群体。有了更多的客户群体使用 CNCF 的项目之后，厂商会把这些开源项目组合成产品或者云服务，以更低的成本和更高的效率供客户使用。

CNCF 希望通过项目连接基金会、开发者和厂商。因此，TOC 的核心目标是在项目本身，我们希望收集最好最适合基金会云原生理念的项目，而我的主要工作也是寻找最好的项目。

CNCF 的每个项目会被分为 sandbox、incubation 和 graduation 这三个阶段。我最近正在对接一个处于 incubation 阶段的项目，叫作 TiKV，主要在流程和规划上帮助他们，以推动项目从 sandbox 进入 incubation。

sandbox 都是处于早期发展阶段的项目，我们会去寻找一些有潜力的项目，为他们提供建议，促使其进入 sandbox。CNCF 基金会本身并不像 Linux 基金会已有十几年发展历程，它现在仍然还需要定义一些东西，比如 sandbox 项目到底意味着什么？进入 sandbox 的流程又是如何？从 sandbox 进入 incubation 该怎么做？它的标准是什么？定义这些也是 TOC 的责任，我也在这方面投入了比较大的精力。

还有，如何分配 CNCF 有限的资源来保证基金会能够以项目为中心运作，如何能让 CNCF 既有创新能力，又能在吸纳进大量项目的同时保持它的先进性、中立性以及云原生理念，这些也都是我们关心的问题。

2.刚刚提到的 TiKV，它们进入您视野有什么小故事或者特别的契机，他们有什么不一样的地方吗？

首先，它们都属于开源领域的项目，跟我们之前接触的项目有互相交叉的地方，也有很多技术交流与合作，所以我对这个项目非常熟悉。第二，这个项目的团队成员是华人，所以我更愿意花精力帮他们在 CNCF 和开源社区中推进。

当然最重要的前提条件是我认可这个项目的前景和发展方向。

3.除这个项目外，方便再和我们分享一下 CNCF 技术监督委员会的其他的职责或者最近在做的一些相关工作或计划吗？

最近在做的另一件大事是我们在 CNCF 里运营一个名叫 CNCF SIG 的组织结构，即 Special Interest Group。

因为 CNCF TOC 成员现在只有九个人，而 CNCF 目前涉及将近 10 个不同领域，我们九个人的能力有限，所以希望能够把 CNCF 的技术组织扩大。

目前，我们已经制定完了专项小组的流程，正在尝试把每一领域的专项小组建立起来。各领域的专项小组能够更好地协助我们寻找各领域中有前景的项目，帮我们一起去审核项目的规划、健康状况，将新的优秀项目引入 CNCF 之中，同时也有助于审核已有的项目。

我主要负责 SIG Storage 存储领域的一个专项小组。SIG 的设立相当于 build another layer 使得 CNCF 技术组织的人力更充沛，毕竟 CNCF TOC 成员更多地在眼界的广度上占优势，而 SIG 能帮助我们在各个领域中更深入地研究项目。

4.据了解，您所参与的 etcd、rkt、Prometheus 等项目都先后进入了 CNCF，请问入选 CNCF 的开源项目有哪些要求？是否会有明确的指导准则？

这些其实我们已经梳理过了，比如 sandbox、incubation 和 graduation 有一些评判标准，但我们也在不断尝试这些标准是否合理，并且不断地迭代。因为个别标准可能过于松散，从而导致有项目进入时，TOC 成员却认为不合标准，不过项目团队却认为自己达标了。

但从另一方面来讲，我们也不认为这些标准能够非常清晰，因为 TOC 成员也会有主观的判断，毕竟不可能所有评判都是绝对客观的，我们也在寻找主客观之间的平衡点，尽量缩短主观判断的量。其实根本原因主要还是人力的瓶颈存在。

5.CNCF 收录的众多项目，在应用开发整个流程中有没有覆盖不到的环节，或者相对比较薄弱的环节？

其实整个 CNCF 是从基础设施（infrastructure）层往上发展的，到目前为止 DevOps 层的内容比较多，但 CNCF 现在没有覆盖研发流程。

第一个方面，从历史角度上来讲，我们是从基础设施（infrastructure）层往上做的，还没有发展到最上面这一层。

第二个方面，我们也在考虑是否介入研发层。纵观整个 Linux 基金会，CNCF 有一个刚成立的兄弟基金会叫 CD 基金会（Continue Delivery Foundation），CDF 是从研发的后半段入手，主要研究的是代码提交之后如何构建（build）、交付（deliver）。CDF 更接近研发侧，CNCF 更接近 DevOps 和基础设施（infrastructure）领域，现在暂时存在这个边界。

综合而言，目前 CNCF 还是更专注于基础设施（infrastructure）层，在 DevOps 上，还有很多问题亟待解决，比如说最近非常火爆的 Service Mesh，这方面 CNCF 应该怎么投入？CNCF 上还有许多项目，比如 LINKERD、knative 和 serverless，如何把 Service Mesh 本身属于 CNCF 这一层的 adoption 提高，也是我们需要集中思考的问题，包括之前 CNCF 也有 serverless 的工作组。

总体来说，组织内的人力有限，我们希望先把自己范畴内的事情做好，包括云原生（Cloud Native）理念的推广等等，再去思考怎样覆盖研发流程等环节。

6.云原生应用开发有一个经典的 12 要素原则，当下它有怎样的发展呢？

12要素原则是当时为了更好运行 Heroku 这样的 PaaS 而提出的，根据它来创建应用，从而能够更好地被运维和管理，有更好的可检测性、可运维性。当年提出这个观点是为了适用于当时的平台上，但随着平台的本身的改变，12要素也有一些可能随之变化的地方。

不过目前为止12要素本身还是一个比较好的指南来引导大家如何建立一个无状态的应用。我认为目前业界还是可以以它为标准和原则，如果未来有更好的理念产生，我们再加以推广。

7.从去年到现在，云厂商和开源项目之间一直存在各种利益纠葛，有些项目甚至为此修改开源协议以防被云厂商“滥用”，但这样做无论对社区还是市场都有损害。可以和我们分享一下您对此的看法吗？

首先开源项目分为两种，第一种是纯社区驱动的，或者说是纯基金会驱动的开源项目，他们并没有利益诉求，比如 CNCF 很欢迎云厂商采用一些技术放在云上贩卖。

刚才我也讲到，CNCF 旨在发掘好项目并让用户使用，让厂商提供服务。那么这些用户、厂商为了了解项目会买门票参加会议，促进基金会的发展，厂商也会更愿意投入人力物力来维持项目，这个轮转是可行的。

这种模式把项目交付给基金会，因为上游的迭代速度快，尤其是好的项目，通常是快于下游的，厂商更愿意持续使用这些项目而不是去 fork 它。今年 CNCF 有两百多个会员加入，很多厂商愿意投入精力推进 CNCF 的项目，这是因为我们在 containerd、etcd 各种生态项目中做了很多工作，让项目更成熟更完善，让云上的用户能享用到原汁原味的 Kubernetes。

所以我认为云厂商和开源项目的争执并不存在本质矛盾，两者有良好的合作模式。

另一种开源项目的边界不太清晰，有需要协调的点，这些开源项目的支持公司是独立个体，比如 CockroachLabs 或者PingCAP 打造的开源数据库，公司需要通过他们的开源产品来赚钱。

如果云厂商也利用这个开源项目包装成产品来获利，两者就在商业模式上产生了冲突。如何解决这个冲突，站在阿里巴巴的角度，我们愿意跟这些独立公司合作，帮助他们在阿里云上把产品卖的更好，扩大用户基础。只要他们能利用好阿里云的资源，为阿里云带来更好更优质的客户。

之前 elastic 跟 AWS 由于利益诉求的冲突而导致一些争端，但不管是通过 license 的形式，还是跟云厂商合作的形式，冲突是可以化解的。

从本质上来讲，云厂商和开源项目应该是共赢互利的关系，长远来看 AWS 最终会愿意改变态度。开源的公司只是利用开源模式以更低的门槛去吸引客户，开源和闭源的生态合作伙伴在本质上并不矛盾。

当然，如何跟持有开源项目的公司在开源模式上有更多良性的商业合作，我认为是云厂商亟待解决的问题。

8.您作为 CoreOS 最早的工程师之一，见证和参与了云原生的兴起，您觉得云原生近几年的发展和演变是否和你预想中的吻合？

是一致的，当时我们认为容器是最好的一种使应用、交付标准化的模式。我们可以把容器类比成集装箱，集装箱让运货体系标准化起来，它把货物从轮船到汽车最终到卖场的环节无缝衔接起来，使得货物在世界各处流通，大幅降低运货成本并提高了联动性。

容器就是这样的概念，那么有了容器之后，自然要去建立码头，把东西都灌进容器里，围绕容器建立生态。在今天，云原始就是围绕这个思路慢慢建立起来的。容器只是一个载体， Kubernetes 是支持容器在云的不同虚拟机中移动的基础建设，增加了它的灵活性，甚至在混合云（hybrid cloud）、多云（multi cloud）的环境下都能装着它的容器在不同云上跑。当容器标准化之后，可观测性也随之变得标准化，运维模型也实现自动化。因为标准化之后就打开了自动化的市场。

容器是我们的载体，我们需要建立很多的系统来把这个红利释放出来，最终带来价值的是自动化、标准化。未来我们也希望通过云原生能孵化出更好的平台，改变研发侧的一些习惯，并把这个价值真正贯穿到整个研发流程中。

9.对于云原生的未来，您是如何的看待的？您觉得云原生此后几年会有怎样的演进，或者说会朝哪个方向演进？

第一个事情，从基础层来讲，容器和 Kubernetes 虽然得到广泛认可，但在国内的采用率并没有想象的那么高，所以在未来三年内，尤其在国内市场我们还是要培养土壤、建设土壤。阿里也开设了云原生的公开课，我们参加 KubeCon 也是为了分享阿里巴巴内部的实践经验。我们想证明云原生理念、它的基础体系是扎实的，也希望大家能认同这个理念，在上面建立新的 platform。让 Kubernetes 的"for platform builders”理念更深入人心，提高容器和 Kubernetes 本身的采用率。

第二件事情是我们希望达到容器本身的目标，让应用能以更标准化的模式交付。

大家来做一个对比，今天我想在 iPhone 上装一个 app，点“安装”键直接就安装了，想升级 app 在苹果的客户端点“升级”键，iPhone 上的所有 app 就能有序升级了。但在服务器端（server side）的交付市场完全不是这样，安装和升级必须要去现场操作，升级中可能还会遇到各种环境不一致的问题需要修复。企业软件交付的成本非常高，跟 iPhone 应用交付的成本完全无法比较。我们认为原因在于， iPhone 是一个统一的硬件平台，iPhone 上的应用（application）是一个统一的运行环境，在传统 IT 交付市场不存在这样标准的条件。但当我们换到云原生上后，硬件是跑在云上的，都是虚拟化的、标准化的；操作系统也被 Kubernetes 云原生的操作系统标准化了；软件的载体是标准化的容器。只要我们把这个流程定义好之后，就能像安装 iPhone app 一样在服务器端（sever side）安装软件，从而大幅降低人力成本和交付成本，整个企业软件开发市场都会有更蓬勃的发展，这也是我们未来的发展方向。

10．目前来讲 Kubernetes 对于技术能力不是很强的公司门槛略高，特别在中国上云率并不高，很多人还没有接受上云的概念，就已经迎来了云2.0时代了。那么在您看来在厂商那端，像阿里，在中国这样的纵向的市场更多地需要做哪些工作？

第一点，我们在做的一件事就是提高抽象降低门槛，未来可以直接跳过云的 1.0 时代，只需学习 Kubernetes、容器这些抽象概念，来降低新一代云原生开发人员的负担和成本。当然也要转移一些老的东西，这就需要服务厂商提供一个 PaaS 来完成。这个演进可能是痛苦的，但先进科技总是要 takeover the world。

回到集装箱那个例子，最开始厂商把集装箱做出来，建立码头和其他基础设施，工人使用集装箱运货，这中间必定存在学习过程，也会导致一些人工作方式的改变，但最终效率会得到极大的提升。这些都不可避免，我们能做的就是降低门槛，让大家更顺利的完成演进。

第二点，我认为 Kubernetes 本身定位是 for platform builder，有一些更高端用户会直接使用 Kubernetes，大部分用户还需要我们提供更多的 PaaS 平台、SaaS 平台建设在 Kubernetes 上，但我们也希望最上面的平台能够认同云原生自动化、标准化的理念。

未来每个领域都会有相应的平台，我希望这些平台还是基于 Kubernetes，因为 Kubernetes 本身是一个大的基础设施（infrastructure），最下面这一层如果统一，我们的想法就能够传导上去。同时，我们也会弥补上层的缺口，比如我们现在和 IoT 团队合作云原生+IoT，就是为了把 IoT 的垂直领域云原生化。新的领域也是契机，我们先把擅长的领域做好，然后再进行下一步演进。