[譯]將 Kubernetes 擴(kuò)展至7500個(gè)節(jié)點(diǎn)

我們已經(jīng)將 Kubernetes 集群擴(kuò)展到了7500個(gè)節(jié)點(diǎn)，該集群主要是為 GPT-3、CLIP 和 DALL·E 等大型模型提供可擴(kuò)展的基礎(chǔ)設(shè)施，同時(shí)也為神經(jīng)語(yǔ)言模型的縮放定律等快速的小規(guī)模迭代研究提供基礎(chǔ)支持。將單個(gè) Kubernetes 集群擴(kuò)展到這種規(guī)模是很少見的，因而需要特別小心，但好處是一個(gè)簡(jiǎn)單的基礎(chǔ)設(shè)施，使我們的機(jī)器學(xué)習(xí)研究團(tuán)隊(duì)能夠更快地遷移和擴(kuò)展，而不需要更改他們的代碼。

自從我們上一篇關(guān)于《擴(kuò)容到2,500個(gè)節(jié)點(diǎn)》(https://openai.com/blog/scaling-kubernetes-to-2500-nodes/)的文章以來(lái)，我們一直在擴(kuò)容我們的基礎(chǔ)設(shè)施來(lái)滿足研究人員的需求，在這個(gè)過程中，我們學(xué)到了很多額外的經(jīng)驗(yàn)教訓(xùn)。這篇文章總結(jié)了這些經(jīng)驗(yàn)，以便 Kubernetes 社區(qū)中的其他人可以從中受益，最后還介紹了我們目前仍然面臨的問題，接下來(lái)我們將重點(diǎn)解決這些問題。

工作負(fù)載

在我們深入本文之前，先簡(jiǎn)單介紹下我們的工作負(fù)載是非常有必要的。我們使用 Kubernetes 運(yùn)行的應(yīng)用程序和硬件與你在大部分公司可能遇到的情況有很大不同。

一個(gè)大型機(jī)器學(xué)習(xí)作業(yè)跨越多個(gè)節(jié)點(diǎn)，當(dāng)它能夠訪問每個(gè)節(jié)點(diǎn)上的所有硬件資源時(shí)，它的運(yùn)行效率最高。這使得 GPU 可以直接使用 NVLink 進(jìn)行交叉通信，或者 GPU 可以直接使用 GPUDirect 與網(wǎng)卡進(jìn)行通信。所以對(duì)于我們的許多公眾任務(wù)，一個(gè) Pod 就會(huì)占據(jù)整個(gè)節(jié)點(diǎn)。NUMA、CPU 或 PCIE 資源競(jìng)爭(zhēng)都不是我們調(diào)度的因素。

Bin-packing 碎片化對(duì)我們而言并也不是一個(gè)常見的問題。我們當(dāng)前的集群有充分的帶寬，因此我們也不用去考慮任何機(jī)架或網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)問題。這些都意味著，雖然我們有很多節(jié)點(diǎn)，但對(duì)調(diào)度器的壓力相對(duì)較小。

一個(gè)新的作業(yè)可能包含數(shù)百個(gè)同時(shí)創(chuàng)建的 Pod，此時(shí)對(duì) kube-scheduler 來(lái)說可能壓力會(huì)比較大，但是然后就會(huì)恢復(fù)到一個(gè)相對(duì)較低的利用率了。

我們最大的任務(wù)是運(yùn)行 MPI，任務(wù)中的所有 Pod 都參與一個(gè) MPI 通信。如果任何一個(gè)參與的 Pod 死亡，整個(gè)任務(wù)就會(huì)停止，需要重新啟動(dòng)。任務(wù)會(huì)定期檢查，當(dāng)重新啟動(dòng)時(shí)，會(huì)從最后一個(gè)檢查點(diǎn)開始恢復(fù)。因此，我們認(rèn)為 Pods 是半狀態(tài)的，被殺死的 Pods 可以被替換，任務(wù)可以繼續(xù)，但是這樣做具有破壞性，應(yīng)該盡量減少。

