Kubernetes最開始是由谷歌開源的虛擬化平臺或是支撐雲原生的基礎設施平臺。它源於谷歌內部的一套基礎設施borg，裡面耦合了很多谷歌自己的業務邏輯。谷歌把它的共性拆出來，開源成Kubernetes。谷歌把它貢獻給CNCF基金會，現在很多國際、國內的企業都在致力於推進Kubernetes的演進、迭代，包括我們熟知的微軟、IBM，包括青雲都是這個社群主要的貢獻者。

目前不管是物理機還是雲平臺，只要使用者的業務構建於Kubernetes、以容器化的方式交付，就可以跑在不同的平臺之上。這意味著你沒有被任何服務商鎖定，你的業務可以很好的跨基礎設施做應用遷移。但目前Kubernetes只提供了資源執行的最基礎平臺，你可以把它理解為毛坯房，沒有傢俱和家電，只能保證企業最基礎的應用，後續的使用會變得非常複雜。過高的學習使用成本，正在阻滯著Kubernetes的企業應用普及。

注意到這些企業的需求，於是青雲打造了雲原生專業平臺—— KubeSphere，並且將程式碼在GitHub上開源。

KubeSphere的設計開發理念在於平臺歸平臺，應用歸應用。透過青雲專業的產品設計師最佳化，讓Kubernetes實現“開箱即用”。

社群使用者把KubeSphere稱為雲原生全家桶，因為KubeSphere提供了很多可選的功能元件，使用者可以在使用過程中，根據自己的業務需求有選擇性的使用這些元件。簡單羅列了一下：

一、即點即用的DevOps，面向開發測試人員，覆蓋了開發測試全鏈條的釋出。從提交程式碼、構建應用、應用釋出到測試環境、測試透過釋出到準生態環境及生產環境，這一套流程在KubeSphere平臺上可透過視覺化介面進行統一的管理。

二、靈活可選的微服務框架，現在Java系比較主流的SpringCloud、Dubbo；CNCF現在主推的Istio，Istio是由谷歌、IBM和Lyft三家公司主導的開源專案。不管是傳統微服務框架還是主流的雲原生微服務框架，在KubeSphere平臺上都可以得到很好的支援。

三、應用跨平臺一鍵部署。這是得益於容器、Kubernetes的特性，天然地在KubeSphere產品裡支援。

此外，青雲把自身擅長的技術同時輸出到這個平臺，青雲有自己的SDN、SDS產品，包括QingCloud雲平臺，都可以跟KubeSphere很好的整合。這個整合並不是強繫結的關係，KubeSphere既可以安裝在青雲之上，也可以安裝在其他雲平臺、物理機或者VMware之上。如果你目前正在使用青雲其他產品，在KubeSphere上也有與之對接的介面，可以保證這些產品之間很好的整合。

目前，透過社群使用者和商業使用者的反饋，青雲KubeSphere的監控功能可以滿足從資源視角、應用視角，運維應用需求。另外在合規方面，可以從產品控制層面滿足，像銀行、保險公司部署安裝KubeSphere時在審計上的要求。

為什麼KubeSphere可以開箱即用？於爽用一個工具箱舉例進行了更形象的說明。

“大家對開箱即用的理解是不同的，左邊是一個很酷很漂亮的工具箱，如果你是物業人員，修水電、水管、電線，所有工具都可以在工具箱裡拿到。但其實工具箱裡的所有東西都是瑣碎的，你需要了解水電的細節，才能很好地修理它。工具箱不是開啟後就能很好地使用，你需要具備基礎的使用知識。

在雲原生的勢頭之下，我們希望KubeSphere可以開箱即用、運維友好，把所有後端的技術細節遮蔽掉，盡我們最大的可能幫助使用者節省所有的學習成本，使用者可以迅速上手，提升使用者的效率。這需要我們對使用者行為習慣有很多的分析。

KubeSphere的產品目標是“聚焦業務應用”，所有的功能體驗都是圍繞應用設計的。因此，青雲在產品開發之前都會跟社群使用者、現有的企業使用者進行調研，他們現在的使用模式是怎樣的，期待的模式是怎樣的，匯聚並梳理所有的需求，提煉並最終展示在KubeSphere平臺上，形成很好的使用者體驗。

