经过近十年发展，云原生的火热不只停留在概念上，而是已成为数字基建的必需品。Gartner的一份报告显示：到 2025 年，云原生平台将成为超过 95% 的新数字计划的基础——高于 2021 年的不到 40%。这说明，云原生正在引领全球技术趋势，而KubeSphere已成为云原生的基石！

为什么说KubeSphere是云原生基石？

问题是，什么是云原生？云原生要经历哪些关键阶段？当前，企业的云原生发展到了何种程度？青云QingCloud（qingcloud.com，股票代码：688316）容器平台资深产品经理于爽，在QKCP3.2产品升级发布之际，进行了详细解读。

大概从2013年开始，“云原生”这三个字被首次提出，要求企业的应用从设计之初就要考虑到云的环境，应用程序要运行在云中，而不是传统的数据中心，要能够充分利用和发挥云的弹性。说白了，真正的云原生要生于云、长于云、用于云。

云原生，为企业业务带来了更大的弹性，但也存在诸多挑战。如果，我们打开CNCF官网看全景图，就会发现云原生正面临和安卓手机一样的问题——碎片化。比如：只在监控和日志领域，就有很多解决方案和工具，IT团队可能没有足够精力按需运维，而KubeSphere从底层统一了架构标准，具有与生俱来的业务封装性，可以自然屏蔽应用的碎片化问题。

至于KubeSphere和QKCP到底是怎样一种关系？于爽给出了一个形象的比喻！在他看来，就像在家里自己做火锅，想吃什么就买什么食材，想怎么吃就怎么吃，KubeSphere能灵活地把各种业务组装在一个产品里，让用户直接忽视底层资源的复杂性问题，满足用户需求。但是，很多企业用户会认为很麻烦，想一步到位，获得类似于“海底捞”式服务，那么QKCP就能在各个环节提供可靠服务。

此种背景下，青云推出了QKCP 3.2版本升级，最根本目的是希望通过更多加强、进化的功能，助力用户全面拥抱云原生。也许一个DBA不懂K8s，但是有了QKCP，他可以基于他熟悉的MySQL管理环境进行操作，剩下的底层问题，都由QKCP平台本身来解决。

青云云原生团队产品开发的初衷是，将云原生能力借助一个产品化的形态给到终端客户。最开始，青云以公有云形式上线了 K8s 服务，逐渐发现不同用户使用 K8s 集群遇到的问题都大同小异，比如：K8s 之上怎么做监控、怎么做 DevOps 等，于是开始从总结、收集、解决问题的角度入手，打造更具竞争力的产品。2018年，为了实现在Kubernetes 之上构建面向云原生应用的分布式操作系统，KubeSphere横空出世。

KubeSphere没有改变底层的 K8s，任何 K8s 社区用户都可以无缝接入到KubeSphere。开源的KubeSphere凭借原生性确保了其与社区相连的紧密性，被很多团队参考、学习甚至直接拿去使用。KubeSphere 为整个开源社区的累积贡献数量达到240多个，很多志愿者现在依然活跃在社区里。青云容器在很多企业的关注度和使用量一下大幅上升，有近千家企业在使用KubeSphere构建 K8s 集群，支撑与管理其核心业务，有大约7.5万个集群及其生态环境是由KubeSphere做支撑。

站在企业用户的角度，KubeSphere已经很好，但青云并不满足于此，尽管很多社区用户能轻松玩转KubeSphere，但对于很多传统企业来说，其实并不知道如何拥抱云原生路线，并且不同行业有不同诉求，而云原生只是一个手段，还有太多可提升空间。

而QKCP就是KubeSphere的“伴生物”，她像“sidecar”一样伴随着KubeSphere，和KubeSphere成为互为最重要的能量来源之一。QKCP在能力上完全复刻了 KubeSphere 既有的各种功能，同时结合很多业务场景、青云的其他产品，以及各个领域合作伙伴进行延展与拓宽，为企业提供满足不同场景、不同行业所需的能力和方案，包括青云售前团队、售后团队提供的软能力，也都融合在QKCP里。

比如：从战略规划的角度看，云原生的第一步该怎么走？企业客户面临的最真实诉求是，不单纯把一个打包好的KubeSphere丢给企业就可以了，青云必须进入到企业，了解其真实业务，然后再借助容器产品以及青云的其他能力，一步步给出相应的规划。拿DevOps来说，市场上有很多工具与实现方法，哪些更适合企业业务现状？微服务、函数计算及代码，都不能只拿出一套理论，或者给一套工具就能解决，青云希望借助QKCP以及更多能力，针对不同的行业、不同企业给出一套适合的云原生实践规划。

