最近無意間看到一篇兩年前的文章《Scaling Kubernetes to 7,500 nodes》原文如下：https://openai.com/research/scaling-kubernetes-to-7500-nodes#unsolvedproblems仁烹。 雖然有點(diǎn)倔墳，但好在里面的東西并不算太落后肚医，至少從OpenAI團(tuán)隊(duì)之前的文章來看仓手，也確實(shí)記錄了整個(gè)在Kubernetes集群規(guī)模的成長與經(jīng)驗(yàn)的分享，非常的值得學(xué)習(xí)业踢。正好最近我們 KubeGems PAI（機(jī)器學(xué)習(xí)平臺）也遇到一些調(diào)度方面的問題栗柒，便再三閱讀并簡單做個(gè)筆記與大家分享讀后感。

資源調(diào)度

[圖片上傳失敗...(image-10b29d-1689260468845)]

**解釋：**因?yàn)镵ubernetes中的每個(gè)Node節(jié)點(diǎn)的GPU均采用NVLink和GPUDirect直通網(wǎng)卡知举，所以在一個(gè)Node上僅調(diào)度一個(gè)Pod獨(dú)占全部資源來達(dá)到算力最大化利用瞬沦。 要實(shí)現(xiàn)這個(gè)效果，采用NodeSelector和DaemoSet可以最簡單滿足需求雇锡，對K8S的調(diào)度壓力也最泄渥辍（后面說到OpenAI并不是使用DaemonSet方式，且也無法做到更高級的調(diào)度策略锰提，這里僅僅只是舉例）曙痘。在獨(dú)占Node場景下確實(shí)不需要調(diào)度支持Bin-Pack（盡可能將pod填充滿node）和Fragmentation（碎片化）算法，因?yàn)榇藭r(shí)整個(gè)集群的資源最小粒度是Node而不是Pod欲账，也自然不用考慮CPU NUMA拓?fù)浣Y(jié)構(gòu)屡江。也不存在Node資源爭強(qiáng)的問題。

**新知識：**full bisection bandwidth（全雙工切分帶寬）指一個(gè)集群中任何一半的節(jié)點(diǎn)都可以與另一半的節(jié)點(diǎn)進(jìn)行最大帶寬的通信赛不，而不會受到帶寬限制的影響惩嘉。例如，假設(shè)一個(gè)系統(tǒng)有16個(gè)節(jié)點(diǎn)踢故，每個(gè)節(jié)點(diǎn)都有一個(gè)10 Gb/s的網(wǎng)絡(luò)連接文黎。如果系統(tǒng)設(shè)計(jì)得很好惹苗，那么任何8個(gè)節(jié)點(diǎn)都應(yīng)該能夠同時(shí)與其他8個(gè)節(jié)點(diǎn)進(jìn)行10 Gb/s的通信。全雙工切分帶寬的主要優(yōu)點(diǎn)是它可以大大提高系統(tǒng)的并行處理能力耸峭，因?yàn)樗梢宰屗械墓?jié)點(diǎn)都能夠最大化地利用他們的網(wǎng)絡(luò)帶寬桩蓉。

[圖片上傳失敗...(image-a8bfb9-1689260468845)]

解釋：我們根據(jù)團(tuán)隊(duì)名字設(shè)計(jì)了一個(gè)污點(diǎn)openai.com/team=teamname:NoSchedule并把他標(biāo)記到服務(wù)器上，這樣不同團(tuán)隊(duì)在使用資源時(shí)就必須要添加污點(diǎn)容忍才能協(xié)調(diào)到資源劳闹。同時(shí)我們還自己開發(fā)了個(gè)控制器院究，用于在準(zhǔn)入階段將忽略污點(diǎn)，優(yōu)先調(diào)度低優(yōu)先級的pod本涕。這樣就可以讓團(tuán)隊(duì)直接可以彼此借用資源业汰。這個(gè)Webhook挺有意思的，熟悉Volcano的知道菩颖，它在做資源調(diào)度時(shí)也允許不同Queue之間互相借用資源样漆，并reclaim這個(gè)布爾值來決定是否當(dāng)前Queue是否允許回收正在使用中的超額資源。這里可以說是英雄所見略同了晦闰。

[圖片上傳失敗...(image-bfe398-1689260468845)]