KubeSphere，是在Kubernetes之上構建的分散式作業系統，是用於資料中心的、可插拔的企業級多租戶容器平臺。為什麼說它是分散式作業系統？大家知道Linux核心是Linux作業系統最核心的軟體或者平臺，但是沒有人直接使用Linux核心，大家使用的是基於Linux核心開發的作業系統，比如紅帽等。Kubernetes是分散式作業系統核心，那麼KubeSphere就是面向終端使用者的分散式作業系統。它並不是給個人使用者用的，而是服務於企業，不管是中小企業還是大型企業組織。

KubeSphere的很多功能是可插拔的，因為企業的訴求是多種多樣的，使用者需要什麼，直接開啟，就可以很好地在平臺上無縫的使用。在企業裡這個平臺肯定是多租戶的，因此需要有相應的租戶管理體系支撐這個平臺。

4月19日，企業數字化轉型日益成為傳統企業突破業務瓶頸的首要選擇，從幾年前的以雲優先的“Cloud First”到所有業務上雲的“Cloud Only”，再到近兩年的“Cloud Native”雲原生時代，更多企業轉變為以消費者和產品為中心來安排生產要素和經營方式，將生產、銷售、運營等業務環節賦予數字化力量。

與之相伴隨的是，大量的數字化應用被整合在企業的業務流程中，而高速迭代變化的數字化系統，對應用架構、運維服務提出了敏捷化的需求，給企業IT部門帶來更大挑戰，當前容器化管理越來越引起關注。

為了更方便快捷的服務於企業數字化轉型需求，青雲QingCloud 推出KubeSphere 容器平臺，旨在幫助企業輕鬆應對多租戶、工作負載和叢集管理、服務與網路管理、應用管理、映象倉庫管理和儲存管理等業務場景。

青雲QingCloud 應用及容器平臺研發總監周小四介紹，KubeSphere是基於Kubernetes為核心的企業級分散式多租戶容器平臺，提供簡單易用的操作介面以及嚮導式操作方式，在降低使用者使用容器排程平臺學習成本的同時，極大減輕開發、測試、運維的日常工作的複雜度。

KubeSphere目標：簡單易用 客戶上手即用

眾所周知，Kubernetes是Google開源的一個容器編排引擎，它本身支援自動化部署、大規模可伸縮、應用容器化管理等。不過Kubernetes的學習成本很高，安裝部署也很複雜，對傳統企業的非專業技術人員而言落地使用困難度太高。

對此，青雲QingCloud 應用及容器平臺研發團隊在Kubernetes基礎上打造出KubeSphere這款專業企業級容器平臺產品，為企業使用者提供簡單易用的高效能可伸縮的容器應用管理服務。

KubeSphere容器平臺產品經理於爽介紹，KubeSphere提供面向開發、測試、運維友好的 UI ，嚮導式使用者體驗，大幅降低 Kubernetes 學習成本。同時，KubeSphere 為企業使用者提供了一個具備極致體驗的 Web 控制檯，讓使用者能夠像使用任何其他網際網路產品一樣，快速上手各項功能與服務，極大降低了企業的使用門檻。

KubeSphere容器平臺的核心優勢

容器市場競爭非常激烈，如何才能長久的保持競爭力？周小四表示KubeSphere從設計之初就採用了更先進、更靈活的架構設計。

這種靈活性具體體現在，第一點，KubeSphere可部署在任何的Kubernetes叢集上，包括任何一個發行版。只要底層是基於Kubernetes的，KubeSphere就都可以部署上去並管理這個叢集。KubeSphere必須擁有納管的能力，因為客戶喜歡嘗試的不同管理平臺。

第二點，KubeSphere支援可配置、可插拔的功能。KubeSphere提供了很多功能，但並不是所有的客戶都想要所有的功能，有的客戶只想要DevOps，有的客戶只想要微服務治理。那麼KubeSphere提供功能是可配置、可插拔的，不同的客戶就可以自行選擇安裝自己需要的功能。

於爽介紹，KubeSphere提供了多種經過社群眾多開發者和廠商驗證過的開源外掛，支援多款儲存外掛以及多種儲存模式。KubeSphere本身提供了各種主流網路外掛的對接，比如calico、flannel等，可滿足企業級使用者各種安全訴求。

