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

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

當企業將業務部署到云端之后，這樣的情況便會得到相應的改善，除了降低整體的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平臺的應用。”