時訊：云原生容器化平臺，為何選擇 KubeSphere？

T3 出行是南京領行科技股份有限公司打造的智慧出行生態平臺，由中國第一汽車集團有限公司、東風汽車集團有限公司、重慶長安汽車股份有限公司發起，聯合騰訊、阿里巴巴等互聯網企業共同投資打造。公司以“成為最值得信賴的出行服務企業”為品牌愿景，“科技引領 愉悅出行”為使命，倡導“可信，更自由”的出行理念，致力為用戶提供“可信、安全、品質”出行服務，讓用戶感受更加自由的出行體驗。

(相關資料圖)

隨著 T3 出行業務體量持續上漲，服務的穩定性需要系統化的保障。容器化改造將提供標準化的環境，基于應用運行環境實現完整的版本控制，消除開發到生產的環境差異，保證應用生命周期內環境一致性和標準化。同時容器化環境可以讓服務共享計算資源，并通過混部方式來提高整體計算資源的利用率，降低企業應用的基礎設施運營成本。

容器化之前 T3 出行是傳統的虛擬機模式，所有業務都部署在虛擬機上，全體產研通過堡壘機、傳統的監控系統、日志平臺等進行日常應用的運維。而一旦服務容器化開始，則必然需要一個云原生的容器化管理平臺，讓 T3 出行全體產研從傳統的虛擬機操作模式轉變為云原生操作模式。

同時，之前日常的應用運維模式需要使用多個平臺進行協作，產研定位一個應用性能問題往往需要來回切換多個平臺。所以 T3 出行希望容器化平臺可以集成周邊的配套，如日志查看、監控系統，讓產研盡量在一個平臺內完成日常運維的工作；也可以作為平臺工程的一部分，讓產研在開發環境可以擁有足夠的權限創建、更新、刪除非基線環境，而無需了解底層架構知識，通過自助化的環境能力可以讓研發并行開發測試，最終讓業務可以快速、高效增長。

選型說明

根據功能、UI 體驗、社區活躍度、學習成本這 4 點選型思路，選型首先必須要滿足 T3 出行對容器平臺的需求，其次是社區活躍度以及生態，最后是 UI 體驗，在 UI 體驗中包含了用戶的學習成本，即以低學習成本的方式讓 T3 出行的研發更夠快速上手容器平臺，同時也具備運維視角，如此就既滿足了研發的應用視角緯度，也滿足了運維的集群視角維度。

在選型期間對比了 Rancher、Openshift、KubeSphere，T3 出行最終選擇了 KubeSphere 作為云原生容器平臺。KubeSphere 定位是以應用為中心的容器平臺，提供簡單易用的操作界面，幫助用戶屏蔽掉那些技術細節，一定程度上降低了學習成本。同時 Kubesphere 具備優秀的容器管理能力、多集群支持能力、多租戶能力、天然集成的可觀測能力等，讓用戶在一個平臺上滿足了日常運維所需。

實踐過程

多集群統一管理

KubeSphere 多集群中角色分為主集群和成員集群，由 1 個主集群和多個成員集群組成，與 T3 出行原先的集群規劃不謀而合。主集群作為成員集群的控制面存在，通過主集群下發不同的管理策略給到成員集群。對于成員集群而言，則根據不同的環境、不同的租戶性質也會劃分到不同集群。如根據環境區分，會有開發集群、測試集群、預生產集群、生產集群；而根據租戶性質，會有一些對接三方業務的集群。

項目管理

在很多傳統的 DevOps 平臺中，并沒有與項目進行聯動，服務往往只是關聯了組織架構，當組織架構變動，服務的元信息就不準確了。而且，對于一個項目來說，經常會有跨部門合作的情況，而業務發布的視角卻是在各自的部門下的，項目成員無法在一個視圖下看到項目的所有業務，在項目的協作過程中自然就增加了許多溝通成本。

而 KubeSphere 就是基于項目維度對容器服務進行管理的，在 KubeSphere 中一個項目對應的就是 Kubernetes 一個 Namespace，租戶之間的視圖是隔離的，日常只需要在自己的項目視圖下進行協作即可。

T3 出行的 DevOps 平臺正在逐步的往項目集成方向發展，目前是按照業務域進行統一管理，一個業務域代表了一個 KubeSphere 中的一個項目，業務域下會有多個相關的業務服務，無論組織架構如何變換，業務域始終不變。

多租戶管理

KubeSphere 中的多租戶管理是基于企業空間維度來完成的，企業空間是用來管理項目、DevOps 項目、應用模板和應用倉庫的一種邏輯單元。用戶可以在企業空間中控制資源訪問權限，也可以安全地在團隊內部分享資源。企業空間可以關聯多個集群中的多個項目，并對企業空間中的成員進行權限管理，引用 KubeSphere 官方配圖便于大家直觀的理解：

T3 出行以業務域為項目維度進行統一管理，那么企業空間作為 KubeSphere 最小的租戶管理單元自然是被按照業務域進行劃分。所以 T3 當下的多租戶管理邏輯就是：企業空間（業務域）→ 集群（開發、測試等）→ 項目（業務域）。同時在企業空間中也抽象出了部門管理緯度，使用 KubeSphere 的部門管理，便于給不同的人員賦予不同集群（環境）操作權限。

內部 DevOps 平臺與 KubeSphere 的結合

T3 容器化之前已有一套 DevOps 平臺，這套 DevOps 平臺交付的制品是部署在虛擬機上的。而容器化項目開展的前置條件就是必須支持容器發布，如果讓現有的 DevOps 平臺改造成云原生化的 DevOps 平臺工作量巨大，項目風險不可控，所以 T3 出行最終選擇了 DevOps 平臺與 KubeSphere 的結合。內部 DevOps 平臺新增容器發布功能，只進行容器服務的發布和 Pod 副本數的擴縮容操作，由 KubeSphere 對發布后的容器進行接管，給研發人員展示容器發布后的應用狀態，讓研發人員自助式的與容器進行交互。

可以說，KubeSphere 接管了 T3 容器化發布的后半場，研發人員執行發布后，便會來到 KubeSphere 上進行與容器的交互操作，如日志查看、監控查看、進入容器控制臺、查看容器事件等。

效果

T3 出行的業務已經全面容器化，所有的集群已被 KubeSphere 納管，產研的日常應用維護工作都需要基于 KubeSphere 平臺進行開展。

得益于 KubeSphere 的以應用為中心的設計，幫用戶屏蔽了底層技術細節，目前 T3 出行全體產研都可以自助式的使用 KubeSphere 進行日常的工作，也讓T3 產研從傳統的應用維護模式成功的轉向了云原生應用維護模式。KubeSphere 集成了監控、日志、事件，提高了 T3 產研日常的人效。KubeSphere 集群級別的可觀測，是T3 出行提升集群資源利用率的參考依據。

本文來源：財經報道網

關鍵詞：