尤其，对于一些创业公司来说，前期需要快速迭代，业务急需上线，QKCP不仅能够全面满足需求，降低硬件采购成本，还免去了人力成本，省去了学习过程。同时，QKCP也适用一些大企业，这类企业一般组织关系错综复杂，团队业务比较多，并且每条业务线都有自己的一套理论与标准，每个团队又都有自己的业务诉求和技术主张，让所有人都通过一个技术栈使用一套技术标准，也不太现实，而QKCP能从业务角度考虑问题，全面实现业务价值的提升。

QKCP 相比 KubeSphere 还有一些功能上的提升。比如：会有基于新形态、新架构的芯片支持，国产化操作系统的支持等等。社区版本的KubeSphere仅提供了核心组件的项目，客户可以基于 ARM 架构安装KubeSphere，但如果想用DevOps组件、微服务组件等，其实无法通过社区版的KubeSphere产品获得这个能力，需要自己打包代码，兼容 ARM 芯片和国产芯片。但在 QKCP 里，青云可提供全程全量的支持。

另外，QKCP还有多集群管理能力。不管用户把K8s 集群放在不同的云上，QKCP 都可以在一个控制平面上统一管理，实现整个平台的调度，包括可以实现GPU层面的管理调度。

值得一提的是，QKCP 不仅单纯地把K8s 管理起来，还实现了与青云更多产品的整合，包括数据库、中间件、低代码平台、云管平台等。为什么要把数据库和中间件统一纳管起来？其实也是和企业业务诉求相关！云原生客户不仅关心K8s本身能力如何，还要能满足数据库、中间件业务对接需求，如何让这些应用在K8s环境中跑起来，并稳定、强大、灵活地管理起来，都是用户选型的关键点。

QKCP 3.2版带来哪些核心能力？

问题是，在QKCP 3.2新版里，青云到底提供了什么样的管理能力呢？

总结下来，QKCP 3.2版本有三大主要更新。

第一， 更易用的GPU管理。原生的开源平台KubeSphere 提供了自定义监控面板，如果用户想拿到GPU数据，需要先部署GPU模板，然后自己配想要的监控页面。虽然比较灵活，可以按诉求自配，但其实企业客户不需要这么灵活。QKCP 优化过后，在集群监控数据里就可以看到 GPU 使用大屏，即在首页就可以看到使用情况。

第二， 更强大的通知管理。在通知配置里，QKCP 支持不同的通知媒介，比如钉钉、邮件、微信等，底下有一个菜单叫“通知历史”。如果配置好了微信或者钉钉之后，可以看站在平台视角统一管理发出去的所有通知。

第三， 深入到云原生 DBaaS领域给DBA提供强大的管理功能。新版QKCP集成了三个数据库：MySQL、PostgreSQL 和 ClickHouse。以MySQL为例，用户进入界面可以直接点击、部署，然后通过可视化的方式配置 MySQL 的各种数据库特性的指标。部署完以后，用户可以直接在 QKCP 界面里管理自己的数据库业务。通过MySQL专有的监控指标，可以快速创建 MySQL 的账户并授予相应的权限，这是DBA非常喜欢的一个功能。不用跳出QKCP子平台，就可以更改各种MySQL的参数。

QKCP 将在更多场景上持续优化。比如，提供跨基础设施的、统一视角的多集群监控大屏，业界也有些人叫驾驶舱。具体到业务层面，比如：跑一个应用，可以直接创建相应的 GPU 工作负载，就可以跑一些类似 TensorFlow 这种 AI 类、大数据类的任务，然后调用业务，直接可以看到相应的资源使用情况，也可以管理这些资源。比如：在某个 GPU 节点上，用户可以在监控里直接看到 GPU 的显存用量、温度、用电功率等。

如前文所述，尽管QKCP平台变得越来越强大，但并不代表青云只简单提供一款产品，而是围绕云原生路线，基于用户的业务架构，配合行业解决方案，提供专属的云原生套餐。其中，既包括QKCP，也可能会有混合云方案、IaaS、PaaS、存储、云管、低代码、数据库等，最终目标是以用户业务为核心，提供全生命周期的服务保障。