[[382903]]

【編者的話】2018年1月OpenAI官方博客稱，他們已將Kubernetes集群擴(kuò)展到2500個(gè)節(jié)點(diǎn)。時(shí)隔三年，在2021年1月，OpenAI官方博客再度宣布Kubernetes集群擴(kuò)展到7500個(gè)節(jié)點(diǎn)，目前不僅可以滿足GPT-3、CLIP 和DALL·E等大型模型的需求，而且也可以服務(wù)于快速的小規(guī)模迭代研究。下面文章來(lái)自于OpenAI官方博客，描述了走向這個(gè)7500節(jié)點(diǎn)規(guī)模過(guò)程中遇到的問(wèn)題和解決辦法，以及對(duì)于未來(lái)走向的暢想。

我們的Kubernetes集群規(guī)模已經(jīng)上升到7,500個(gè)節(jié)點(diǎn)，主要為諸如GPT-3、CLIP和DALL·E等大型訓(xùn)練模型提供可擴(kuò)展的基礎(chǔ)架構(gòu)，而且還可用于小規(guī)模快速迭代研究，例如神經(jīng)語(yǔ)言模型的標(biāo)度律等。將單個(gè)Kubernetes集群擴(kuò)展到如此規(guī)模很難完成，同時(shí)在這個(gè)過(guò)程中需要格外小心。但好處是借助這種簡(jiǎn)單的基礎(chǔ)架構(gòu)使得我們的機(jī)器學(xué)習(xí)研究團(tuán)隊(duì)無(wú)需更改其代碼就可以快速擴(kuò)容。

自上一篇有關(guān)擴(kuò)展到2,500個(gè)節(jié)點(diǎn)的文章發(fā)表以來(lái)，我們一直在不斷擴(kuò)展基礎(chǔ)架構(gòu)以滿足研究人員的需求，在此過(guò)程中我們還學(xué)到了很多經(jīng)驗(yàn)。這篇文章對(duì)此作了總結(jié)，以便Kubernetes社區(qū)共同受益，最后介紹我們?nèi)匀灰鎸?duì)的問(wèn)題以及解決辦法探討。

工作負(fù)載

在我們深入討論之前，介紹一下我們的工作負(fù)載是很重要的。我們運(yùn)行Kubernetes軟硬件和您在公司的情況可能不太一樣。我們的問(wèn)題和相應(yīng)的解決方案可能是，也可能不是，也請(qǐng)您視情況而應(yīng)用!

大型機(jī)器學(xué)習(xí)作業(yè)跨越許多節(jié)點(diǎn)，并且只有當(dāng)可以訪問(wèn)每個(gè)節(jié)點(diǎn)上的所有硬件資源時(shí)，才能最大化運(yùn)行效率。如此一來(lái)，GPU就可以通過(guò) NVLink直接進(jìn)行交叉通信，或者GPU也可以通過(guò)GPUDirect直接與NIC通信。因此，對(duì)于我們的許多工作負(fù)載，一個(gè)節(jié)點(diǎn)上只放置一個(gè)Pod。任何NUMA、CPU或PCIE資源爭(zhēng)用都不是調(diào)度的因素，因此裝箱調(diào)度或碎片化不是一個(gè)常見(jiàn)的問(wèn)題。我們現(xiàn)有的集群擁有完整的對(duì)分帶寬，因此也無(wú)需考慮任何機(jī)架或網(wǎng)絡(luò)拓?fù)洹Ｋ羞@些都表明，我們的Kubernetes擁有許多節(jié)點(diǎn)，但是調(diào)度的壓力相對(duì)較低。

不過(guò)，kube-scheduler上經(jīng)常會(huì)出現(xiàn)峰值壓力。一個(gè)新的Job可能包含數(shù)百個(gè)一次性創(chuàng)建的Pod，但具有較低的使用率。

我們最大的Job上運(yùn)行著 MPI 協(xié)議(消息傳遞接口協(xié)議)，該Job內(nèi)的所有Pod都加入了同一個(gè)MPI通信器。如果某個(gè)Pod宕機(jī)，則整個(gè)Job都將暫停，需要重新啟動(dòng)。我們會(huì)定期保存檢查點(diǎn)，Job重啟時(shí)會(huì)從上一個(gè)檢查點(diǎn)恢復(fù)。因此，可以認(rèn)為Pod是半狀態(tài)化的，終止的Pod可以被替換掉，而且Job還可以繼續(xù)，但是這種做法會(huì)干擾正常的Job，應(yīng)盡量減少。

