 本次演講從滴滴機(jī)器學(xué)習(xí)平臺的特點(diǎn)開始探討，分享了滴滴機(jī)器學(xué)習(xí)場景下的 k8s 落地實(shí)踐與二次開發(fā)的技術(shù)實(shí)踐與經(jīng)驗(yàn)，包括平臺穩(wěn)定性、易用性、利用率、平臺 k8s 版本升級與二次開發(fā)等內(nèi)容。此外，唐博還介紹了滴滴機(jī)器學(xué)習(xí)平臺是如何從 YARN 遷移到 k8s，以及 YARN 的二次開發(fā)與 k8s 的對比等。最后，唐博還分享了滴滴機(jī)器學(xué)習(xí)平臺正在研發(fā)中的功能以及對未來的展望。 2019 AI開發(fā)者大會(huì)是由中國IT社區(qū) CSDN 主辦的 AI 技術(shù)與產(chǎn)業(yè)年度盛會(huì)，2019 年 9 月 6-7 日，近百位中美頂尖 AI 專家、知名企業(yè)代表以及千余名 AI 開發(fā)者齊聚北京，進(jìn)行技術(shù)解讀和產(chǎn)業(yè)論證。 以下為唐博演講實(shí)錄，AI科技大本營（ID:rgznai100）整理： 我叫唐博，來自滴滴出行機(jī)器學(xué)習(xí)平臺，負(fù)責(zé)調(diào)度系統(tǒng)，今天分享的題目《是滴滴機(jī)器學(xué)習(xí)平臺kubernetes落地與實(shí)踐》，大概分四個(gè)部分： 一、滴滴機(jī)器學(xué)習(xí)平臺簡介 二、平臺調(diào)度系統(tǒng)的演進(jìn) 三、機(jī)器學(xué)習(xí)場景下的k8s落地實(shí)踐與二次開發(fā) 四、平臺正在開發(fā)的功能及未來展望 機(jī)器學(xué)習(xí)平臺介紹 上圖最下方是滴滴學(xué)習(xí)平臺整體提供的算力、網(wǎng)絡(luò)和存儲(chǔ)三個(gè)方面，其中算力包括 GPU、CPU，也有第三方合作廠商所提供的專用神經(jīng)網(wǎng)絡(luò)處理器；網(wǎng)絡(luò)方面我們內(nèi)部有一個(gè)高速網(wǎng)絡(luò)；存儲(chǔ)方面我們提供了分布式高性能網(wǎng)絡(luò)存儲(chǔ)?；谒懔?、網(wǎng)絡(luò)和存儲(chǔ)這三個(gè)硬件層面的基礎(chǔ)設(shè)施，我們在上面用 kubernetes 調(diào)度系統(tǒng)來進(jìn)行資源管理。 我們選擇 kubernetes 的原因很多，首先是 kubernetes 的擴(kuò)展性較好，它可以適配各種不同的網(wǎng)絡(luò)和存儲(chǔ)，且在其他方面，如調(diào)度、自定義資源、容器運(yùn)行時(shí)等方面都有很好的擴(kuò)展能力。其次，因?yàn)?kubernetes 本身給社區(qū)的紅利非常好，基于它的設(shè)計(jì)理念和提供的服務(wù)，可以更好地適用于機(jī)器學(xué)習(xí)不同的訓(xùn)練和預(yù)測場景。 基于調(diào)度層，我們平臺提供了各種對機(jī)器學(xué)習(xí)的支撐，比如高可用/負(fù)載均衡；對于不同的訓(xùn)練，滴滴自研了環(huán)狀參數(shù)服務(wù)器，實(shí)現(xiàn)是環(huán)狀算法。為了提高推理服務(wù)的性能，我們自己研發(fā)了彈性推理服務(wù)和前向框架。 當(dāng)用戶在實(shí)驗(yàn)環(huán)境里進(jìn)行代碼開發(fā)，代碼調(diào)試到一定程度時(shí)，可以把比較成熟的代碼放到我們的離線任務(wù)里進(jìn)行批量調(diào)參，或者進(jìn)行自動(dòng)調(diào)參，生成一個(gè)滿足他們業(yè)務(wù)需求的模型，并把生成的模型通過我們的前向框架和彈性推理服務(wù)，以在線的方式進(jìn)行推理。 基于這些服務(wù)，我們提供不同的深度學(xué)習(xí)和機(jī)器學(xué)習(xí)業(yè)務(wù)，包括圖像、語音、自然語言處理、知識圖譜、地圖和 AR、VR 等業(yè)務(wù)。 側(cè)面這四個(gè)是其它部門提供的對于平臺建設(shè)的支持類業(yè)務(wù)，比如智能運(yùn)維、監(jiān)控告警服務(wù)、日志收集和鏡像倉庫等，這些合起來構(gòu)成我們的機(jī)器學(xué)習(xí)平臺架構(gòu)。 平臺調(diào)度系統(tǒng)演進(jìn) 下面我們來看第二部分，滴滴機(jī)器學(xué)習(xí)平臺調(diào)度系統(tǒng)的演進(jìn)。 最開始我們選擇了 YARN，并對社區(qū)的 Application Master進(jìn)行了改造，以適合自己的機(jī)器學(xué)習(xí)場景。我們修改了 DockerContainerExecutor以更好地支持 docker 調(diào)度，并去除了其中的docker rm命令，從調(diào)度層面 100% 保證數(shù)據(jù)的可靠性。此外，修改了調(diào)度器，以支持 GPU 調(diào)度，并擴(kuò)展了 YARN API，讓管控系統(tǒng)和調(diào)度系統(tǒng)更好地結(jié)合，管控系統(tǒng)可以獲取更多調(diào)度方面的信息。然而，隨著業(yè)務(wù)的逐漸發(fā)展，以及業(yè)務(wù)線和業(yè)務(wù)形態(tài)的多樣化，我們發(fā)現(xiàn) YARN無法滿足我們的需求，于是，我們從 2017 年開始向 kubernetes 遷移。 對于我們來說，kubernetes 相比于 YARN，在擴(kuò)展性、CSI、CNI、CRI、CRD、調(diào)度等許多其他可以擴(kuò)展的接口上有很大的提升。從生態(tài)系統(tǒng)上來講，kubernetes 依托 CNCF 社區(qū)，專注于云計(jì)算領(lǐng)域，更加契合我們的場景。而 YARN 依托 Apache 社區(qū)，主要是大數(shù)據(jù)領(lǐng)域。云原生設(shè)計(jì)理念方面，kubernetes 以聲明式 API為根本，向上在微服務(wù)、serverless、持續(xù)集成交付等方面可以做更好的集成，這也是我們從YARN 向 kubernetes 遷移的重要原因。 右圖是 CNCF 項(xiàng)目全景圖，包括存儲(chǔ)、網(wǎng)絡(luò)、容器進(jìn)行時(shí)、調(diào)度、監(jiān)控等諸多方面，云計(jì)算領(lǐng)域應(yīng)該有的開源項(xiàng)目都包含在其中，包括 Spark 這一子項(xiàng)目。大勢所趨，我們決定從 YARN 向kubernetes 遷移。 機(jī)器學(xué)習(xí)場景下的k8s落地實(shí)踐與二次開發(fā) 第三點(diǎn)，是關(guān)于滴滴機(jī)器學(xué)習(xí)場景下的 k8s 落地實(shí)踐與二次開發(fā)。 滴滴機(jī)器學(xué)習(xí)平臺的主要特點(diǎn)是給用戶提供三種環(huán)境，實(shí)驗(yàn)環(huán)境、離線任務(wù)、在線服務(wù)。實(shí)驗(yàn)環(huán)境主要是用戶可以登陸里面，進(jìn)行代碼開發(fā)、調(diào)試、修改版本等。離線服務(wù)是在代碼基本成型之后進(jìn)行批量訓(xùn)練調(diào)參，并生成模型。在線服務(wù)是使用生成的模型進(jìn)行預(yù)測。 下面將就平臺要考慮易用性、利用率、穩(wěn)定性這三個(gè)方面進(jìn)行 k8s 落地實(shí)踐與二次開發(fā)的相關(guān)介紹。 易用性 首先是易用性，平臺給用戶提供了扁平網(wǎng)絡(luò)，最開始是使用的是sriov 網(wǎng)絡(luò)，給用戶環(huán)境分配一個(gè) IP，用戶通過管控系統(tǒng)頁面登陸實(shí)驗(yàn)環(huán)境。但是，后來隨著公司整體網(wǎng)絡(luò)架構(gòu)演進(jìn)，一方面需要更加靈活的網(wǎng)絡(luò)配置，另一方面需要更強(qiáng)的隔離性，平臺改為使用公司內(nèi)部的SDN，使得配置更靈活，隔離更強(qiáng)，容災(zāi)之后 IP 不變，且可以指定 IP。這一方面是為了給用戶更好的用戶體驗(yàn)，另一方面是如果將內(nèi)部調(diào)度系統(tǒng)和其他系統(tǒng)，如數(shù)據(jù)庫、分布式緩存系統(tǒng)等進(jìn)行打通，我們需要有一個(gè)白名單功能，而 IP 不變會(huì)方便我們進(jìn)行白名單打通。 這是網(wǎng)絡(luò)方面調(diào)度易用性的相關(guān)介紹。接下來是存儲(chǔ)方面。 最主要的是中間黃色部分，我們給用戶提供了一個(gè)分布式的基于 SSD 盤的 GlusterFS 分布式存儲(chǔ)系統(tǒng)，用戶可以用他們的項(xiàng)目和個(gè)人 IP 訪問存儲(chǔ)空間。但是因?yàn)?GlusterFS 空間不大，我們還提供了 HDFS，用戶可以把一些較冷的數(shù)據(jù)放到 HDFS 里，可以多存儲(chǔ)一些。除此之外，用戶在使用過程中，如果想編譯一些小文件較多的框架，網(wǎng)絡(luò)存儲(chǔ)的性能并不能滿足他們的需求，所以，基于用戶需求和硬件環(huán)境，我們提供第三種存儲(chǔ)方式，在本機(jī)節(jié)點(diǎn)上隔出來一塊盤，基于local PV提供本機(jī)緩存。 local PV本身有兩個(gè)特點(diǎn)，一是適用高吞吐場景，二是只存在于一個(gè)node 節(jié)點(diǎn)上，不保證數(shù)據(jù)的可靠性。關(guān)于 local PV 比較典型的使用樣例是 Uber 提出來的，Uber的M3DB 把數(shù)據(jù)進(jìn)行分片，每一個(gè)分片復(fù)制三份，每一份是一個(gè) local PV，相當(dāng)于把數(shù)據(jù)可靠性功能做到分布式數(shù)據(jù)系統(tǒng)這一層，所以緩解了 local PV 本身數(shù)據(jù)不可靠的缺陷。 但是對于我們來說，提供 local PV 功能是為了讓用戶可以更好地編譯而提供緩存，并不需要保證可靠性，只是提供為了高速存儲(chǔ)。 我們對 local PV 的代碼進(jìn)行了修改，如果在K8S的yaml文件里面寫了一個(gè) node 節(jié)點(diǎn)上不存在的目錄，它會(huì)自動(dòng)創(chuàng)建該目錄，因?yàn)槲覀兊恼{(diào)度系統(tǒng)只能從管控系統(tǒng)來進(jìn)行 PV 創(chuàng)建，所以安全性可以得到保障。 總的來說，如右圖中所示，我們提供了三種不同存儲(chǔ)，從上到下磁盤空間越來越大，從下到上性能逐漸提升。 接下來是易用性方面的輔助性功能。我們修改了調(diào)度的代碼， 對docker根目錄大小進(jìn)行了限制。最開始docker存儲(chǔ)區(qū)驅(qū)動(dòng)是devicemapper，后來隨著版本升級變成了overlay2，物理機(jī)我們是 xfs 系統(tǒng)，我們用xfs quota功能限制 docker 根目錄大小，保證物理機(jī)磁盤足夠用，以及 harbor 磁盤不被占滿。 第二個(gè)輔助性功能是增加正在使用的 GPU，APIserver 返回 GPU，kubelet 獲取 container 正在使用的 GPU，返回給 apiserver。 這是滴滴自研前向框架加上滴滴自研的 serving框架，是為了提高inference的性能。kube-proxy在這個(gè)場景下會(huì)增加一層額外的iptables或者ipvs，我們直接使用了 LVS 對接后面的 Pod IP，類似 ingress，不過是 EIP 對接 Pod IP。我們的目的是為了可以給用戶提供更好的前向預(yù)測性能。 利用率
利用率方面，首先介紹共享 GPU。目前我們了解到，社區(qū)和友商也提出了一些共享 GPU 的方案，其中可能比較著名的是 GPU share device plugin，加上 GPU 共享的 scheduler extender解決方案，這種解決方案的特點(diǎn)是，它更適合于 serving 前向推理步驟或者代碼調(diào)試，同時(shí)需要限制顯存。第二個(gè)開源方案是 Fractional GPU，提供強(qiáng)隔離，目前還處于研發(fā)階段，只支持 Caffe 一種框架，如果要適配更加普適性的框架，還需要自己對接開發(fā)。第三個(gè)是社區(qū)同學(xué)提供的 Multiple device plugin 方案，一個(gè) GPU 會(huì)上報(bào)多次，也是需要限制顯存。 我們的機(jī)器學(xué)習(xí)平臺提供的方法與以上友商和社區(qū)的方法有很多相似之處，比如共享 GPU 的方案，我們修改了代碼，允許多個(gè) docker 共同使用一個(gè) GPU，并且hook 了cuMemAlloc 等一系列函數(shù)進(jìn)行顯存限制。后來，隨著業(yè)務(wù)的演進(jìn)，我們的實(shí)驗(yàn)環(huán)境讓用戶可以進(jìn)行任何實(shí)驗(yàn)，這時(shí)有些用戶會(huì)偶爾做一些破壞性的工作，docker 這種軟隔離對他們的限制作用有限，所以我們就采用了英偉達(dá)最新提出的 vGPU KVM 供用戶使用。
接下來是調(diào)度方面，我們根據(jù)用戶的使用習(xí)慣提供了不同套餐的離線任務(wù)和實(shí)驗(yàn)環(huán)境，比如只有一個(gè) GPU 的一卡離線任務(wù)和有四個(gè) GPU 的四卡離線任務(wù)，在這種套餐化的場景下，會(huì)產(chǎn)生一個(gè)問題，即資源的碎片化，所以我們用了調(diào)度策略，通過配置優(yōu)先級函數(shù)，實(shí)現(xiàn)緊湊調(diào)度。如右圖所示，下面四個(gè)是節(jié)點(diǎn)，分別運(yùn)行了兩個(gè)1卡 GPU，還有三個(gè)。第二個(gè)和第三個(gè)1卡離線任務(wù)也是同樣調(diào)度到第一個(gè)節(jié)點(diǎn)上，第一個(gè)節(jié)點(diǎn) GPU 目前使用率是集群中使用的第二個(gè)，這時(shí)通過緊湊調(diào)度，我們會(huì)把第三個(gè)節(jié)點(diǎn)的離線任務(wù)分配給四卡，充分調(diào)度空閑機(jī)器。 除此之外，根據(jù)用戶的使用情況，滴滴機(jī)器學(xué)習(xí)平臺里除了有 GPU 的任務(wù)，也有不使用 GPU 的純 CPU 離線任務(wù)，結(jié)合物理機(jī)內(nèi)存和顯存的比例情況，除了提供 GPU 離線任務(wù)之外，我們把每臺物理機(jī)隔出一塊資源提供給 CPU 離線任務(wù)，把 CPU 任務(wù)盡量打散，避免影響重要的GPU 任務(wù)。另外一點(diǎn)是緊湊調(diào)度函數(shù)，社區(qū)自帶的MostRequestedPriority函數(shù)只適用于 CPU 和內(nèi)存，不支持其他的擴(kuò)展資源，比如 GPU，所以我們對緊湊調(diào)度優(yōu)先級函數(shù)進(jìn)行修改，讓它可以支持?jǐn)U展資源。 為了提升用戶體驗(yàn)和進(jìn)一步提高利用率，我們對k8s 在調(diào)度上進(jìn)行了改進(jìn)。
當(dāng)資源占有率非常高時(shí)，如果用戶還沒有高優(yōu)先級的任務(wù)，就只能讓一些緊急任務(wù)搶占資源。但是在搶占的同時(shí)，我們也希望高優(yōu)先級的任務(wù)到來時(shí)，對集群現(xiàn)有任務(wù)所造成的傷害和影響最小，所以，我們?yōu)閾屨嫉倪^程加入了一個(gè)按照離線任務(wù)和 Pod 啟動(dòng)時(shí)間先后順序來進(jìn)行排序的功能。我們在第二步生成每個(gè) node 上可以被搶占的 Pod進(jìn)行了改進(jìn)，加入了啟動(dòng)時(shí)間。在第四步，社區(qū)的算法是遍歷每個(gè) node 上比當(dāng)前 Pod 優(yōu)先級低的 Pod，加入 potential victims。將 potential victims 按照優(yōu)先級排序，同優(yōu)先級下按照時(shí)間排序。如果第一條不能選出最合適的 node 就進(jìn)行下一條，依次進(jìn)行。 首先選擇違反 PDB 最小的節(jié)點(diǎn)。如果第一條就選不出來，第二條從所有可以被搶占的最高優(yōu)先級Pod中選出優(yōu)先級最低那個(gè)Pod所在的節(jié)點(diǎn)，接著是優(yōu)先級之和最小的節(jié)點(diǎn)，個(gè)數(shù)最少的節(jié)點(diǎn)，最高優(yōu)先級的 Pod 中啟動(dòng)時(shí)間最晚的節(jié)點(diǎn)。我們發(fā)現(xiàn)友商也有這個(gè)需求，后來我們和友商一起把這個(gè)方案貢獻(xiàn)給社區(qū)。 穩(wěn)定性
下面我們來看看穩(wěn)定性方面。因?yàn)榉€(wěn)定性對于任何一個(gè)平臺級的產(chǎn)品和應(yīng)用來說都是必不可少的，針對穩(wěn)定性我們也做了或大或小的參數(shù)調(diào)整和二次開發(fā)，我將分別從運(yùn)行穩(wěn)定性、數(shù)據(jù)穩(wěn)定性和升級穩(wěn)定性三個(gè)方面來講解。 運(yùn)行穩(wěn)定性，我們調(diào)大 pod 驅(qū)逐時(shí)間和節(jié)點(diǎn)監(jiān)控時(shí)間，一方面是為了更好地應(yīng)對內(nèi)部網(wǎng)絡(luò)抖動(dòng)，超時(shí)調(diào)大之后可以扛住更大的抖動(dòng)；另一方面也是為了便于運(yùn)維操作，如果一個(gè)機(jī)器掛掉，運(yùn)維組的同學(xué)有足夠的時(shí)間來恢復(fù)腳本，把集群恢復(fù)到之前的狀態(tài)，并把這些 pod 的 IP 也配置成之前的狀態(tài)，讓用戶感覺除了重啟之外沒有其他變化。 數(shù)據(jù)穩(wěn)定性，我們?nèi)コ?docker rm 命令，防止異常情況下數(shù)據(jù)丟失，在調(diào)度層面確保數(shù)據(jù)不丟。 升級穩(wěn)定性，去除了 container hash 檢查，去除了 kubelet 創(chuàng)建環(huán)境變量時(shí)對 pod.Spec.Enable service Links 的檢查，使Pod在升級時(shí)不會(huì)重啟。社區(qū)相關(guān)PR從1.16起升級才管用。 同時(shí)我們關(guān)閉了TaintBasedEviction，使pod 在升級時(shí)不會(huì)被驅(qū)逐。 平臺正在開發(fā)的功能及未來展望
最后是關(guān)于平臺正在開發(fā)的功能以及機(jī)器學(xué)習(xí)相關(guān)的未來展望。 我們正在進(jìn)行中的功能開發(fā)主要有調(diào)度器、再調(diào)度器，以及我們自己的 device plugin。
首先是調(diào)度器，基于社區(qū)的新的調(diào)度框架，調(diào)度分為不同的階段，每個(gè)階段都是一個(gè)擴(kuò)展點(diǎn)，用戶可以在這些擴(kuò)展點(diǎn)實(shí)現(xiàn)自己的插件和需要的功能。我們正在做的是 Filter 定制，Post-bind定制，并且與監(jiān)控打通和任務(wù)畫像。
再調(diào)度器的主要目的是防止集群中的資源碎片化，比如上圖的集群中分別有一、二、三不同個(gè)數(shù)一卡離線任務(wù)，如果有四卡離線任務(wù)到來，會(huì)對這個(gè)節(jié)點(diǎn)形成搶占，一卡離線任務(wù)之前運(yùn)行的一些流程就被迫中斷了，或者如果模型沒有保存就沒用了。我們做再調(diào)度器是為了提前發(fā)現(xiàn)這種狀況，和監(jiān)控系統(tǒng)打通，通過再調(diào)度器來驅(qū)逐一卡離線任務(wù)，讓它重新通過調(diào)度器的緊湊調(diào)度，調(diào)度到這臺機(jī)器上，這樣就可以提前空出機(jī)器，供后續(xù)的四卡離線任務(wù)使用。但是，這也涉及到當(dāng)前正在運(yùn)行的異卡離線任務(wù)啟動(dòng)時(shí)間，以及任務(wù)的特征刻畫。舉例來說，驅(qū)逐一個(gè)卡運(yùn)行 30 分鐘還是驅(qū)逐兩個(gè)卡運(yùn)行 20 分鐘，都是我們需要考慮的問題。
此外，我們也在開發(fā) device plugin，以實(shí)現(xiàn)實(shí)驗(yàn)環(huán)境和離線任務(wù)的混合調(diào)度，但暫時(shí)不便透露太多信息。
未來，我們希望借助 k8s 提供多機(jī)多卡服務(wù)，現(xiàn)在多機(jī)多卡是在管控這一層實(shí)現(xiàn)的，我們希望放到調(diào)度這一層，以更好地利用 k8s 的調(diào)度能力，為用戶提供更好的體驗(yàn)，打造一站式機(jī)器學(xué)習(xí)平臺。同時(shí)也把更多大數(shù)據(jù)任務(wù)放到這個(gè)平臺上，比如 Spark等。以及提供更好的在離線混合調(diào)度，來進(jìn)一步提高集群的資源分配率和利用率。 目前，滴滴機(jī)器學(xué)習(xí)平臺著力發(fā)展公有云，讓機(jī)器學(xué)習(xí)平臺不但在內(nèi)部使用，也可以提供給更多外部同行使用。
再細(xì)一點(diǎn)講，希望可以為從硬件選型到基礎(chǔ)設(shè)施，到整個(gè)上層軟件棧，提供一個(gè)內(nèi)外統(tǒng)一的架構(gòu)，減少內(nèi)外兩部分的重復(fù)性工作。比如針對上圖中底部的 IaaS 和Paas層，我們希望提供內(nèi)外統(tǒng)一的資源，如機(jī)器學(xué)習(xí)平臺簡樞、算法市場、模型市場、數(shù)據(jù)市場等，基于這些底層服務(wù)，在 SaaS 層提供人臉、語音、自然語言處理和智能視頻識別和其他圖像、地圖服務(wù)。
現(xiàn)在，滴滴機(jī)器學(xué)習(xí)平臺已經(jīng)在滴滴公有云平臺上，上圖為架構(gòu)圖，如果想了解詳細(xì)內(nèi)容可以訪問網(wǎng)站。 演講嘉賓： 唐博，滴滴出行資深軟件工程師，曾就職于高盛美國、高盛香港，現(xiàn)就職于滴滴出行，負(fù)責(zé)機(jī)器學(xué)習(xí)平臺調(diào)度系統(tǒng)，是kubernetes, istio, kubeflow, alluxio等開源項(xiàng)目的代碼貢獻(xiàn)者。 （*本文為AI科技大本營整理文章 |
|
|