此外，周小四介紹，除開源解決方案外，使用者如果對網路和儲存有更高要求，可選用青雲QingCloud作為底層平臺，可以使用價效比更高的網路和儲存解決方案。青雲QingCloud固有的核心優勢包括“儲存和網路”，其中分散式儲存QingStor NeonSAN天然適合微服務，其效能、穩定性、安全性遠高於開源的儲存。青雲QingCloud的SDN在私有云和公有云都得到驗證，其效能穩定，穩定性高於開源的網路方案。

Kubernetes強大的生態能支援KubeSphere走更遠

事實上關於容器技術，業界存在三大主流排程框架之爭，即Docker Swarm、Kubernetes和Mesos。青雲QingCloud 為何選擇Kubernetes？

周小四表示，確實經過了長時間的考量，“因為一旦擁抱一家，如果這一家走不下去是很麻煩的。而周小四認為Kubernetes最終將贏得戰爭，因為其生態足夠強大。

Kubernetes背後有Google、IBM的強大支援。並且Kubernetes是源自於Google內部的BORG，BORG在Google內部運行了差不多20年，可以說早就已經得到驗證，併成熟了。

此外，周小四表示，Kubernetes之所以可以贏得戰爭，就是憑藉開源創造的強大生態。Kubernetes不僅僅是容器的排程和編排，它還制訂了一套標準和規範，生態非常強大。

而KubeSphere本身也採用了開源模式，周小四稱：“我們認為Kubernetes是容器時代的分散式作業系統核心，我們一定是要基於此再發展上層的功能。”事實上現在的容器廠商，從去年開始也越來越多的轉到Kubernetes上來。

KubeSphere 作為雲原生家族 後起之秀，開源近兩年的時間以來收穫了諸多使用者與開發者的認可。本文透過大白話從零詮釋 KubeSphere 的定位與價值，以及不同團隊為什麼會選擇 KubeSphere。

KubeSphere 是在 Kubernetes 之上構建的 多租戶 容器平臺，以應用為中心，提供全棧的 IT 自動化運維的能力，簡化企業的 DevOps 工作流。使用 KubeSphere 不僅能夠幫助企業在公有云或私有化資料中心快速搭建 Kubernetes 叢集，還提供了一套功能豐富的嚮導式操作介面。

KubeSphere 能夠幫助企業快速構建一個功能豐富的容器雲平臺，讓企業在享受 Kubernetes 的彈性伸縮與敏捷部署的同時，還可以在容器平臺擁有 IaaS 平臺的儲存與網路能力，獲得與 IaaS 一樣穩定的使用者體驗。比如在 KubeSphere 2.1.1 新增了對阿里雲與騰訊雲塊儲存外掛的整合，支援為 Pod 掛載公有云的儲存，為有狀態應用提供更穩定的持久化儲存的能力。

在日常的運維開發中，我們可能需要使用與管理大量的開源工具，頻繁地在不同工具的 GUI 和 CLI 視窗操作，每一個工具的單獨安裝、使用與運維都會帶來一定的學習成本，而 KubeSphere 容器平臺能夠統一納管與對接這些工具，提供一致性的使用者體驗。這意味著，我們不需要再去多執行緒頻繁地在各種開源元件的控制面板視窗和命令列終端切換，極大賦能企業中的開發和運維團隊，提高生產效率。

有很多使用者習慣把 KubeSphere 定義為 “雲原生全家桶”。不難理解，KubeSphere 就像是一個一攬子解決方案，我們設計了一套完整的管理介面，開發與運維在一個統一的平臺中，可以非常方便地安裝與管理使用者最常用的雲原生工具，從業務視角提供了一致的使用者體驗來降低複雜性。為了不影響底層 Kubernetes 本身的靈活性，也為了讓使用者能夠按需安裝，KubeSphere 所有功能元件都是可插拔的。

KubeSphere 基於 OpenPitrix 和 Helm 提供了應用商店，對內可作為團隊間共享企業內部的中介軟體、大資料、APM 和業務應用等，方便開發者一鍵部署應用至 Kubernetes 中；對外可作為根據行業特性構建行業交付標準、交付流程和應用生命週期管理的基礎，作為行業通用的應用商店，可根據不同需求應對不同的業務場景。在 3.0 版本還將支援計量 (Metering)，方便企業對應用與叢集資源消耗的成本進行管理。