我們并不那么依賴 Kubernetes 進(jìn)行負(fù)載均衡。我們的 HTTPS 流量很少，不需要進(jìn)行 A/B 測(cè)試、藍(lán)/綠或金絲雀發(fā)布。Pods 通過 SSH，而不是服務(wù)端點(diǎn)，直接在其 Pod IP 地址上與 MPI 相互通信。服務(wù)“發(fā)現(xiàn)”是有限的；我們只是在任務(wù)啟動(dòng)時(shí)一次性查找哪些 Pods 在參與 MPI。

大部分任務(wù)都會(huì)與某種形式的 blob 存儲(chǔ)進(jìn)行交互。它們通常會(huì)直接從 blob 存儲(chǔ)中讀寫數(shù)據(jù)集，或?qū)⑵渚彺娴礁斓谋镜嘏R時(shí)磁盤。我們同時(shí)也有一些 PersistentVolumes，但是 blob 存儲(chǔ)的可擴(kuò)展性更強(qiáng)，并且不需要緩慢的 detach/attach 操作。

我們的工作性質(zhì)實(shí)際上屬于研究工作，這意味著工作負(fù)載本身是不斷變化的。盡管超級(jí)計(jì)算團(tuán)隊(duì)努力提供我們所認(rèn)為的滿足“生產(chǎn)”質(zhì)量水平的計(jì)算基礎(chǔ)設(shè)施，但在該集群上運(yùn)行的應(yīng)用程序壽命很短，開發(fā)人員也會(huì)快速迭代。任何時(shí)候都有可能出現(xiàn)新的使用方式，這對(duì)我們關(guān)于未來(lái)趨勢(shì)的預(yù)測(cè)提出了挑戰(zhàn)，我們需要一個(gè)可持續(xù)發(fā)展的系統(tǒng)，該系統(tǒng)還可以讓我們?cè)谑虑榘l(fā)生變化時(shí)迅速做出響應(yīng)。

網(wǎng)絡(luò)

隨著集群中節(jié)點(diǎn)和 Pod 數(shù)量的增加，我們發(fā)現(xiàn) Flannel 難以滿足所需的網(wǎng)絡(luò)吞吐量。我們轉(zhuǎn)而使用元素的 Pod 網(wǎng)絡(luò)技術(shù)為我們的 IP 配置 Azure VMSSes 和相關(guān)的 CNI 插件。這使我們能夠在 Pod 上獲得宿主機(jī)級(jí)別的網(wǎng)絡(luò)吞吐量。

我們轉(zhuǎn)而使用基于別名的 IP 地址的另一個(gè)原因是，在我們最大的集群上，任何時(shí)候都可能有大約20萬(wàn)個(gè) IP 地址正在使用。當(dāng)我們測(cè)試基于路由的 Pod 網(wǎng)絡(luò)時(shí)，我們發(fā)現(xiàn)可以有效使用的路由數(shù)量存在明顯的限制。

避免封裝會(huì)增加對(duì)底層 SDN 或路由引擎的需求，但它使我們的網(wǎng)絡(luò)配置變得簡(jiǎn)單。無(wú)需任何其他適配器即可添加 VPN 或隧道，我們不需要擔(dān)心由于網(wǎng)絡(luò)的某些部分具有較低的 MTU 而導(dǎo)致數(shù)據(jù)包碎片。網(wǎng)絡(luò)策略和流量監(jiān)控非常簡(jiǎn)單，數(shù)據(jù)包的源和目的地都很明確。

我們?cè)谥鳈C(jī)上使用 iptables 標(biāo)記來(lái)跟蹤每個(gè)命名空間和 Pod 的網(wǎng)絡(luò)資源使用情況。這可以讓研究人員可視化他們的網(wǎng)絡(luò)使用模式，特別是，由于我們的很多實(shí)驗(yàn)都有不同的網(wǎng)絡(luò)和 Pod 內(nèi)部通信模式，因此這對(duì)排查可能出現(xiàn)瓶頸的地方會(huì)很有幫助。

