Kubernetes在上汽集團雲平臺及AI方面的應用

帆一尚行成立於2015年，是上汽集團的全資子公司，建設有上海、南京、鄭州（在建）三個數據中心，擁有超過4000臺物理服務器，10PB的數據存儲，總面積將近9000平米。

帆一尚行主要爲用戶提供彈性計算、存儲網絡、大數據、人工智能、安全等雲產品及服務，並提供車聯網、物聯網、整車等行業解決方案。截至目前，已服務了上汽集團集團本部、上汽乘用車、上汽大通、吉安物流、賽客出行等40餘家汽車企業。

2018年11月13日，由Rancher Labs、華爲、CNCF聯合主辦的KubeCon + CloudNativeCon 的同場活動——雲原生服務網格（Istio）企業峯會在上海隆重舉行，上汽集團帆一尚行業務發展部總經理龔瀚申在峯會上進行了主題演講，分享了上汽集團如何在利用Kubernetes的強大能力的同時，下降系統的使用門檻，使得Kubernetes技術可以多樣化的知足不一樣技術水平用戶的使用需求，而且利用Kubernetes的強大能力支撐人工智能等新興業務。

---

發展背景

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

當企業將業務部署到雲端以後，這樣的狀況便會獲得相應的改善，除了下降總體的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集羣與上汽集團帆一尚行的用戶界面是集成的，用戶能夠經過登陸Saicmotor的門戶網站直接使用上汽集團帆一尚行的Kubernetes集羣，或者是經過上汽集團帆一尚行周邊的雲平臺產品如應用開發日誌、日誌管理等來進行對Kubernetes集羣進行管控。而上汽集團帆一尚行的運維人員則是經過Rancher的管理界面來管理底層的Kubernetes集羣。

「關於Kubernetes應該怎樣以產品的方式提供給用戶，咱們也進行了一些場景化的思考。有人會將Kubernetes看成是數據中心的管控系統，有人會將它做爲是任務調度的管理系統，還會有人將Kubernetes看成是微服務的一個治理框架，在不一樣的而場景下，你們對Kubernetes的定義是不同的。」龔瀚申分析：「這一切就是源於Kubernetes它開放的多維度框架設計理念以及簡單易用的產品特性，因此咱們將它理解爲一個可擴展、可組合的調度系統框架。」

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

AI應用

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

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

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

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

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

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

「全部這些調度的服務層的任務所有都是以鏡像的形式存儲在Kubernetes的鏡像倉庫裏面，Kubernetes在整套系統裏面起到的是多任務控制的調度以及資源調度的做用。因此這個核心其實是有底層的Kubernetes實現的。」龔瀚申補充道：「咱們團隊會根據算法團隊打包他們的算力，把它存儲在鏡像倉庫裏面，由他們自主地經過前端的前臺來自主地發起任務訓練。這就是Kubernetes在上汽集團AI平臺的應用。」