两三年前，云原生势头正盛，开始“侵入”各大公司。三年过后，随着云原生 2.0 时代的到来以及落地实际进度的放慢，业内对云原生又有了很多新的了解，对其可为业务带来的理论价值有了更多感触，容器的圈子也经验了一轮洗礼。在各大公司纷纷表示曾经迈入云原生 2.0 时代的明天，咱们有幸能够和 KubeSphere 容器平台产品负责人于爽交换下以后云原生畛域值得关注的技术趋势和落地方向。

容器的圈子开始卷了吗？

K8s 我的项目倒退至今，已成为云计算畛域平台层当仁不让的事实标准，但其复杂性、学习曲线平缓也是不争的事实。于是，咱们在过来三年看到了一众基于 K8s 衍生出的我的项目，试图升高用户部署 K8s 的难度，并且随着开源静止的衰亡，这些我的项目大都抉择了开源的形式经营。相似的我的项目，雷同的经营形式，竞争在劫难逃，难道容器的圈子开始内卷了吗？

“两三年前，的确有用户会找来一堆与 KubeSphere 相似的开源我的项目让咱们提供比拟后果，甚至有些开源我的项目，咱们都没见过。”

现在，CNCF 基金会的云原生全景图曾经相当宏大，涵盖基础设施层、运行时层、编排和管理层、利用定义和开发层以及贯通所有层的平台解决方案、可察看性和剖析工具，并且通过这三年的倒退，很多我的项目曾经从高级版本走向成熟，领有稳固的拥护者和使用者。

“三年前，用户可能须要不少的工夫抉择本人须要的我的项目，现在从开源社区的角度来看，围绕着容器平台的我的项目根本稳固，也有一些我的项目在这三年走向淘汰，用户联合具体的业务场景很容易就能够做好选型。”
从这个角度看，容器的圈子并没有在过来三年逐渐内卷，反而越来越清晰，留下来的我的项目都有了各自的栖身之地，淘汰的我的项目起因各不相同，而开源不易是其中很重要的一项影响因素。

我的项目地址：
https://github.com/kubesphere…

开源，很容易走弯路

“开源这件事件，咱们起初也走了一些弯路。”

从外表上看起来，一家商业公司经营一个开源我的项目仿佛很简略：将代码放到 GitHub 上或者将我的项目募捐给某一个基金会，而后建设社区把有雷同想法的人聚拢在一起，接下来就是用户群体一直壮大，我的项目不断更新迭代，最初胜利毕业或者走向成熟，这套流程看起来十分瓜熟蒂落，但具体到执行层面，有很多问题须要思考：一个全新的开源我的项目怎么让开发者信赖并参加？如何经营开源社区是无效的模式？哪些性能应该奉献给社区？

开源社区通常不是由一个人管制的，基于商业公司经营的开源我的项目状况更加简单。有时候，同一个性能，社区的实现思路和公司不一样；有时候，公司布局了一个商业性能，社区提前做进去了 ……

在 KubeSphere 开源之初，整个团队想的是把代码写好就能够了，起初的经营过程中发现这种想法是有问题的，如果开源之初没有想好指标，只是为了开源而开源，就会导致前面的很多工作无奈失常发展，把代码提交到 GitHub 并不代表开源指标就实现了，如果没有种子开发者的信赖和推广，很难真正做起来，但怎么让种子开发者信赖呢？

“咱们后期和很多开源畛域的资深专家做过沟通。事实上，种子用户们对开源我的项目的接受度十分高，对新的开源我的项目容忍度也十分高，但这所有的前提是你的代码和开源文档都足够欠缺，只有他能够依照你的文档和代码解决理论问题，就会对我的项目产生信赖，从而自发向外举荐。”

尽管种子用户的容忍度很高，但这批人的技术水平也十分高，乱搞必定是不行的，于爽补充道，一个齐备的开源我的项目应该领有欠缺的开发文档、清晰的技术架构图，并且有一个清晰的路线图，违心聆听种子用户的倡议。如果种子用户都没了，转而去孵化前面的小白用户，整个链条就断掉了，必定是做不好的。

过来几年，咱们也看到了一些我的项目的败落，大多是团队没有意识到开源的价值，没有真正弄懂开源，进而导致我的项目的倒退出现负向循环，越做越丧气，甚至成为整个团队的累赘。