由于HTTPS通道流量很少，也不需要進(jìn)行A/B測(cè)試、藍(lán)/綠或金絲雀部署，我們沒(méi)有完全依賴Kubernetes進(jìn)行負(fù)載均衡。Pod之間通過(guò)SSH(而不是服務(wù)端點(diǎn))，利用IP地址直接通過(guò)MPI相互通信。我們的服務(wù)“發(fā)現(xiàn)”功能很有限，一般只需要在Job啟動(dòng)的時(shí)候執(zhí)行一次查找去找到MPI中的Pod。

我們的大多數(shù)Job都使用了某種形式的Blob存儲(chǔ)。通常，它們會(huì)直接從Blob存儲(chǔ)，以流的形式讀取數(shù)據(jù)及或檢查點(diǎn)的某些分片，或?qū)⑵渚彺娴脚R時(shí)的本地磁盤。在需要POSIX語(yǔ)義的時(shí)候，我們也使用了一些持久卷，但是Blob存儲(chǔ)更容易擴(kuò)展，而且不需要緩慢的分離/附加操作。

最后要提醒，我們的工作大多是基于研究性質(zhì)的，這意味著負(fù)載本身在不斷變化。盡管超算團(tuán)隊(duì)努力提供了生產(chǎn)級(jí)別的計(jì)算基礎(chǔ)架構(gòu)，但集群上運(yùn)行的應(yīng)用程序的生命周期很短，而且開(kāi)發(fā)人員的迭代非?？?。新的使用模式隨時(shí)可能出現(xiàn)，因此我們很難預(yù)料發(fā)展趨勢(shì)，并做出適當(dāng)?shù)恼壑?。我們需要一個(gè)可持續(xù)發(fā)展的系統(tǒng)，以便在事情發(fā)生變化時(shí)迅速做出響應(yīng)。

網(wǎng)絡(luò)

由于集群內(nèi)的Node數(shù)和Pod數(shù)不斷增長(zhǎng)，我們發(fā)現(xiàn)Flannel難以擴(kuò)展到所需的吞吐量。于是，我們轉(zhuǎn)而使用原生Pod網(wǎng)絡(luò)技術(shù)來(lái)管理Azure VMSSes的IP配置和相關(guān)的CNI插件。這樣我們的Pod就能夠獲得宿主級(jí)別的網(wǎng)絡(luò)吞吐。

我們最大的集群上大約有20萬(wàn)個(gè)IP地址正在使用中，在測(cè)試基于路由的Pod網(wǎng)絡(luò)時(shí)，我們發(fā)現(xiàn)可以有效利用的路由數(shù)量受到了嚴(yán)重限制。因此我們改用基于別名的IP尋址。

避免封裝增加了對(duì)底層SDN或路由引擎的要求，但它使我們的網(wǎng)絡(luò)設(shè)置保持簡(jiǎn)單。無(wú)需任何額外的適配器就可以添加隧道。我們不需要擔(dān)心數(shù)據(jù)包分片，因?yàn)榫W(wǎng)絡(luò)的某些部分MTU較低。網(wǎng)絡(luò)策略和流量監(jiān)控也很簡(jiǎn)單;數(shù)據(jù)包的源和目的地不存在歧義。

我們?cè)谒拗魃鲜褂胕ptables來(lái)跟蹤每個(gè)命名空間和Pod上網(wǎng)絡(luò)資源的使用情況。這樣研究人員就可以可視化網(wǎng)絡(luò)的使用情況。具體來(lái)說(shuō)，因?yàn)樵S多實(shí)驗(yàn)的互聯(lián)網(wǎng)和Pod間通信都有獨(dú)特的模式，所以能夠調(diào)查何處可能出現(xiàn)瓶頸是非常必要的。

iptables的mangle規(guī)則可以給任何符合特定規(guī)則的數(shù)據(jù)包做標(biāo)記。我們采用了以下規(guī)則來(lái)檢測(cè)流量屬于內(nèi)部還是發(fā)向外網(wǎng)。FORWARD規(guī)則負(fù)責(zé)Pod間的流量，而INPUT和OUTPUT負(fù)責(zé)來(lái)自宿主的流量：