iptables mangle 規(guī)則可以用來(lái)標(biāo)記符合特定條件的數(shù)據(jù)包，以下是我們用來(lái)檢測(cè)流量是內(nèi)部流量還是外部流量的規(guī)則，同時(shí)也可以看到 FORWARD 規(guī)則包含了來(lái)自 Pods 的流量，與來(lái)自主機(jī)的 INPUT 和 OUTPUT 流量的對(duì)比：

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?openai?traffic=internet-out"

標(biāo)記后，iptables 將啟動(dòng)計(jì)數(shù)器來(lái)跟蹤與此規(guī)則匹配的字節(jié)和數(shù)據(jù)包數(shù)量，你可以使用 iptables 命令來(lái)查看這些計(jì)數(shù)器：

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?????????????/*?iptables-exporter?openai?traffic=internet-in?*/

我們使用一個(gè)名為 iptables-exporter(https://github.com/madron/iptables-exporter/) 的開源 Prometheus exporter，然后將其部署到我們的監(jiān)控系統(tǒng)中。

我們的網(wǎng)絡(luò)模型有一個(gè)特別的地方是，我們將節(jié)點(diǎn)、Pod 和 Service CIDR 范圍完全暴露給我們的研究人員。我們有一個(gè)中心輻射網(wǎng)絡(luò)模型，并使用本機(jī)節(jié)點(diǎn)和 Pod CIDR 來(lái)路由該流量。研究人員連接到中心，然后從那里可以訪問任何單個(gè)集群。但是集群本身無(wú)法相互通信。這樣可確保集群保持隔離，沒有跨群集的依賴關(guān)系會(huì)破壞故障隔離。

我們使用 NAT 主機(jī)來(lái)轉(zhuǎn)換 Service CIDR，以處理來(lái)自群集外部的流量。這種設(shè)置使我們的研究人員在選擇實(shí)驗(yàn)方式和選擇哪種網(wǎng)絡(luò)配置時(shí)具有極大的靈活性。

APIServer

Kubernetes APIServer 和 etcd 是集群健康運(yùn)行的核心組件，因此我們需要特別關(guān)注這些系統(tǒng)的壓力。我們使用 kube-prometheus(https://github.com/coreos/kube-prometheus)提供的 Grafana 儀表盤，以及其他內(nèi)部?jī)x表盤。我們發(fā)現(xiàn)，在 APIServer 上 HTTP 狀態(tài)碼429（過多請(qǐng)求）和5xx（服務(wù)端錯(cuò)誤）的告警速率是很有用的，通過他們能得知當(dāng)前的 Kubernetns 集群的壓力。

雖然有些人在 kube 中運(yùn)行 APIServer，但我們是在集群之外運(yùn)行它們的。etcd 和 APIServer 都在各自的專用節(jié)點(diǎn)上運(yùn)行。我們最大的集群運(yùn)行5個(gè) APIServer 和5個(gè) etcd 節(jié)點(diǎn)，以分散負(fù)載，在其中一個(gè)節(jié)點(diǎn)宕機(jī)時(shí)將影響降到最低。自從我們?cè)谏弦黄┪闹袑?Kubernetes Events 拆分到自己的 etcd 集群后，etcd 就沒有出現(xiàn)過明顯的問題了，APIServer 是無(wú)狀態(tài)的，通常很容易在自愈實(shí)例組或 scaleset 中運(yùn)行。

此外 APIServer 會(huì)占用相當(dāng)大的內(nèi)存，并且會(huì)隨著群集中節(jié)點(diǎn)的數(shù)量增加而線性擴(kuò)展。對(duì)于有7500個(gè)節(jié)點(diǎn)的集群，我們觀察到每個(gè) APIServer 使用了高達(dá)70GB的堆內(nèi)存，不過這完全在我們的物理硬件能力范圍之內(nèi)。

APIServer 的一大壓力是 Endpoints 上的 WATCH 操作，有一些服務(wù)，例如 kubelet 和 node-exporter，集群中的每個(gè)節(jié)點(diǎn)都有這些組件。當(dāng)從集群中添加或刪除節(jié)點(diǎn)時(shí)，將觸發(fā) WATCH 事件。而且由于每個(gè)節(jié)點(diǎn)本身通常都通過 kube-proxy 來(lái) WATCH kubelet 服務(wù)，因此這些響應(yīng)所需的帶寬將是 N^2 ，這是非常龐大的，偶爾甚至?xí)_(dá)到1GB/s或更高。在 Kubernetes 1.17 中推出的 EndpointSlices 特性帶了很大的改善，它讓這個(gè)負(fù)載降低了1000倍。