现在，KubeSphere 3.1.0 版本已正式公布，该版本蕴含了来自 KubeSphere 社区及企业用户发现的 bug 及提出 的需要，波及到 KubeSphere 前后端各个组件；寰球近 100 位贡献者参加 3.1.0 的开发、测试工作，有集体爱 好者，也有大量的企业用户、开源我的项目参加奉献，如中通、锐捷、马上生产金融、红亚科技、Kube-OVN 等；主仓库 160 多个 PR 提交。在 3.1.0 版本 之后，KubeSphere 小版本的公布频率会更频繁。

“回头想想，做开源我的项目就如同在下棋，而后旁边有很多人在领导你，你不单单是在做一个我的项目，也是在交朋友、做圈子。如果你是纯做商业产品，圈子就会十分垂直，集中在和商业闭环这个圈里的人打交道。”

除了技术的文档层面准备就绪，青云自上而下对开源的认知也让 KubeSphere 从诞生之初就决定走全球化的路线，而不是闭门造车，为此开明了海内沟通形式，并提供了大量英文素材，心愿寰球开发者都能够退出到其中平等沟通，并设置了专门的经营团队负责对接寰球开发者提的问题，治理开发者关系，为开源社区输送对应的文档和材料。

当初拥抱 FaaS 的理由是什么？

基于上述认知，KubeSphere 得以在容器圈领有一席之地，并于近日新增了 FaaS（函数计算）反对。事实上，FaaS 在云原生的圈子里也不是什么陈腐概念，这代表着一种计算模式，能够极致优化资源老本，主动应答波峰波谷，对于特定畛域的开发，它能够极大地开释开发者的开发运维压力。过往几年，咱们也见到了一些互联网大厂在此方面的实际和输入，但对传统企业而言，这还是一个“陈腐事物”。

相较于私有云厂商的一早入局，青云此时开始做 FaaS 会不会有些晚。对此，于爽示意现阶段公开反对 FaaS 次要基于三方面的思考：一是随着容器的遍及，FaaS 的落地难度逐步升高，业内已有许多开源框架可供选择，尽管性能层面还不能齐全满足客户，但从架构完整性角度来说曾经准备就绪；二是客户对此已提出需要，基于 Java 的框架可能更好招人但整个框架给技术团队带来较大累赘，对于中小客户而言，可疾速拼接的业务框架或者是更优的抉择，每个开源框架都有本人的优劣，但在一些私有化环境外面，客户须要借助一个通用性框架实现跨平台的 FaaS；三是青云外部的技术储备曾经足够，并为本次开源筹备了半年无余，次要工作曾经实现。

随着 FaaS 开发框架的退出，KubeSphere 将来也会退出对 Serverless 的反对，整个 FaaS 框架与 KubeSphere 不是强绑定关系，开发者可独自选用，也可搭配 KubeSphere 应用，KubeSphere 自身也为能够更好反对该框架进行了适配。

人均迈入的云原生 2.0 是啥？

最近两年，业界不谋而合地进入到云原生 2.0 时代。几年前，咱们对云原生的定义更多的是停留在微服务、DevOps、麻利基础设施层面，议论更多的云化通常指资源的池化，次要是计算、网络、存储三大资源。那么，云原生 2.0 阶段区别于此的特色是什么呢？

采访中，于爽示意，不同的厂商对于 2.0 有着不同的定义，但大抵是心愿对本人或者与竞争对手的技术成熟度进行辨别，以便用户能够感知到差别。在 1.0 阶段，很多用户没开始或者在容器化的初始阶段，很多业务只是单纯满足容器诉求，但还没有和业务进行深刻联合。在 2.0 阶段，用户的关注点从容器化转移到更低的投入产出比，并开始尝试兼容云原生基础设施的技术架构，比方 Service Mesh、FaaS 等，开发人员写代码的形式不变，只是通过云的形式屏蔽了底层架构的复杂性。