iptables -t mangle -A INPUT ! -s 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-in" 
iptables -t mangle -A FORWARD ! -s 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-in" 
iptables -t mangle -A OUTPUT ! -d 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-out" 
iptables -t mangle -A FORWARD ! -d 10.0.0.0/8 -m comment --comment "iptables-exporter  

做好標(biāo)記后，iptables就會(huì)統(tǒng)計(jì)符合該規(guī)則的數(shù)據(jù)包的字節(jié)數(shù)。使用iptables命令就可以看到這些統(tǒng)計(jì)結(jié)果：

% iptables -t mangle -L -v 
Chain FORWARD (policy ACCEPT 50M packets, 334G bytes) 
pkts bytes target     prot opt in     out     source               destination 
.... 
1253K  555M            all  --  any    any     anywhere            !10.0.0.0/8           /* iptables-exporter openai traffic=internet-out */ 
1161K 7937M            all  --  any    any    !10.0.0.0/8           anywhere     

我們使用了一個(gè)名為 iptables-exporter 的開(kāi)源 Prometheus 導(dǎo)出程序，將這些跟蹤信息導(dǎo)出到監(jiān)控系統(tǒng)中。這樣就可以直接跟蹤符合各種條件的數(shù)據(jù)包了。

我們的網(wǎng)絡(luò)模型的獨(dú)特之處在于，Node、Pod和服務(wù)網(wǎng)絡(luò)的CIDR范圍是完全暴露給研究者的。網(wǎng)絡(luò)采用了輪輻模型，使用原生節(jié)點(diǎn)和Pod的CIDR范圍進(jìn)行路由。研究者連接到中央樞紐，從那里可以訪問(wèn)到任何集群。但是兩個(gè)集群之間不能互相通信。這樣可以保證每個(gè)集群都是隔離的，不會(huì)出現(xiàn)跨集群依賴(否則會(huì)破壞故障隔離原則)。

我們使用一個(gè)“NAT”宿主對(duì)來(lái)自集群外部的流量進(jìn)行CIDR范圍轉(zhuǎn)譯。這種結(jié)構(gòu)可以讓研究人員自由地選擇使用何種網(wǎng)絡(luò)配置以及怎樣使用，以滿足實(shí)驗(yàn)的需要。

API Servers

對(duì)于健康工作的集群來(lái)講， API Servers和etcd是Kubernetes的關(guān)鍵組件，所以我們特別關(guān)注這些組件。我們采用了kube-prometheus提供的Grafana儀表板，以及自己設(shè)計(jì)的儀表板。我們發(fā)現(xiàn)，針對(duì)API Servers上發(fā)生的HTTP 429(Too Many Requests)和5xx(Server Error)發(fā)送高級(jí)別報(bào)警非常有效。

雖然許多人在Kubernetes內(nèi)部運(yùn)行API Servers，但我們選擇了在集群外部運(yùn)行。etcd和API Servers都運(yùn)行在獨(dú)立的節(jié)點(diǎn)上。最大的集群運(yùn)行了5個(gè)API Servers和5個(gè)etcd節(jié)點(diǎn)，并以分散負(fù)載減小宕機(jī)造成的影響。自從將Kubernetes Events分離到單獨(dú)的etcd集群上以后，就再也沒(méi)有出現(xiàn)過(guò)因etcd問(wèn)題導(dǎo)致的故障。API Servers是無(wú)狀態(tài)的，因此只需要運(yùn)行一個(gè)自我修復(fù)的實(shí)例組或scaleset就可以。我們沒(méi)有嘗試過(guò)針對(duì)etcd集群構(gòu)建自我修復(fù)自動(dòng)化，因?yàn)樗鼧O少出故障。

API Servers占用的內(nèi)存相當(dāng)多，而且內(nèi)存占用會(huì)隨著集群中的節(jié)點(diǎn)數(shù)量增加而呈線性增長(zhǎng)。對(duì)于我們擁有7500節(jié)點(diǎn)的集群，每個(gè)API Servers上的堆空間占用最多為70GB，還好這依然在硬件能夠承受的范圍內(nèi)。