解釋：Gang scheduling在處理MPI作業(yè)時(shí)非常重要鲤拿，原因在于MPI作業(yè)的同步通信特性巍糯。由于MPI是一種并行計(jì)算的編程模型蒿柳，它允許進(jìn)程間通過消息傳遞的方式進(jìn)行通信舅列，以完成一項(xiàng)共同的計(jì)算任務(wù)。在MPI中窿冯，一項(xiàng)常見的操作是集合通信骗奖，其中所有進(jìn)程需要同時(shí)參與。如果任何一個(gè)進(jìn)程滯后或者不可用醒串，那么所有的進(jìn)程都將被阻塞，等待該進(jìn)程完成鄙皇。這就導(dǎo)致了MPI作業(yè)非常依賴于所有參與進(jìn)程的同步執(zhí)行芜赌。OpenAI實(shí)現(xiàn)Gang Scheduling的方式則是通過嵌入k8s scheuler plugis的方式實(shí)現(xiàn)。這個(gè)插件名叫Coscheduling伴逸，當(dāng)前已被合并到scheudler-plugin主線缠沈。https://github.com/kubernetes/enhancements/pull/1463. 上文也提到，Gang Scheduling也可通過Volcano來擴(kuò)展Kubernetes的調(diào)度功能來實(shí)現(xiàn)错蝴。

并行作業(yè)處理

[圖片上傳失敗...(image-1f450-1689260468845)]

解釋： 參與到運(yùn)行MPI作業(yè)任務(wù)的work節(jié)點(diǎn)都必須定期進(jìn)行checkpoint洲愤，這是一種容錯(cuò)機(jī)制，可以在作業(yè)出錯(cuò)或者系統(tǒng)崩潰時(shí)恢復(fù)作業(yè)的狀態(tài)顷锰，用來避免計(jì)算出錯(cuò)后全部重頭來過柬赐。

新概念： semi-stateful pod (半狀態(tài)容器)，由于并行任務(wù)的Runtime載體是Pod官紫，它的狀態(tài)數(shù)據(jù)主要就是任務(wù)執(zhí)行是產(chǎn)生的checkpoint肛宋。顯然這部分?jǐn)?shù)據(jù)需要被持久化到PVC中州藕。之所以稱之為半狀態(tài)，主要在于即便該容器掛了酝陈，最壞的情況也是任務(wù)整體暫停并回到上一次checkpoint重新開始床玻，并不會像有狀態(tài)應(yīng)用產(chǎn)生不可逆的災(zāi)難

網(wǎng)絡(luò)

[圖片上傳失敗...(image-6f568d-1689260468845)]

解釋： 訓(xùn)練過程中幾乎沒有外部的網(wǎng)絡(luò)開銷（個(gè)人理解不包含存儲數(shù)據(jù)集的數(shù)據(jù)訪問），所以對Kubernetes的kube-proxy沉帮，ingress組建沒有特別的依賴锈死。之前調(diào)度部分說過，很多時(shí)候一個(gè)Node上就調(diào)度一個(gè)Pod獨(dú)占穆壕，我甚至認(rèn)為有可能Pod直接使用了Host網(wǎng)絡(luò)來最小化網(wǎng)絡(luò)的影響馅精。 此外對Kubernets的服務(wù)發(fā)現(xiàn)應(yīng)用場景也主要是為參與到MPI并行作業(yè)的進(jìn)程提供網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，并用在各個(gè)Worker之間進(jìn)行集體通信粱檀。

[圖片上傳失敗...(image-79166a-1689260468845)]
解釋： 當(dāng)K8S集群擴(kuò)大到7500臺時(shí)洲敢，網(wǎng)絡(luò)方案不管是基于overlay的flannel還是基于路由實(shí)現(xiàn)的組網(wǎng)，都無法在IP地址擴(kuò)展性和性能方面做到同時(shí)兼顧茄蚯。所以我們使用了Azure的VMSS解決了我們的問題压彭。

**新知識：**VMSS是Azure上管理大規(guī)模虛擬機(jī)集群的網(wǎng)絡(luò)服務(wù)和解決方案。

資料較少渗常，看起來這里看起想表達(dá)的意思是OpenAI將Azure上管理虛擬機(jī)地址的VMSS服務(wù)通過CNI給Kuberntes Pod用了起來壮不。

[圖片上傳失敗...(image-a69597-1689260468845)]