一般來(lái)說，我們非常關(guān)注所有隨集群大小而擴(kuò)展的 APIServer 請(qǐng)求，我們盡量避免 DaemonSet 與 APIServer 交互。如果確實(shí)需要這樣做，那么引入中間緩存服務(wù)，例如 Datadog Cluster Agent，這是避免集群瓶頸的一個(gè)好的方式。

隨著我們集群的增長(zhǎng)，我們對(duì)集群的實(shí)際自動(dòng)伸縮操作比較少，但是當(dāng)一次自動(dòng)縮放過多時(shí)，我們偶爾還是會(huì)遇到一些問題，當(dāng)新節(jié)點(diǎn)加入集群時(shí)，會(huì)生成很多請(qǐng)求，如果一次添加數(shù)百個(gè)節(jié)點(diǎn)可能會(huì)使 APIServer 容量過載，即使只需幾秒鐘就可以消除這種情況。

Prometheus 和 Grafana 的監(jiān)控指標(biāo)

我們使用 Prometheus 收集監(jiān)控指標(biāo)，并使用 Grafana 進(jìn)行圖形展示以及告警。我們首先部署 kube-prometheus，它收集各種各樣的指標(biāo)來(lái)用于可視化儀表板配置。隨著時(shí)間的推移，我們添加了很多自己的儀表板、指標(biāo)和告警。

隨著我們添加越來(lái)越多的節(jié)點(diǎn)，我們對(duì) Prometheus 收集的大量指標(biāo)而苦惱，盡管 kube-prometheus 提供了很多有用的數(shù)據(jù)，但其中一些我們實(shí)際上從未使用過，而有些則過于精細(xì)而無(wú)法有效地收集、存儲(chǔ)和查詢。我們使用 Prometheus 的 relabel 規(guī)則(https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config)來(lái)刪除其中的某些指標(biāo)。

有一段時(shí)間，我們一直在努力解決一個(gè)問題，即 Prometheus 會(huì)消耗越來(lái)越多的內(nèi)存，直到最終由于內(nèi)存不足錯(cuò)誤（OOM）使容器崩潰。即使在應(yīng)用程序上投入了大量的內(nèi)存容量之后，這種情況似乎仍會(huì)發(fā)生。更糟糕的是，當(dāng)它真的崩潰時(shí)，在啟動(dòng)時(shí)要花幾個(gè)小時(shí)才能重放 write-ahead-log 日志文件才能正常。