API Servers上比較大的壓力之一就是端點(diǎn)上的WATCH。有幾個(gè)服務(wù)的服務(wù)對(duì)象是集群中的所有成員，如kubelet、node-exporter等。每當(dāng)集群中添加或刪除節(jié)點(diǎn)時(shí)，就會(huì)觸發(fā)WATCH。而且由于每個(gè)節(jié)點(diǎn)自身都會(huì)通過(guò)kube-proxy監(jiān)視kubelet服務(wù)，這些服務(wù)的響應(yīng)數(shù)量和所需帶寬就會(huì)呈N^2增長(zhǎng)，大約每秒增加1 GB。Kubernetes 1.17中發(fā)布的EndpointSlices極大地緩解了這個(gè)壓力，它將負(fù)載降低了1000倍。

一般而言，我們會(huì)注意任何API Servers請(qǐng)求數(shù)量隨著集群大小而變化的情況。我們會(huì)盡量避免讓任何DaemonSet與API Servers交流。如果需要讓每個(gè)節(jié)點(diǎn)監(jiān)控變化，那么引入中間緩存服務(wù)(如DatadogCluster Agent)或許是避免集群范圍瓶頸的好辦法。

隨著集群的增長(zhǎng)，我們的自動(dòng)伸縮越來(lái)越少了。但偶爾也會(huì)出現(xiàn)大幅自動(dòng)伸縮的情況。新的節(jié)點(diǎn)加入集群會(huì)產(chǎn)生許多請(qǐng)求，而一次性增加幾百個(gè)節(jié)點(diǎn)會(huì)超過(guò)API Servers能夠承受的容量。平滑請(qǐng)求速度，甚至僅僅增加幾秒鐘，就可以有效地避免這個(gè)問(wèn)題。

使用Prometheus和Grafana測(cè)量時(shí)序列度量

我們使用Prometheus收集時(shí)序列度量，利用Grafana繪制成圖表、顯示儀表板并生成警告。首先我們部署了kube-prometheus來(lái)收集各種度量和可視化的儀表板。隨著時(shí)間的推移，我們已經(jīng)添加了許多我們自己的儀表板、指標(biāo)和警報(bào)。

隨著節(jié)點(diǎn)越來(lái)越多，我們逐漸難以理解Prometheus收集到的度量。盡管kube-prometheus公開(kāi)了許多非常有用的數(shù)據(jù)，但有些數(shù)據(jù)我們并不需要，而有些數(shù)據(jù)過(guò)于細(xì)致，很難收集、存儲(chǔ)和有效地查詢。因此我們使用Prometheus 規(guī)則“放棄”了一些度量。

長(zhǎng)期以來(lái)，有一個(gè)問(wèn)題一直困擾我們：Prometheus消耗的內(nèi)存越來(lái)越多，最終由于內(nèi)存耗盡而崩潰。即使給Prometheus提供大量的內(nèi)存也無(wú)濟(jì)于事。更糟糕的是，每當(dāng)出現(xiàn)崩潰，它就需要花費(fèi)好幾個(gè)小時(shí)重新執(zhí)行預(yù)寫式日志(write-ahead log)文件，之后才能正常使用。

最后我們研究了Prometheus的源代碼，發(fā)現(xiàn)內(nèi)存耗盡是由于Grafana和Prometheus之間的交互導(dǎo)致的，Grafana會(huì)使用Prometheus上的/api/v1/series這個(gè)API，進(jìn)行{le!=""}的查詢(含義是“獲取所有直方圖的度量”)。而/api/v1/series的實(shí)現(xiàn)在運(yùn)行時(shí)間和空間上都沒(méi)有任何限制，如果查詢結(jié)果過(guò)多，就會(huì)消耗越來(lái)越多的內(nèi)存和時(shí)間。即使請(qǐng)求者放棄請(qǐng)求并關(guān)閉連接，查詢也會(huì)繼續(xù)執(zhí)行。對(duì)于我們的情況而言，無(wú)論多少內(nèi)存都不夠，Prometheus最終總會(huì)崩潰。于是，我們給Prometheus打了補(bǔ)丁，將這個(gè)API包裹在一個(gè)Context中以實(shí)現(xiàn)超時(shí)，終于修復(fù)了該問(wèn)題。

