相比於傳統的調度系統，Kubernetes在CSI、CNI、CRI、CRD等許多可以擴展的接口上有很大提升。從生態系統上來講，Kubernetes 依託於 CNCF 社區，生態組件日趨豐富。在雲原生設計理念方面，Kubernetes 以聲明式 API爲根本，向上在微服務、Serverless、CI/CD等方面可以做更好的集成，因此不少公司開始選擇基於K8s搭建機器學習平臺。在ArchSummit全球架構師峯會（北京站）的現場，InfoQ採訪到了小米人工智能部高級軟件工程師褚向陽，聽他分享小米機器學習平臺以及基於K8s原生擴展的機器學習平臺引擎ML Engine。
2015年，現任小米人工智能部高級軟件工程師褚向陽加入了創業公司——數人云，開始進行PaaS平臺的研發，算是國內比較早的一批投身容器化PaaS平臺研發的工程師，後來去到京東廣告部，這個階段積累了一些GPU的使用經驗，爲他之後來小米做機器學習平臺打下了基礎。採訪中，褚向陽表示，相較於通用型PaaS平臺，機器學習平臺更加聚焦業務，需要對機器學習相關業務具備清晰認知，並理解困難點。在小米工作的這段時間，褚向陽參與構建和優化了小米CloudML 機器學習平臺以及ML Engine 架構。本文，褚向陽分享了他的一些實踐經驗和想法。
小米CloudML 機器學習平臺
對於機器學習平臺的定位，褚向陽套用了ABC概念圖（如下圖），並表示機器學習平臺應該處於這三者中間的支撐位置，只有機器學習平臺可以充分利用雲原生的計算能力和特性，不斷加速把數據轉化爲用戶價值的循環過程，這也是機器學習平臺真正起作用的地方。
在小米，機器學習平臺承載了圖像、NLP、聲學、搜索推薦等應用業務，各應用作爲用戶接入機器學習平臺，然後可以利用平臺提供的所有功能，比如訓練、Pipeline、模型服務等，機器學習平臺團隊對用戶提供這些能力的定義，幫助用戶更好的使用這些服務。
在這個全景圖中，核心邏輯也就是平臺接入層、模型框架層和資源管理層被抽離出來形成了ML Engine。
ML Engine 架構設計演進
據介紹，ML Engine是基於 K8s 原生擴展的新一代機器學習平臺引擎 ，在此之前，小米機器學習平臺應用了原生K8s的所有對象，比如原來的Job、Deployment、Service等，初期的CloudML架構圖如下所示：
如上圖，分佈式訓練任務主要是一組Job/Pod+SVC，模型服務主要是Deployment+SVC+Ingress。褚向陽表示，最初的架構在隊列、狀態同步，生命週期管理和調度策略層面均存在挑戰，比如隨着業務規模逐漸成熟，大部分業務訓練對分佈式提出了比較強的需求，當時雖然可以支持，但用戶體驗上不夠友好。最終，出於解決這些問題的想法，團隊開始對平臺進行改進。
團隊對可能的開源方案進行了調研，發現TF Operator的設計理念與現有想法比較吻合，但又沒有完全解決問題，因爲小米需要對多個框架做統一支持，所以團隊決定通過自研解決問題。ML Engine的主要思路則是充分利用 K8s 原生的擴展機制，包括 CRD / Webhook / Scheduling Framework 等，將機器學習平臺相關的業務模型、控制邏輯和調度策略融入到 K8s 集羣中，提供更好的生命週期管理，同時滿足高可用、穩定性和易維護性的雲原生特性。最終，ML Engine變成了由CRD、Webhock、定製調度器組成的狀態。
總結來看，ML Engine新版架構具備如下特點：
- 機器學習平臺業務的合理抽象 CRD
- 針對機器學習任務特性的定製調度器
- 公共的 validating/mutating 邏輯
- 提供統一的對外接口
褚向陽表示，整個引擎可以理解爲基於K8s原生擴展做的定製和改造，使它更適合於平臺直接把它當做機器學習能力的輸出口。舉例來說，K8s裏面可能只有Job，沒有機器學習訓練或者模型推理，但是通過ML Engine將這些能力抽象到了平臺裏面，用戶調用K8s的API或者SDK時，就可以使用定義好的模型推理和訓練能力，直接做API級別的交互。
爲什麼不直接放在K8s之上？
對K8s的改造其實也花費了團隊不少精力，但在褚向陽看來，整個社區的發展，包括Tensorflow，都在對K8s進行擴展，以保證真正把K8s用的更靈活，或者真正使用好這份擴展性，也就是雲原生的特性，可以很好地繼承雲原生的穩定性、高可用特性等。如果只是底層基於K8s，而不做任何改造，很難用好。正是基於這樣的擴展機制，開發團隊纔可以更加靈活和可靠的設計業務場景。
爲什麼不直接用K8s生態裏面的工具？
如開篇所言，K8s依託CNCF形成了豐富的開源生態，開源社區中也有很多工具可供選擇，但褚向陽表示，這些工具不會爲了機器學習一個場景調整調度策略，或者資源分配邏輯。舉例來說，深度學習和機器學習中佔據主導地位的GPU資源，在其他場景下並不常見。目前，社區在這方面比較火的項目是Kubeflow，小米也吸取了很多Kubeflow的優勢，但是爲了能給平臺向上提供統一的接口，只能把這些作爲引擎裏的關鍵組成部件。
ML Engine 對多框架的分佈式訓練支持
在小米，ML Engine訓練任務的核心用例有用戶給定訓練代碼及啓動命令(可選：定義數據及產出物)；支持選擇不同的機器學習框架及運行時環境(CPU/GPU)；下發集羣，需要支持分佈式啓動訓練，且需要遵循一定的調度優化策略等。
褚向陽表示，ML Engine訓練任務的整體流程爲：
1、發起訓練任務請求； 2、提交K8s，創建ML Train； 3、觸發ML Engine Controller； 4、根據MLTrain Spec，決定創建TF Job； 5、ML Train Code相關Spec，觸發git-sync Mutating邏輯； 6、Patch Request； 7、Pod調度； 8、識別分佈式任務，觸發framework plugins
在整個過程中，小米機器學習團隊逐漸解決了用戶接口層統一、框架狀態統一等問題。談到未來的發展方向，褚向陽表示，整體還是以解決內部需求爲主，只要內部用戶有需求，團隊都會滿足。功能上，主要考慮將計量、計費也抽象成 CRD，提供更方便的數據管理邏輯和更豐富的模型服務管理能力。 此外，與模型優化相關的項目，或者說所有可以提高效率的做法也會實時關注，並在時機成熟後積極嘗試開源。
經驗總結
在機器學習平臺搭建層面，每家公司由於背景、業務不同，所以會出現不同的做法，在褚向陽的理解中，K8s原生的擴展性、服務的可用性保證以及服務的易維護性是可取的優點，但使用時需要注意admission webhook 是把雙刃劍，建議設置過濾條件，以及處理好各框架不同版本之間的 golang 依賴等。
最後，容器也有自己的應用場景，K8s誕生之初就對無狀態應用提供了非常好的支持，無論是開發快速試用環境，還是用來跑大規模分佈式訓練的任務調度，包括雲原生的推理服務，都是非常合適的。如果希望充分發揮雲原生的特性，不但平臺層和應用層要做改造，底層的支撐平臺，包括存儲等都要爲雲原生做好準備，否則會遇到各種各樣的困難。
採訪嘉賓：
褚向陽，小米人工智能部/高級軟件工程師。2013 年畢業後加入紅帽軟件，吸收開源文化，接觸 OpenStack 和 IaaS 平臺相關技術。2015 年底開始加入容器雲創業公司，參與打造容器化的 PaaS 平臺，2018 年從京東廣告部加入小米人工智能部，負責小米機器學習平臺的建設，重點支持各個框架的分佈式訓練，訂製優化 K8s 調度，努力提高平臺用戶體驗的同時保證集羣利用率。持續關注 Kubeflow 社區及性能優化相關開源項目發展。