最終，我們追蹤到這些 OOM 的來(lái)源是 Grafana 與 Prometheus 之間的交互，其中 Grafana 會(huì)在 Prometheus 上使用 /api/v1/series 這個(gè)接口并查詢{le!=""}，對(duì)于有大量結(jié)果的查詢，/api/v1/series 在時(shí)間和空間上都是不受限制的，但這將消耗越來(lái)越多的內(nèi)存和時(shí)間。即使在請(qǐng)求者放棄并關(guān)閉連接后，它也會(huì)繼續(xù)增長(zhǎng)。對(duì)于我們來(lái)說，內(nèi)存永遠(yuǎn)是不夠用的，Prometheus 最終都會(huì)崩潰。為此我們?yōu)?Prometheus 提交了一個(gè)patch(https://github.com/openai/prometheus/pull/1)，將這個(gè) API 包含在一個(gè) Context 中來(lái)強(qiáng)制超時(shí)，從而完全修復(fù)了這個(gè) bug。

雖然 Prometheus 崩潰的頻率比較小，但在我們確實(shí)需要重新啟動(dòng)它的時(shí)候，WAL replay 仍然是一個(gè)問題。在 Prometheus 收集新指標(biāo)和服務(wù)查詢之前，經(jīng)常需要花費(fèi)幾個(gè)小時(shí)來(lái)重放所有 WAL 日志。在 Robust Perception 的幫助下，我們發(fā)現(xiàn)配置 GOMAXPROCS=24 后會(huì)對(duì) Prometheus 有很大的改善。

目前我們正在嘗試新的方案來(lái)增加我們的監(jiān)控能力，在下面未解決問題部分有介紹。

健康檢查

對(duì)于一個(gè)如此龐大的集群，我們當(dāng)然要依靠自動(dòng)化來(lái)檢測(cè)并從集群中移除異常的節(jié)點(diǎn)。隨著時(shí)間的推移，我們已經(jīng)建立了一些健康檢查系統(tǒng)。

被動(dòng)健康檢查

有些健康檢查是被動(dòng)的，并且始終在所有節(jié)點(diǎn)上運(yùn)行。它們監(jiān)控基本的系統(tǒng)資源，例如網(wǎng)絡(luò)可達(dá)性、磁盤損壞或磁盤容量、GPU 錯(cuò)誤等。GPU 表現(xiàn)出的問題有很多不同的方式，但一個(gè)常見的問題是 Uncorrectable ECC error.，Nvidia 的數(shù)據(jù)中心 GPU 管理器工具可以很容易地查詢這個(gè)錯(cuò)誤以及其他的一些 Xid 錯(cuò)誤。我們跟蹤這些錯(cuò)誤的一種方法是通過 dcgm-exporter(https://github.com/NVIDIA/gpu-monitoring-tools#dcgm-exporter)將指標(biāo)抓取到我們的監(jiān)控系統(tǒng) Prometheus 中，當(dāng)指標(biāo) DCGM_FI_DEV_XID_ERRORS 出現(xiàn)時(shí)，表示最近發(fā)生的錯(cuò)誤代碼，此外，NVML 設(shè)備查詢 API 暴露了有關(guān) GPU 的運(yùn)行狀況的詳細(xì)信息。

一旦我們檢測(cè)到錯(cuò)誤，它們通?？梢酝ㄟ^重置 GPU 或系統(tǒng)來(lái)修復(fù)它們，盡管在某些情況下，它確實(shí)需要從底層上進(jìn)行物理更換 GPU。

健康檢查的另一種形式是跟蹤來(lái)自上游云供應(yīng)商的維護(hù)事件，大部分的云提供商都會(huì)提供一種方法，以了解當(dāng)前的虛擬機(jī)是否即將面臨即將發(fā)生的維護(hù)事件，而該事件最終會(huì)導(dǎo)致中斷。虛擬機(jī)可能需要重新啟動(dòng)，以便應(yīng)用底層的管理程序補(bǔ)丁，或者將物理節(jié)點(diǎn)換成其他硬件。

這些被動(dòng)健康檢查在所有節(jié)點(diǎn)的后臺(tái)持續(xù)運(yùn)行，如果健康檢查一開始就失敗，節(jié)點(diǎn)將自動(dòng)被停用，因此不會(huì)在該節(jié)點(diǎn)上調(diào)度新的 Pod，對(duì)于更嚴(yán)重的健康檢查失敗，我們還將嘗試驅(qū)逐容器，以讓所有當(dāng)前節(jié)點(diǎn)運(yùn)行的容器立即退出。這些還是由 Pod本身決定，可以通過 Pod Disruption Budget 進(jìn)行配置，決定是否要讓這種配置生效。最終，在所有 Pod 終止后或7天后，我們將強(qiáng)制停掉虛擬機(jī)。

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

不幸的是，并非所有的 GPU 問題都可以通過 DCGM 獲知對(duì)應(yīng)的錯(cuò)誤代碼，我們已經(jīng)建立了自己的測(cè)試庫(kù)，這些測(cè)試使用 GPU 來(lái)捕獲額外的問題，并確保硬件和驅(qū)動(dòng)程序按預(yù)期運(yùn)行，這些測(cè)試不能在后臺(tái)運(yùn)行，它們需要獨(dú)占使用 GPU 幾秒鐘或幾分鐘才能運(yùn)行。

我們首先在啟動(dòng)時(shí)在節(jié)點(diǎn)上運(yùn)行這些測(cè)試，我們稱之為預(yù)檢系統(tǒng)，一開始，所有節(jié)點(diǎn)均以預(yù)檢污點(diǎn)和標(biāo)簽加入集群，此污點(diǎn)會(huì)阻止在節(jié)點(diǎn)上調(diào)度普通的 Pod，將 DaemonSet 配置為在帶有此標(biāo)簽的所有節(jié)點(diǎn)上運(yùn)行預(yù)檢測(cè)試 Pod，成功完成測(cè)試后，測(cè)試本身將去除污點(diǎn)和標(biāo)簽，然后該節(jié)點(diǎn)即可用于常規(guī)用途。

然后，我們還將在節(jié)點(diǎn)的生命期內(nèi)定期運(yùn)行這些測(cè)試。我們將其作為 CronJob 運(yùn)行，使其可以在集群中的所有可用節(jié)點(diǎn)上運(yùn)行，當(dāng)然這是隨機(jī)的，無(wú)法控制要測(cè)試的節(jié)點(diǎn)，但是我們發(fā)現(xiàn)，隨著時(shí)間的流逝，它可以提供足夠的覆蓋范圍，并且干擾影響最小。

配額和資源使用

當(dāng)我們擴(kuò)大集群規(guī)模時(shí)，研究人員開始發(fā)現(xiàn)自己很難獲得分配給他們的所有容量。傳統(tǒng)的作業(yè)調(diào)度系統(tǒng)有很多不同的功能，可以在團(tuán)隊(duì)之間公平地運(yùn)行工作任務(wù)，而 Kubernetes 沒有這些特性。隨著時(shí)間的推移，我們從那些作業(yè)調(diào)度系統(tǒng)中獲得了靈感，并以 Kubernetes 原生的方式構(gòu)建了一些功能。

團(tuán)隊(duì)污點(diǎn)

我們?cè)诿總€(gè)集群中都有一個(gè)服務(wù) team-resource-manager，它有多種功能。它的數(shù)據(jù)源是一個(gè) ConfigMap，它為特定集群中所有研究團(tuán)隊(duì)指定了一些元組標(biāo)簽（節(jié)點(diǎn)選擇器、要應(yīng)用的團(tuán)隊(duì)標(biāo)簽、分配數(shù)量等），它將與集群中的當(dāng)前節(jié)點(diǎn)進(jìn)行協(xié)調(diào)，并使用 openai.com/team=teamname:NoSchedule 標(biāo)簽來(lái)保留適當(dāng)數(shù)量的節(jié)點(diǎn)。

team-resource-manager 還有一個(gè)準(zhǔn)入 webhook 服務(wù)，以便在提交每個(gè)作業(yè)時(shí)，根據(jù)提交者的團(tuán)隊(duì)成員身份應(yīng)用相應(yīng)的容忍度，使用污點(diǎn)可以使我們靈活地約束 Kubernetes Pod 調(diào)度器，例如允許對(duì)優(yōu)先級(jí)較低的 Pod 允許 any 容忍，這樣就可以讓團(tuán)隊(duì)互相借用對(duì)方的能力，而不需要重量級(jí)的協(xié)調(diào)。

CPU 和 GPU balloons

除了使用 cluster-autoscaler 動(dòng)態(tài)擴(kuò)展我們的虛擬機(jī)支持的集群之外，我們還使用它來(lái)修復(fù)（刪除和重新添加）集群中不健康的成員，為此，我們將集群的最小大小設(shè)置為零，將集群的最大大小設(shè)置為可用容量來(lái)實(shí)現(xiàn)。但是，如果 cluster-autoscaler 看到空閑節(jié)點(diǎn)，它將嘗試縮小到需要的容量。由于多種原因（虛擬機(jī)啟動(dòng)延遲、預(yù)先分配的成本、上面提到的 APIServer 影響），這種空閑擴(kuò)展并不理想。

因此，我們?yōu)槲覀兊?CPU 和 GPU 主機(jī)引入了一個(gè) balloon 式部署。此部署包含一個(gè)有“最大大小”低優(yōu)先級(jí) Pod 數(shù)的 ReplicaSet，這些 Pod 占用節(jié)點(diǎn)內(nèi)的資源，因此 autoscaler 不認(rèn)為它們是空閑的。但是，由于它們的優(yōu)先級(jí)較低，調(diào)度程序可以立即將它們逐出，以便為實(shí)際工作騰出空間。（我們選擇使用 Deployment 而不是 DaemonSet，以避免 DaemonSet 被視為節(jié)點(diǎn)上的空閑工作負(fù)載。）

