云原生生态非常活跃，各种新兴项目层出不穷。不仅仅是 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 的生态，一起共建新一代的云原生分布式操作系统。 
分享