雖然Prometheus的崩潰次數(shù)大大減少了，但我們依然需要經(jīng)常重啟，因此預(yù)寫式日志(簡(jiǎn)稱WAL)的重新執(zhí)行依然是一個(gè)問(wèn)題。重新執(zhí)行所有 WAL 通常需要花費(fèi)好幾個(gè)小時(shí)，之后Prometheus才能啟動(dòng)，并開(kāi)始收集度量和查詢請(qǐng)求。在Robust Perception的幫助下，我們發(fā)現(xiàn)設(shè)置GOMAXPROCS=24可以極大地改善這個(gè)問(wèn)題。因?yàn)镻rometheus會(huì)在執(zhí)行WAL期間嘗試使用所有CPU核心，對(duì)于核心數(shù)量極多的服務(wù)器而言，核心之間的競(jìng)爭(zhēng)會(huì)導(dǎo)致性能大幅度下降。

我們正在探索新的選項(xiàng)，以增加我們的監(jiān)測(cè)能力，如下面的“未解決的問(wèn)題”一節(jié)所述。

健康檢查

面對(duì)如此龐大的集群，我們必須依賴自動(dòng)化來(lái)檢測(cè)并移除任何有問(wèn)題的節(jié)點(diǎn)。慢慢地，我們建立起了一系列健康檢查系統(tǒng)。

被動(dòng)健康檢查

一些健康檢查是被動(dòng)的，永遠(yuǎn)在節(jié)點(diǎn)上運(yùn)行。這些健康檢查會(huì)監(jiān)視基本的系統(tǒng)資源，如網(wǎng)絡(luò)不通暢、磁盤失敗、磁盤寫滿或GPU錯(cuò)誤等。GPU會(huì)呈現(xiàn)多種錯(cuò)誤，但最常見(jiàn)的就是“Uncorrectable ECC error”(無(wú)法修復(fù)的ECC錯(cuò)誤)。Nvidia的Data Center GPU Manager (DCGM)工具可以幫助查詢?cè)撳e(cuò)誤，以及許多其他的“Xid”錯(cuò)誤。跟蹤錯(cuò)誤的方法之一就是使用dcgm-exporter工具將度量導(dǎo)出到Prometheus監(jiān)視系統(tǒng)中。這樣就可以創(chuàng)建DCGM_FI_DEV_XID_ERRORS度量，其內(nèi)容為最近發(fā)生過(guò)的錯(cuò)誤代碼。此外，NVMLDevice Query API還可以提供有關(guān)GPU的健康情況和操作的更詳細(xì)信息。

檢測(cè)到錯(cuò)誤之后，通常重啟就能修復(fù)GPU或系統(tǒng)，盡管有些情況下需要更換顯卡。

另一種健康檢查會(huì)跟蹤來(lái)自上游云服務(wù)提供商的維護(hù)事件。每個(gè)主流云服務(wù)提供商都會(huì)提供一種方法，獲知當(dāng)前使用的VM是否即將維護(hù)，從而導(dǎo)致服務(wù)中斷。VM可能需要重啟，因?yàn)樾枰o監(jiān)視程序打補(bǔ)丁，或者給物理服務(wù)器更換硬件。

這些被動(dòng)健康檢查在所有節(jié)點(diǎn)的后臺(tái)不斷運(yùn)行。如果運(yùn)行狀況檢查開(kāi)始失敗，將自動(dòng)隔離該節(jié)點(diǎn)，這樣就不會(huì)在該節(jié)點(diǎn)上調(diào)度新的Pod。對(duì)于更嚴(yán)重的健康檢查失敗，我們還將嘗試終止Pod，請(qǐng)求所有當(dāng)前運(yùn)行的Pod立即退出。它仍然取決于Pod本身，通過(guò)Pod中斷預(yù)算進(jìn)行配置，以決定它是否希望允許這種終止發(fā)生。最終，在所有Pod終止或7天過(guò)去(我們SLA的一部分)之后，我們將強(qiáng)制終止VM。

主動(dòng)GPU測(cè)試