調(diào)度爭(zhēng)用

我們的實(shí)驗(yàn)通常涉及一個(gè)或多個(gè) StatefulSet，每個(gè) StatefulSet 都負(fù)責(zé)不同部分的訓(xùn)練工作。對(duì)于優(yōu)化器來(lái)說，研究人員需要 StatefulSet 的所有成員都被調(diào)度好，然后才能進(jìn)行訓(xùn)練。

但是，默認(rèn)情況下，Kubernetes 不一定會(huì)優(yōu)先滿足來(lái)自一個(gè) StatefulSet 的所有請(qǐng)求。例如，如果兩個(gè)實(shí)驗(yàn)都請(qǐng)求集群100%的容量，那么 Kubernetes 可能只調(diào)度每個(gè)實(shí)驗(yàn)的一半 Pod，而不是調(diào)度一個(gè)或另一個(gè)實(shí)驗(yàn)的全部容量，從而導(dǎo)致死鎖，最終導(dǎo)致兩個(gè)實(shí)驗(yàn)都無(wú)法進(jìn)行。

我們嘗試了一些自定義調(diào)度程序的方式，但是遇到了一些極端情況，這些情況導(dǎo)致與普通 Pod 的調(diào)度方式發(fā)生沖突。Kubernetes 1.18引入了用于核心 Kubernetes 調(diào)度程序的插件架構(gòu)，這使得在本地添加此類功能變得更加容易。最近我們落地了 Coscheduling 插件(https://github.com/kubernetes/enhancements/pull/1463)，是解決這個(gè)問題的好辦法。

未解決的問題

在擴(kuò)展 Kubernetes 集群時(shí)，我們?nèi)杂泻芏鄦栴}需要解決。其中幾個(gè)問題包括：

監(jiān)控指標(biāo)

在我們的規(guī)模中，我們有很多問題都是與 Prometheus 的內(nèi)置 TSDB 存儲(chǔ)引擎相關(guān)，因?yàn)樗膲嚎s很緩慢，一旦需要重啟，就需要很長(zhǎng)的時(shí)間來(lái)重放 WAL，查詢還會(huì)導(dǎo)致 query processing would load too many samples 錯(cuò)誤，當(dāng)前，我們正在遷移到另一個(gè)與 Prometheus 兼容的存儲(chǔ)和查詢引擎，期待未來(lái)的有機(jī)會(huì)介紹!

Pod 網(wǎng)絡(luò) traffic shaping

隨著我們集群規(guī)模的擴(kuò)大，每個(gè) Pod 都會(huì)被計(jì)算為有一定的外網(wǎng)帶寬，每個(gè)人對(duì)帶寬的總需求已經(jīng)變得相當(dāng)大了，并且我們的研究人員現(xiàn)在在無(wú)意間對(duì)外網(wǎng)的訪問（例如，下載數(shù)據(jù)和安裝軟件包）帶來(lái)了巨大的資源壓力。

結(jié)論

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

原文鏈接：https://openai.com/blog/scaling-kubernetes-to-7500-nodes/