如何用架构的思维为云原生做减法？

云原生的理念相信大家已经不陌生，不论是实际使用的用户，还是业界从业者，都一致认同云原生是当前重要的技术趋势。

今天主要想 跟大家分享一下青云科技在帮企业推进云原生转型的过程中碰到的问题，以及我们找到的答案。

云原生带来一道“加法”题

Gartner 在分析报告中指出，到 2025 年，云原生平台将成为 95% 以上企业新数字计划的基础，而 2021 年这一比例还不到 40% 。

云原生平台成为企业数字基建的必需品大势所趋，不仅是互联网行业，制造、能源、医疗、教育、政府等各行业都在拥抱云原生技术。

这就带来一个新问题，在 CNCF 全景图里面，现在已经有 16 个已经毕业的项目，39 个在孵化，76 个进入沙箱，包括青云科技贡献的 OpenELB 负载均衡器、OpenFunction 开源函数计算平台两个项目也在沙箱里面。

云原生生态非常活跃，各种新兴项目层出不穷。不仅仅是 Kubernetes，围绕  Kubernetes 之上的边缘计算、网络、存储、Serverless 等项目不断涌现，构成了一张丰富的 云原生“元素周期表” 。

就像一个化学师想去调配某个物质时，会在元素周期表里选择适合的元素，企业在推进云原生转型之时，也必须要清楚地知道该如何去选择项目，更好地匹配业务。

然而， 很多企业都在做加法，比如一开始选择 Kubernetes 这个最核心的、已经毕业的项目作为底层调度平台。 当运维人员需要全面掌控平台的情况， 可能会选择 Prometheus 的技术栈。接下来要做日志管理，做微服务架构改造， 就像一道加法题，不停地在最原始的 Kubernetes 之上做加法。

这种做法，就导致 Kubernetes 这个雪球越来越大，越来越难推动，碎片化日益严重，需要不停协调技术人员去调研新的技术框架和开源项目，企业的运维成本逐层升高。

伴随业务发展，场景增多， **企业还需要做更多的加法。 **比如，不断给技术人员施加压力去学习新的东西，雇佣新的人员掌握新的技能。 平台构建好之后，人员的维护是企业看不见的成本，如何去管理这些平台，让平台各个组件无缝地升级，这些都会加载到企业的成本上。

青云科技破解之道：KubeSphere

2018年，青云科技找到了自己的解决办法，推出了 KubeSphere 容器平台。KubeSphere在推出时，秉承的理念是 让用户只需要一款产品，就能享受一支云原生团队带来的服务。

KubeSphere 通过产品化的方式屏蔽掉整个云原生生态各种碎片化的问题，开发者和企业用户只需要面对场景本身。

• KubeSphere 支持一键安装，组件按需开启。 比如运维团队需要可观测性里的监控、日志、告警等能力，只需要开启相关的组件。 开发团队需要 DevOps 各种场景的能力支持，可以在后台开启 DevOps 组件。 KubeSphere 完全按需匹配企业当前的场景和能力。

**• KubeSphere 提供插件市场，集成当前主流开源组件。 **开发者和企业需要什么，KubeSphere 就提供什么，一键部署，灵活掌握。 借助 KubeSphere，极大地帮助企业降低了碎片化、运维成本和管理成本上升等问题。

**• KubeSphere 提供跨基础设施全场景支持。 **从 2018 年至今，KubeSphere 积累了大量垂直场景的能力。 支持敏捷 DevOps，内置 Jenkins 和 Argo CD，支持各种业务场景的 CI/CD。 围绕可观测性，提供跨集群、跨异构基础设施的观测能力，无缝对接各种主流的网络存储，管理边缘云的边缘节点等。

**• KubeSphere 提供垂直多租户的多层管理能力。 **在 上层应用上，能够满足企业多样化的业务需求，而且 KubeSphere 是一个纯软件，不管企业之前的环境是使用物理服务器、公有云、私有云，还是云厂商的托管服务，都可以直接部署 KubeSphere，有极大的兼容性和包容性。