解釋： 我們的Pod對外訪問還是基于NAT的，只不過用了Iptables來標(biāo)記流量的來源以及使用量皱碘，這個(gè)主要用來評估Pod間或者說是并行作業(yè)間網(wǎng)絡(luò)通訊是否存在瓶頸

存儲

[圖片上傳失敗...(image-b30272-1689260468845)]

解釋：因?yàn)闆]有更多資料參考OpenAI中Blob存儲的設(shè)計(jì)询一，按照這里意思，我們存儲的用途主要來放訓(xùn)練時(shí)所需要的數(shù)據(jù)集以及記錄訓(xùn)練過程中的checkout（上文有提到）癌椿。并且該存儲還支持?jǐn)?shù)據(jù)的預(yù)熱以加速數(shù)據(jù)訪問效率健蕊，同時(shí)這個(gè)存儲對上還實(shí)現(xiàn)了操作系統(tǒng)標(biāo)準(zhǔn)的POSIX接口方便開發(fā)人員直接操作。

API servers

[圖片上傳失敗...(image-b2e76d-1689260468845)]

**解釋：**我們用5臺獨(dú)立的ETCD服務(wù)器和5臺獨(dú)立的api server服務(wù)器支撐了7500個(gè)節(jié)點(diǎn)踢俄，并當(dāng)前的配置還足以應(yīng)對未來的擴(kuò)容的需求缩功。這里面我們的主要優(yōu)化點(diǎn)是將Kuebrnetes Events分離到其它Etcd集群上以減少記錄大量事件的IO帶來的延遲

[圖片上傳失敗...(image-7c1f82-1689260468845)]

解釋：運(yùn)行大量節(jié)點(diǎn)場景下，每個(gè)Node上的List-Watch帶來的泛洪效應(yīng)比較明顯都办，涓流成河嫡锌，當(dāng)所有請求都匯聚到API Server后所帶來的傳輸帶寬高達(dá)1GB/s! 好在我們用了Kubernete 1.1之后的版本，通過EndpointSlices在服務(wù)器將壓力縮小了1000倍

[圖片上傳失敗...(image-9135d2-1689260468845)]

新知識：EndpointSlices是Kubernetes 1.16 版本引入的新Feature琳钉。它將Endpoint信息分散在多個(gè)較小的對象中势木，每個(gè)對象只包含一部分Endpoint信息。這樣歌懒，對端點(diǎn)的添加啦桌、刪除或修改只需要更新一個(gè)較小的 EndpointSlice 對象，而不需要更新整個(gè) Endpoints 對象歼培。這大大提高了 Kubernetes 在處理大規(guī)模集群時(shí)的性能和可擴(kuò)展性震蒋。

監(jiān)控

[圖片上傳失敗...(image-f78d26-1689260468845)]解釋： 我們也遇到了海量無效的指標(biāo)茸塞，這真的很"煩人"，大部分我們都不從來不關(guān)注查剖。我們Prometheus也經(jīng)常OOM钾虐，后來發(fā)現(xiàn)是大量的histogram指標(biāo)查詢堆積造成的。所以我們在后端查詢時(shí)設(shè)置了執(zhí)行超時(shí)時(shí)間笋庄，這樣promtheus的內(nèi)存就再沒爆過了效扫。

另外Prometheus重啟后對WAL文件的重放事件慢得我們也無法忍受，后來在Robust Perception的幫助下知道了調(diào)大GOMAXPROCS參數(shù)來設(shè)置goroutine數(shù)來加快重放速度

爸鄙啊菌仁？原來OpenAI的工程師居然不知道 - -!

總結(jié)

OpenAI 將 Kubernetes 集群擴(kuò)展到 7,500 個(gè)節(jié)點(diǎn)，并為 GPT-3静暂、CLIP 和 DALL·E 等大型模型提供了可擴(kuò)展的基礎(chǔ)設(shè)施济丘，足以證明Kubernetes 是一個(gè)非常靈活的平臺，隨著AI行業(yè)的這波浪潮洽蛀，Kubernetes也會跟著機(jī)器學(xué)習(xí)摹迷、更大規(guī)模和精細(xì)化的調(diào)度迎來一波新的高點(diǎn)。

[圖片上傳失敗...(image-ce1e43-1689260468845)]

[圖片上傳失敗...(image-39a212-1689260468845)]