上汽集團帆一尚行業務發展部總經理 龔瀚申

在上汽集團帆一尚行業務發展部總經理龔瀚申看來，汽車行業對網際網路轉型的需求主要集中在兩個方面，一方面是汽車行業對於網際網路雲原生的需求，如車聯網共享出行等，這些網際網路業務帶動了整個汽車行業的轉型，而這一類的生態大多源於雲的系統架構，屬於雲原生的系統。另一方面則是來源於公司內部的運營需求，運營方式無法實現對網際網路快速變革需求的及時響應，重複的基礎建設、複雜的系統架構以及封閉的業務系統，將會造成巨大的資源浪費和高昂的企業運營成本。

當企業將業務部署到雲端之後，這樣的情況便會得到相應的改善，除了降低整體的IT投資成本之外，基於雲端計算互聯互通的優勢，也能增加業務之間的資料互動。“從上汽集團的戰略規劃層面出發，我們需要開發大量的具有行業特性的產品。”龔瀚申分析道：“在上雲的過程當中，雲平臺不單是資源提供方的角色，最重要的是它將通用技術與通用業務功能產品化。這是上汽雲平臺長期的一個發展方向。”

帆一尚行雲平臺的總體框架

在明確上汽雲平臺未來的發展方向之後，他們制定了一個總體的雲平臺框架，將主要的任務集中放在兩大平臺進行處理。其一是基礎服務平臺，以虛擬化和資料中心作為技術核心，將標準化的硬體以虛擬資源的方式提供給使用者，使用者在資源池內按需計算。其二則是推出了平臺服務，容器加上排程系統將構成平臺服務的執行基礎，當平臺服務往業務層靠攏，將抽象出業務中臺，當平臺服務往技術層靠攏，將抽象出技術中臺。不管是技術中臺還是業務中臺，執行基礎都是由虛擬化和容器來提供的。所以在雲資料中心，容器已經顯然成為上汽集團帆一尚行的一個核心技術，它不僅是一個輕量級的PaaS，也是IaaS平臺更小顆粒的虛擬化，為整個平臺提供執行基礎。

從時間線上來看，上汽集團在容器技術的探索和實踐與容器技術的整體發展息息相關。

帆一尚行容器技術使用歷程

2015年，上汽集團帆一尚行的開發團隊使用Docker跑了一些簡單的網站應用，開發人員在筆記本上執行一些簡單的程式碼，通過容器打包推送到帆一尚行的虛擬環境裡面，在秒級的響應時間內便可以啟動打包的應用。“我們將Docker和OpenStack進行了對比，也在內部進行了容器是否會取代OpenStack的議題討論。”龔瀚申回憶：“由於容器成熟度以及使用者成熟度的問題，我們認為短期內容器還無法取代OpenStack，但基於這次嘗試，我們感受到了容器在資源利用率和環境一致性上的優勢。”

2016年，上汽集團帆一尚行在Docker以及編排系統上投入了更多的精力，開發團隊調研了市面上Rancher、Mesos+Marathon、Kubernetes以及Docker+Swarm等系統，不同的系統在系統成熟度以及部署難易程度上存在一定的差別，最終選擇了Docker+Swarm去搭建企業的叢集，並開始了利用小規模叢集支撐整體營銷活動的實踐及推廣。

到了2017年，隨著Kubernetes的呼聲和熱度越來越高，產品也日趨成熟。上汽集團帆一尚行開發團隊在內部小範圍構建了Kubernetes的小型叢集，將其應用於整個GPU資源平臺的排程。經過這一兩年的嘗試及探索，上汽集團帆一尚行正式將Kubernetes列為產品線的重要產品，用以支撐整個容器平臺的執行。

“在建設Kubernetes平臺的初期，我們從多個維度設定了容器平臺的目標。”龔瀚申分享道：“從部署的維度出發，它必須支援多跨資料中心的部署，必須支援主流公有云和私有云平臺的部署；從資源排程編排的角度出發，它必須支援主流的CPU排程，必須以開放標準的形式提供儲存與網路的對接；從租戶管理的角度出發，它必須可以提供多租戶的資源配額，讓租戶在自己的配額裡面可以排程資源以及映象倉庫；從整體運營管理的角度出發，它必須提供一個統一對接Kubernetes叢集管理的平臺，必須能對Kubernetes叢集進行靈活增減，以及能實現簡單的監控功能。”

帆一尚行技術方案選型

通過一系列的探索與實踐，上汽集團最終落地了最符合自身需求的容器技術選型：基於物理伺服器構建基礎設施，利用自研基於Ansible的Kubernetes進行整個叢集的自動化部署；通過Rancher來實現平臺的統一管控，對接統一認證系統，實現應用部署管理、多租戶、配額管理等高階功能；在網路的層面上，選擇利用Calico BGP網路+外部L4L/7的負載均衡來實現多種應用的釋出形式；儲存則是沿用了Swarm裡面的Nexenta以及PortWorx來打造分散式儲存方案；最後，上汽集團還基於Prometheus進行平臺監控和外部統一監控告警。

