人均云原生2.0，容器的圈子内卷吗？
两三年前，云原生势头正盛，开始“侵入”各大公司。三年过后，随着云原生 2.0 时代的到来以及落地实践进度的加快，业内对云原生又有了很多新的理解，对其可为业务带来的实际价值有了更多感触，容器的圈子也经历了一轮洗礼。在各大公司纷纷表示已经迈入云原生 2.0 时代的今天，我们有幸可以和 KubeSphere 容器平台产品负责人于爽交流下当前云原生领域值得关注的技术趋势和落地方向。
K8s 项目发展至今，已成为云计算领域平台层当仁不让的事实标准，但其复杂性、学习曲线陡峭也是不争的事实。于是，我们在过去三年看到了一众基于 K8s 衍生出的项目，试图降低用户部署 K8s 的难度，并且随着开源运动的兴起，这些项目大都选择了开源的方式运营。类似的项目，相同的运营方式，竞争在所难免，难道容器的圈子开始内卷了吗？
“两三年前，确实有用户会找来一堆与 KubeSphere 类似的开源项目让我们提供比较结果，甚至有些开源项目，我们都没见过。”
如今，CNCF 基金会的云原生全景图已经相当庞大，涵盖基础设施层、运行时层、编排和管理层、应用定义和开发层以及贯穿所有层的平台解决方案、可观察性和分析工具，并且经过这三年的发展，很多项目已经从初级版本走向成熟，拥有稳定的拥护者和使用者。
“三年前，用户可能需要不少的时间抉择自己需要的项目，如今从开源社区的角度来看，围绕着容器平台的项目基本稳定，也有一些项目在这三年走向淘汰，用户结合具体的业务场景很容易就可以做好选型。”
从这个角度看，容器的圈子并没有在过去三年逐步内卷，反而越来越清晰，留下来的项目都有了各自的栖身之地，淘汰的项目原因各不相同，而开源不易是其中很重要的一项影响因素。
项目地址：
https://github.com/kubesphere/kubesphere
“开源这件事情，我们起初也走了一些弯路。”
从表面上看起来，一家商业公司运营一个开源项目似乎很简单：将代码放到 GitHub 上或者将项目捐献给某一个基金会，然后建立社区把有相同想法的人聚拢在一起，接下来就是用户群体不断壮大，项目不断更新迭代，最后成功毕业或者走向成熟，这套流程看起来非常水到渠成，但具体到执行层面，有很多问题需要考虑：一个全新的开源项目怎么让开发者信任并参与？如何运营开源社区是有效的模式？哪些功能应该贡献给社区？
开源社区通常不是由一个人控制的，基于商业公司运营的开源项目情况更加复杂。有时候，同一个功能，社区的实现思路和公司不一样；有时候，公司规划了一个商业功能，社区提前做出来了......
在 KubeSphere 开源之初，整个团队想的是把代码写好就可以了，后来的运营过程中发现这种想法是有问题的，如果开源之初没有想好目标，只是为了开源而开源，就会导致后面的很多工作无法正常开展，把代码提交到 GitHub 并不代表开源目标就完成了，如果没有种子开发者的信任和推广，很难真正做起来，但怎么让种子开发者信任呢？
“我们前期和很多开源领域的资深专家做过沟通。事实上，种子用户们对开源项目的接受度非常高，对新的开源项目容忍度也非常高，但这一切的前提是你的代码和开源文档都足够完善，只要他可以按照你的文档和代码解决实际问题，就会对项目产生信任，从而自发向外推荐。”
虽然种子用户的容忍度很高，但这批人的技术水平也非常高，乱搞肯定是不行的，于爽补充道，一个完备的开源项目应该拥有完善的开发文档、清晰的技术架构图，并且有一个清晰的路线图，愿意倾听种子用户的建议。如果种子用户都没了，转而去孵化后面的小白用户，整个链条就断掉了，肯定是做不好的。
过去几年，我们也看到了一些项目的没落，大多是团队没有意识到开源的价值，没有真正弄懂开源，进而导致项目的发展呈现负向循环，越做越沮丧，甚至成为整个团队的累赘。
如今，KubeSphere 3.1.0 版本已正式发布，该版本包含了来自 KubeSphere 社区及企业用户发现的 bug 及提出 的需求，涉及到 KubeSphere 前后端各个组件；全球近 100 位贡献者参与 3.1.0 的开发、测试工作，有个人爱 好者，也有大量的企业用户、开源项目参与贡献，如中通、锐捷、马上消费金融、红亚科技、Kube-OVN 等；主仓库 160 多个 PR 提交。在 3.1.0 版本 之后，KubeSphere 小版本的发布频率会更频繁。
“回头想想，做开源项目就好像在下棋，然后旁边有很多人在指导你，你不单单是在做一个项目，也是在交朋友、做圈子。如果你是纯做商业产品，圈子就会非常垂直，集中在和商业闭环这个圈里的人打交道。”
除了技术的文档层面准备就绪，青云自上而下对开源的认知也让 KubeSphere 从诞生之初就决定走全球化的路线，而不是闭门造车，为此开通了海外沟通方式，并提供了大量英文素材，希望全球开发者都可以加入到其中平等沟通，并设置了专门的运营团队负责对接全球开发者提的问题，管理开发者关系，为开源社区输送对应的文档和资料。
“其实，国内很多做开源的人都是既写代码又做社区运营，也不乏有做的好的，但写代码的人所希望聚焦的问题未必是和运营相同，所以我们设立了专门的团队来做运营，希望开发者在社区中的体验更好，希望对用户反馈问题的响应更加及时。”
基于上述认知，KubeSphere 得以在容器圈拥有一席之地，并于近日新增了 FaaS（函数计算）支持。事实上，FaaS 在云原生的圈子里也不是什么新鲜概念，这代表着一种计算模式，可以极致优化资源成本，自动应对波峰波谷，对于特定领域的开发，它可以极大地释放开发者的开发运维压力。过往几年，我们也见到了一些互联网大厂在此方面的实践和输出，但对传统企业而言，这还是一个“新鲜事物”。
相较于公有云厂商的一早入局，青云此时开始做 FaaS 会不会有些晚。对此，于爽表示现阶段公开支持 FaaS 主要基于三方面的考虑：一是随着容器的普及，FaaS 的落地难度逐渐降低，业内已有许多开源框架可供选择，虽然功能层面还不能完全满足客户，但从架构完整性角度来说已经准备就绪；二是客户对此已提出需求，基于 Java 的框架可能更好招人但整个框架给技术团队带来较大负担，对于中小客户而言，可快速拼接的业务框架或许是更优的选择，每个开源框架都有自己的优劣，但在一些私有化环境里面，客户需要借助一个通用性框架实现跨平台的 FaaS；三是青云内部的技术储备已经足够，并为本次开源准备了半年有余，主要工作已经完成。
随着 FaaS 开发框架的加入，KubeSphere 未来也会加入对 Serverless 的支持，整个 FaaS 框架与 KubeSphere 不是强绑定关系，开发者可单独选用，也可搭配 KubeSphere 使用，KubeSphere 本身也为可以更好支持该框架进行了适配。
最近两年，业界不约而同地进入到云原生 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 都希望参与其中。”
本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：赵钰莹，36氪经授权发布。