KubeSphere 还与英特尔达成合作：基于全新升级的 KubeSphere 企业版，双方打造了更高效的企业级云原生容器平台，在“安全、网络、性能”方面显著提升；集成英特尔开源的 Kata Container，让企业用户在 KubeSphere 界面就可以选择 Kata Container的运行环境，无缝将业务运行在 Kata Container Runtime 里；集成英特尔开源的 Multus，为企业用户提供多元的网络插件集中管理能力等。

另外，双方研发团队还联合实现软硬一体优化、应用性能优化。而作为云原生开源生态的重要参与者，未来双方将深化合作，更敏捷地将新技术、新项目能力进行整合。

寻求“加法”之外的更优解

青云科技推出 KubeSphere 破局方向之后，还在寻求更优的解决办法。

1+1+1+1+1+……这种加法的成本提升带来很多隐性痛点。比如前面提到的，KubeSphere 集成了英特尔的 Kata Container，集成的过程就意味着后台的 API Server 要做改造，集成新功能的 API，这其实是一种变相的侵入式开发，整个版本要为新特性去做新的规划，版本节奏也要做新的调整。

集群监控增强

当一个项目要发布新版本，KubeSphere 想集成它的新功能，就需要去做新的技术评估，新的后台架构设计调整，匹配相应的开发测试人员。

同时，KubeSphere 也有自己的版本迭代节奏，很难去快速匹配。当新版本发布之后，需要在用户环境中进行版本更新，即使用户的 IT 环境可以实现滚动更新，且基于高可用架构，但对于一个后端 API 服务的单一副本来说，这就是一次中断式更新。

如果希望新特性更好地呈现在 KubeSphere 界面，前后端代码需要整体调整。这种前后端构建的配合，其实是非常低效的行为。

KubeSphere 希望实现真正无缝地与大量优秀开源项目的整合，更加敏捷地为用户提供云原生生态体系的各种新能力。KubeSphere 即将 **重磅推出可插拔功能 **，这是在 KubeSphere 面对“加法”问题给出的解决方案之上寻求的更优解。

KubeSphere 的目标是为每一位用户和云原生玩家提供专属的云原生平台。 如果和 CNCF 全景图中的开源项目作比较，那些开源项目好比自助餐，每位食客可以拿着盘子去选自己想吃的食物，这个盘子可能会越盛越多。

KubeSphere 希望变成每位用户的专属厨房，企业的业务当前处于什么阶段，需要什么样的能力，通过可插拔开放架构的设计进行创新调整，天然地 KubeSphere 就能变成用户想要的样子。借助 KubeSphere，青云科技希望将自身的各种能力，及整个云原生生态的能力整合起来，让每一位参与者都能够去打造自己的 KubeSphere。

通过上图可以看到，KubeSphere 的核心组件在这次架构调整中变得更加轻薄， 很多支撑组件以插件化的方式整合到 KubeSphere 架构里面。 无论是用户的业务，还是合作伙伴的新能力，都以插件的方式整合到 KubeSphere 里面。

我们很快也会将 KubeDesign 域名开放出来，整个前端类库也是开源开放的。 比如我们的合作伙伴有个项目，需要在界面上嵌入新的表单，就可以直接用前端开源的类库整合到新的控制台。

而且，来自第三方的 API 都是直接动态注册的，实现了前后端一体的热更新。外部合作伙伴新的能力不用再等 KubeSphere 的版本更新，就可以快速整合到现有的 KubeSphere 框架里。

同时，这套前后端一致的插件架构也可以为合作伙伴提供新的 UI 框架，帮助他们打造自己的 KubeSphere 控制台。在 KubeSphere 里，整体的 UI 体验做了进一步的优化和提升，整个 UI 更像一个桌面操作系统，实现真正的云原生时代的分布式操作系统。每个组件都是卡片式的，可以按需灵活定制整个前端控制台。

KubeSphere 还会提供松耦合架构的插件中心，插件可以按需开启和关闭，从此告别由于“不断做加法”带来的臃肿现状。

Build Your Own KubeSphere，通过 KubeSphere 架构，我们实现了 BYOK，KubeSphere 不再单纯地属于当前 KubeSphere 社区，KubeSphere 完全属于用户，属于每一位合作伙伴。

目前 KubeSphere 前后端框架已经在 GitHub 社区完全开放，相关文档已经就绪。非常诚挚地欢迎大家加入 KubeSphere 的生态，一起共建新一代的云原生分布式操作系统。