从技术层面来看，CNCF 提供了蕴含微服务、容器等在内的云原生最佳实际。通过企业的实际，依据【2019-2020 年的云原生实际调研报告】显示 8.2% 的企业用了超过 5000 个容器，大部分参加调研企业应用容器的数量在 500 以下（61.2%），500-1000 个容器的比例为 21.4%，1000-5000 个容器为 9.2%。21.7% 的受访者中将云原生技术（包含容器、DevOps、微服务）已用于外围业务生产，30.6% 用于边缘性业务，20.1% 用于测试阶段，16.3% 尚处于评估阶段，11.3% 还没有采纳这些前沿的技术。

从数字来看，容器的整体应用率还是偏低的。依据于爽的理论理解，很多企业在应用容器的形式上也与技术层面的最佳实际有偏差，很多企业会将之前运行在虚拟机上的工作无缝打包到容器，也就是业界常提起的“胖容器”。从业务视角来看，微服务革新可能带来治理复杂度的成倍增长，这也是很多企业没有进行大规模微服务革新的起因，但通过容器化能够享受到 K8s 带来的便当也是没有问题的。

相较技术层面的最佳实际而言，越过微服务而先进行容器化对企业来说投入老本更低，然而奏效不会很显著，如果原有业务全部都是容器化的可能在上到 K8s 平台后成果显著；如果原有业务偏传统，为了容器化而容器化，奏效甚微，即使前期开始进行微服务革新也是须要投入微小精力的。

在 1.0 阶段之后，“以利用为核心”的概念进入咱们的视角。在于爽看来，这能够认为是 1.0 和 2.0 之间的过渡阶段，而 2.0 阶段的次要特色是“以业务为核心”，青云的指标是心愿让原有的业务开发人员间接享受到云原生的红利而无需投入过多学习老本。

容器混合云架构

在 2.0 阶段，容器混合云架构成为绝大多数传统企业的抉择，这些企业的需要基本一致，那就是兼顾稳态与敏态的业务，以一套对立的云平台或云架构反对多种不同的工作负载，既能确保利用和数据的稳固、牢靠和平安，又可能反对不断涌现的新利用。

“公有云 + 私有云”能够称之为广义的混合云，而明天更狭义上的混合云能够了解为是一种混合的环境或架构，它能够将物理的、虚拟化的、容器的、边缘的、云化的环境对立纳管起来，屏蔽各种不同的底层技术之间连贯、合作的复杂性，为下层利用提供对立的、敌对的的资源池。

不同的公有云、私有云因为采纳了不同的架构、技术，遵循不同的规范和标准，它们之间的连通性、兼容性是具备相当大难度的，数据和利用在本地与云端，甚至云和云之间迁徙、共享、合作，不得不逾越技术和厂商层面的壁垒，甚至能够说鸿沟。

直到容器的呈现，它屏蔽了底层异构环境的复杂性，为下层利用提供了对立的规范和接口，为混合云提供了机会和空间。

在此之前，人们对混合云的扫视次要是从 IaaS 层面切入的，集中在对裸金属、虚拟机等设施的治理；在此之后，混合云的架构体系以 K8s 作为规范和根底，对底层基础设施的各项能力进行抽象化和标准化。
从容器视角来看，只有镜像打包规范对立，用户能够无缝跨各种云，不存在厂商绑定危险；从混合云的视角来看，这种架构会让跨 Region 容灾等更加好操作；从客户的视角来看，整个技术趋势以及业务诉求都在推着客户抉择这种模式。

站在 KubeSphere 的视角，容器混合云架构是必须要做的一件事件，无论是对我的项目自身倒退还是满足客户需要层面，这都是一件值得投入精力的事件。与私有云大厂不同，KubeSphere 作为一个开源容器我的项目能够平滑运行在不同的底层云平台之上，对于容器混合云架构的实际具备人造劣势，并在积极参与跨混合云治理架构的研发，目前，KubeSphere 提供多集群多云混合部署并反对跨云治理及利用散发，其用户遍布多个私有云。
“无论将来的架构规范由谁来实现，KubeSphere 都心愿参加其中。”

嘉宾介绍：

于爽（Calvin Yu），KubeSphere 容器平台产品负责人，参加并研发了多款青云容器相干产品，如 K8s On QingCloud，KubeSphere 等。在退出青云科技之前供职于 IBM，对中间件监控、电子商务等多个畛域有深刻的钻研。

作者

赵钰莹 InfoQ