Kubernetes平臺邏輯框架

Kubernetes叢集與上汽集團帆一尚行的使用者介面是整合的，使用者可以通過登入Saicmotor的入口網站直接使用上汽集團帆一尚行的Kubernetes叢集，或者是通過上汽集團帆一尚行周邊的雲平臺產品如應用開發日誌、日誌管理等來進行對Kubernetes叢集進行管控。而上汽集團帆一尚行的運維人員則是通過Rancher的管理介面來管理底層的Kubernetes叢集。

“關於Kubernetes應該怎樣以產品的方式提供給使用者，我們也進行了一些場景化的思考。有人會將Kubernetes當作是資料中心的管控系統，有人會將它作為是任務排程的管理系統，還會有人將Kubernetes當作是微服務的一個治理框架，在不同的而場景下，大家對Kubernetes的定義是不一樣的。”龔瀚申分析：“這一切就是源於Kubernetes它開放的多維度框架設計理念以及簡單易用的產品特性，所以我們將它理解為一個可擴充套件、可組合的排程系統框架。”

針對Kubernetes的產品特性和使用者對Kubernetes的熟悉程度，上汽集團帆一尚行設計了兩類產品形態。一類產品形態針對初級使用者，將Kubernetes封裝起來，以另外一種形式為使用者提供服務，使用者更多體驗到的是以容器技術為主的應用部署和釋出能力。另一類則針對高階使用者開放，使用者可以獨享一個Kubernetes叢集，並且通過一鍵部署來快速實現，可以充分體驗Kubernetes的特性。

在內部的專案落地之後，上汽集團為了實現對L4自動駕駛產業化軟體的開發以及複雜場景下自動駕駛功能的建設需求，他們對容器平臺提出了更高的要求。

 “平臺必須提供完整的AI軟體開發流程管理體系，包括資料管理、模型管理、模擬測試、模型壓縮等系統功能，和車端行程從訓練到推理的AI軟體開發閉環。”龔瀚申將這一目標歸結為兩大需求，一是AI訓練服務，將專注於資料標註、資料儲存、CPU訓練以及分散式訓練；二是AI模型，包含訓練服務、託管釋出和模型的版本管理。

同時，這一平臺將定義為集團層面的公共訓練服務平臺，不僅服務於上汽集團智慧駕駛的部門，還將為集團下屬的整車物流零部件等企業提供AI訓練服務。那麼，對於這一平臺來說，任務排程功能以及租戶隔離功能都是不可或缺的。

上汽集團帆一尚行開發團隊在進行技術選型的時候，發現Kubernetes能完美地實現資源層的排程和服務層的任務排程功能，也能對租戶的GPU資源和網路儲存資源進行很好的隔離。最終在AI平臺應用的層面，上汽集團也選擇了Kubernetes進行應用於落地。

AI平臺業務架構

那麼，整個AI平臺是怎麼進行業務實現的呢？從橫向的角度來看，上汽集團的AI平臺客戶分為三個層面，一是人力層面，二是算力層面，三是資料層面。資料層面將產生大量的資料，如行車交通標誌、雨天產生的大量視訊和影象，以及一些訊號資料，這些資料將被收集起來，送到算力平臺上，最終由上汽集團帆一尚行的人力分工對這些資料進行處理和訓練，最終產出一個演算法。從縱向的角度來看，平臺的人力團隊被劃分為三類，一是標註團隊，主要負責模型服務；二是演算法團隊，三是運營團隊，起到協調的作用。

AI訓練平臺邏輯框架

當帆一尚行的開發團隊和業務進行溝通之後，抽象出了AI平臺的系統邏輯框架，第一層為基礎層面，由Kubernetes和儲存構成；第二層為Service層面，包括需要排程的演算法和需要進行的資料處理；還有一個層面就是前臺的服務層，包括資料管控的流程、任務釋出等。當Kubernetes接到排程之後，將去Service的層面去排程Service模組，然後Kubernetes再把GPU資源、儲存資源分配給Service模組，Service模組進行統一的訓練和計算，最終把結果返回到前臺的使用者。

“所有這些排程的服務層的任務全部都是以映象的形式儲存在Kubernetes的映象倉庫裡面，Kubernetes在整套系統裡面起到的是多工控制的排程以及資源排程的作用。所以這個核心實際上是有底層的Kubernetes實現的。”龔瀚申補充道：“我們團隊會根據演算法團隊打包他們的算力，把它儲存在映象倉庫裡面，由他們自主地通過前端的前臺來自主地發起任務訓練。這就是Kubernetes在上汽集團AI平臺的應用。”