經過近十年發展，雲原生的火熱不隻停留在概念上，而是已成為數字基建的必需品。Gartner的一份報告顯示：到 2025 年，雲原生平台将成為超過 95% 的新數字計劃的基礎——高于 2021 年的不到 40%。這說明，雲原生正在引領全球技術趨勢，而KubeSphere已成為雲原生的基石！
為什麼說KubeSphere是雲原生基石？
問題是，什麼是雲原生？雲原生要經曆哪些關鍵階段？目前，企業的雲原生發展到了何種程度？青雲QingCloud 容器平台資深産品經理于爽，在QKCP3.2.0産品更新釋出之際，進行了詳細解讀。
大概從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、存儲、雲管、低代碼、資料庫等，最終目标是以使用者業務為核心，提供全生命周期的服務保障。