不幸的是，并非所有的GPU問(wèn)題都能從DCGM中看到錯(cuò)誤碼。我們自己構(gòu)建了GPU測(cè)試庫(kù)，能夠捕獲額外的錯(cuò)誤，確保硬件和驅(qū)動(dòng)程序按照預(yù)期運(yùn)行。這些測(cè)試無(wú)法在后臺(tái)運(yùn)行，因?yàn)檫\(yùn)行測(cè)試需要獨(dú)占GPU幾秒鐘或幾分鐘。

首先，我們會(huì)在節(jié)點(diǎn)啟動(dòng)時(shí)運(yùn)行測(cè)試，稱為“預(yù)運(yùn)行”。所有加入集群的節(jié)點(diǎn)都會(huì)加上“preflight” 污染并打標(biāo)簽。該污染可以防止普通Pod被調(diào)度到節(jié)點(diǎn)上。然后配置一個(gè)DaemonSet，在所有帶有該標(biāo)簽的Pod上運(yùn)行預(yù)運(yùn)行測(cè)試。測(cè)試成功后，測(cè)試程序會(huì)移除污染，節(jié)點(diǎn)就可以正常使用了。

我們還會(huì)在節(jié)點(diǎn)的生命周期內(nèi)定期執(zhí)行測(cè)試。測(cè)試通過(guò)CronJob運(yùn)行，因此可以在集群中的任何可用節(jié)點(diǎn)上執(zhí)行。雖然這樣無(wú)法控制測(cè)試在哪個(gè)節(jié)點(diǎn)上運(yùn)行，但我們發(fā)現(xiàn)，只要時(shí)間足夠長(zhǎng)，它就能提供足夠的測(cè)試覆蓋，同時(shí)不會(huì)對(duì)服務(wù)造成太多干擾。

配額和資源利用

當(dāng)我們擴(kuò)大集群時(shí)，研究人員開(kāi)始發(fā)現(xiàn)他們很難獲得分配給它們的所有能力。傳統(tǒng)的Job調(diào)度系統(tǒng)有很多不同的特性，可以在競(jìng)爭(zhēng)團(tuán)隊(duì)之間公平地運(yùn)行工作，而Kubernetes沒(méi)有這些特性。隨著時(shí)間的推移，我們從這些Job調(diào)度系統(tǒng)中獲得了靈感，給Kubernetes添加了幾個(gè)原生功能。

Team taints

我們?cè)诿總€(gè)集群都有一個(gè)服務(wù)“team-resource-manager”，它具有多種功能。它的數(shù)據(jù)源是一個(gè)ConfigMap，它為在給定集群中有能力的所有研究團(tuán)隊(duì)指定元組(節(jié)點(diǎn)選擇器、要應(yīng)用的團(tuán)隊(duì)標(biāo)簽、分配數(shù)量)。它與集群中的當(dāng)前節(jié)點(diǎn)保持一致，從而設(shè)置適當(dāng)數(shù)量的節(jié)點(diǎn)。

openai.com/team=teamname:NoSchedule. 

“team-resource-manager”還具有一個(gè)admission webhook服務(wù)，例如，當(dāng)提交每個(gè)作業(yè)時(shí)，會(huì)根據(jù)提交者的團(tuán)隊(duì)成員申請(qǐng)相應(yīng)的容忍度。使用taints允許我們靈活地約束Kubernetes Pod調(diào)度程序，例如允許對(duì)較低優(yōu)先級(jí)的Pod有“any”容忍度，這允許團(tuán)隊(duì)在不需要重量級(jí)協(xié)調(diào)的情況下借用彼此的能力。

CPU & GPU balloons

除了使用cluster-autoscaler來(lái)動(dòng)態(tài)伸縮集群之外，我們還會(huì)刪除并重新添加集群內(nèi)的不健康節(jié)點(diǎn)。實(shí)現(xiàn)方法是將集群的最小尺寸設(shè)置為零，最大尺寸設(shè)置為可用的容量。但是，如果cluster-autoscaler看到空閑節(jié)點(diǎn)，就會(huì)嘗試將集群收縮至必要限度大小。從許多角度來(lái)看(VM的啟動(dòng)延遲、預(yù)分配的成本、對(duì)API服務(wù)器的影響)來(lái)看，這種空閑狀態(tài)的伸縮并不理想。