可觀察性是容器雲平臺非常關鍵的一環，狹義上主要包含監控、日誌和追蹤等，廣義上還包括告警、事件、審計等。對於 Kubernetes 運維人員來說，通常需要搭建和運維一整套可觀察性的技術架構，例如 Prometheus + Grafana + AlertManager、EFK 等等。並且，企業通常還需要對不同租戶能夠看到的監控、日誌、事件、審計等資訊，實現按不同租戶隔離，這些需求的引入無疑會增大企業的運維成本與複雜性。

KubeSphere 能夠幫助運維人員基於 Kubernetes 快速搭建一套滿足雲原生可觀察性標準的技術架構，支援在一個統一的平臺納管這些元件，或對接外部已有的元件。KubeSphere 能夠在一套管理介面中，實現從基礎設施層級到容器微服務層級的多維度日誌與監控，支援逐級下鑽定位異常資源，並且能夠滿足多租戶隔離的需求。在 3.0 版本還將持續增強可觀察性，近一步豐富事件與審計的視覺化管理能力。

對於 DevOps 團隊而言，日常工作除了開發一些自動化的工具之外，還需要運維與管理眾多開源工具鏈。DevOps 本身作為一個很廣義的方法論，也可以被認為是一種文化，很多 DevOps 團隊在落地過程中，也會遇到各種各樣問題，例如 CI/CD 工具繁多、涉及人員和環境較多、流程相對複雜等等。

我們選擇以工具型產品的形式，將 DevOps 在 KubeSphere 中落地。KubeSphere DevOps 系統選擇 Jenkins 作為其 CI/CD 引擎，藉助 Jenkins 豐富的外掛體系和易於進行擴充套件開發的特性，幫助 DevOps 團隊在一個統一的平臺中，打通開發、測試、構建、部署、監控、日誌與通知等流程。KubeSphere 為 DevOps 團隊打造了以容器為載體的端到端的應用交付平臺，實現從專案管理、應用開發、持續整合、單元測試、製品構建到應用的生產交付，所有的流程都是一個完整的閉環。

基於 Kubernetes，KubeSphere DevOps 充分利用和釋放 Kubernetes 動態擴充套件的能力。例如，我們在內建的 DevOps 系統使用了 Jenkins Kubernetes 的動態 Agent，即預設全部使用動態的 Kubernetes Slave，這樣的方案相較於傳統虛擬機器上的 Jenkins 要更加靈活敏捷。同時，在 KubeSphere DevOps 中內建了使用者常用的 Agent 型別，例如 Maven、Node.js、Go 等，並且還支援使用者自定義與擴充套件的 Agent 型別。

我們將內建的 Jenkins 與 KubeSphere 賬戶打通，滿足企業對 CI/CD 流水線多租戶隔離與統一認證的需求。另外，KubeSphere DevOps 支援建立 InSCM 與 OutOfSCM 兩種形式的流水線。這樣能很好地相容專案已有的 Jenkinsfile，或使用圖形化編輯流水線。

業務開發者即使還沒有深入瞭解 Docker 與 Kubernetes 的機制，也可以藉助 KubeSphere 內建的自動化 CD 工具，如 Binary to Image 和 Source to Image。使用者只需要提交一個倉庫地址，或上傳 JAR/WAR/Binary 等二進位制檔案，即可快速將製品打包成 Docker 映象併發布到映象倉庫，最終將服務自動釋出至 Kubernetes 中，無需編寫一行 Dockerfile。並且，在自動構建的過程中，能夠生成動態日誌，幫助開發者快速定位服務構建與釋出的問題。

在產品新版本釋出前，運營團隊通常需要引入一部分流量對新版本灰度測試。灰度釋出可以保證整體系統的穩定，在初始灰度的時候就可以對新版本進行測試，方便及時發現和調整問題，以驗證產品的可行性和收集使用者反饋。

KubeSphere 基於 Istio 提供了藍綠部署、金絲雀釋出、流量映象等三種灰度策略，無需修改應用的服務程式碼，即可實現灰度、流量治理、Tracing、流量監控、呼叫鏈等服務治理功能，即讓產品的迭代能夠按照不同的灰度策略對新版本進行線上環境的測試，並且能夠在服務拓撲與 Tracing 中發現微服務間互相請求的網路問題。

KubeSphere 支援部署和執行在包括 公有云、私有云、虛機、物理機 和 Kubernetes 等任何基礎設施之上，並支援線上與離線安裝，可參考 KubeSphere 官方文件 進行安裝。