所以，我們同時(shí)為僅支持CPU的宿主和支持GPU的宿主引入了氣球部署。該部署包含一個(gè)ReplicaSet，其中設(shè)置了低優(yōu)先級(jí)Pod的最大數(shù)量。這些Pod會(huì)占用一個(gè)節(jié)點(diǎn)內(nèi)的資源，所以自動(dòng)縮放器就不會(huì)認(rèn)為該節(jié)點(diǎn)閑置。但是由于這些Pod優(yōu)先級(jí)很低，因此調(diào)度器可以隨時(shí)將其驅(qū)逐，給真正的作業(yè)騰出空間。(我們選擇了使用部署而不是DaemonSet，避免DaemonSet在節(jié)點(diǎn)上被認(rèn)為是閑置負(fù)載。)

需要注意的一點(diǎn)是，我們使用了Pod反親和性來(lái)保證Pod最終會(huì)均勻地分布到節(jié)點(diǎn)上。Kubernetes早期版本的調(diào)度器在處理Pod反親和性時(shí)的性能為O(N^2)，不過(guò)這一點(diǎn)在1.8版本后就修正了。

有問(wèn)題的調(diào)度

我們的實(shí)驗(yàn)經(jīng)常涉及到一個(gè)或多個(gè)StatefulSet，每個(gè)負(fù)責(zé)訓(xùn)練作業(yè)的一部分。至于優(yōu)化器，研究人員要求所有的StatefulSet都被調(diào)度，訓(xùn)練作業(yè)才能完成(因?yàn)槲覀兘?jīng)常使用MPI來(lái)協(xié)調(diào)優(yōu)化器的各個(gè)成員，而MPI對(duì)于組內(nèi)成員數(shù)量的變化非常敏感)。

但是，Kubernetes默認(rèn)并不一定會(huì)優(yōu)先滿足某個(gè)StatefulSet的所有請(qǐng)求。例如，如果兩個(gè)實(shí)驗(yàn)都要求100%的集群容量，那么Kubernetes不一定會(huì)調(diào)度某個(gè)實(shí)驗(yàn)的所有Pod，而是可能會(huì)為每個(gè)實(shí)驗(yàn)調(diào)度一半的Pod，導(dǎo)致死鎖狀態(tài)，每個(gè)實(shí)驗(yàn)都無(wú)法完成。

我們嘗試了幾種方案，但都遇到了一些極端情況，會(huì)與正常Pod的調(diào)度產(chǎn)生沖突。Kubernetes 1.18為核心調(diào)度器引入了一個(gè)插件架構(gòu)，因此添加功能變得非常容易了。我們最近剛剛發(fā)布了Coscheduling plugin，以解決這個(gè)問(wèn)題。

未解決的問(wèn)題

隨著我們的Kubernetes集群不斷擴(kuò)大，還有許多問(wèn)題有待解決。一些問(wèn)題包括：

度量

在目前的規(guī)模下，Prometheus自帶的TSDB存儲(chǔ)引擎有許多問(wèn)題，例如速度很慢、重啟時(shí)需要很長(zhǎng)時(shí)間重新執(zhí)行WAL(預(yù)寫入日志)等。查詢也很容易導(dǎo)致“查詢可能會(huì)加載過(guò)多數(shù)據(jù)”的錯(cuò)誤。我們正在遷移到與Prometheus兼容的另一個(gè)存儲(chǔ)和查詢引擎上。

Pod網(wǎng)絡(luò)流量

隨著集群的擴(kuò)大，每個(gè)Pod都會(huì)占用一定的互聯(lián)網(wǎng)帶寬。因此，每個(gè)人的互聯(lián)網(wǎng)帶寬加起來(lái)就無(wú)法忽略不計(jì)了，我們的研究人員有可能無(wú)意間給互聯(lián)網(wǎng)的其他部分帶來(lái)不可忽略的資源壓力，例如下載數(shù)。

總結(jié)

我們發(fā)現(xiàn)Kubernetes對(duì)于我們的研究需求來(lái)說(shuō)是一個(gè)非常靈活的平臺(tái)。它有能力擴(kuò)大規(guī)模，以滿足最苛刻的工作負(fù)載。不過(guò)，Kubernetes還有很多需要改進(jìn)的地方，OpenAI的超級(jí)計(jì)算團(tuán)隊(duì)將繼續(xù)探索Kubernetes如何擴(kuò)展。