我們已經將 Kubernetes 集群擴展到了7500個節點，該集群主要是為 GPT-3、CLIP 和 DALL·E 等大型模型提供可擴展的基礎設施，同時也為神經語言模型的縮放定律等快速的小規模迭代研究提供基礎支持。將單個 Kubernetes 集群擴展到這種規模是很少見的，因而需要特別小心，但好處是一個簡單的基礎設施，使我們的機器學習研究團隊能夠更快地遷移和擴展，而不需要更改他們的代碼。
自從我們上一篇關於《擴容到2,500個節點》(https://openai.com/blog/scaling-kubernetes-to-2500-nodes/)的文章以來，我們一直在擴容我們的基礎設施來滿足研究人員的需求，在這個過程中，我們學到了很多額外的經驗教訓。這篇文章總結了這些經驗，以便 Kubernetes 社區中的其他人可以從中受益，最後還介紹了我們目前仍然面臨的問題，接下來我們將重點解決這些問題。
工作負載在我們深入本文之前，先簡單介紹下我們的工作負載是非常有必要的。我們使用 Kubernetes 運行的應用程式和硬體與你在大部分公司可能遇到的情況有很大不同。
一個大型機器學習作業跨越多個節點，當它能夠訪問每個節點上的所有硬體資源時，它的運行效率最高。這使得 GPU 可以直接使用 NVLink 進行交叉通信，或者 GPU 可以直接使用 GPUDirect 與網卡進行通信。所以對於我們的許多公眾任務，一個 Pod 就會佔據整個節點。NUMA、CPU 或 PCIE 資源競爭都不是我們調度的因素。
Bin-packing 碎片化對我們而言並也不是一個常見的問題。我們當前的集群有充分的帶寬，因此我們也不用去考慮任何機架或網絡拓撲結構問題。這些都意味著，雖然我們有很多節點，但對調度器的壓力相對較小。
一個新的作業可能包含數百個同時創建的 Pod，此時對 kube-scheduler 來說可能壓力會比較大，但是然後就會恢復到一個相對較低的利用率了。
我們最大的任務是運行 MPI，任務中的所有 Pod 都參與一個 MPI 通信。如果任何一個參與的 Pod 死亡，整個任務就會停止，需要重新啟動。任務會定期檢查，當重新啟動時，會從最後一個檢查點開始恢復。因此，我們認為 Pods 是半狀態的，被殺死的 Pods 可以被替換，任務可以繼續，但是這樣做具有破壞性，應該儘量減少。
我們並不那麼依賴 Kubernetes 進行負載均衡。我們的 HTTPS 流量很少，不需要進行 A/B 測試、藍/綠或金絲雀發布。Pods 通過 SSH，而不是服務端點，直接在其 Pod IP 地址上與 MPI 相互通信。服務「發現」是有限的；我們只是在任務啟動時一次性查找哪些 Pods 在參與 MPI。
大部分任務都會與某種形式的 blob 存儲進行交互。它們通常會直接從 blob 存儲中讀寫數據集，或將其緩存到更快的本地臨時磁碟。我們同時也有一些 PersistentVolumes，但是 blob 存儲的可擴展性更強，並且不需要緩慢的 detach/attach 操作。
我們的工作性質實際上屬於研究工作，這意味著工作負載本身是不斷變化的。儘管超級計算團隊努力提供我們所認為的滿足「生產」質量水平的計算基礎設施，但在該集群上運行的應用程式壽命很短，開發人員也會快速迭代。任何時候都有可能出現新的使用方式，這對我們關於未來趨勢的預測提出了挑戰，我們需要一個可持續發展的系統，該系統還可以讓我們在事情發生變化時迅速做出響應。
網絡隨著集群中節點和 Pod 數量的增加，我們發現 Flannel 難以滿足所需的網絡吞吐量。我們轉而使用元素的 Pod 網絡技術為我們的 IP 配置 Azure VMSSes 和相關的 CNI 插件。這使我們能夠在 Pod 上獲得宿主機級別的網絡吞吐量。
我們轉而使用基於別名的 IP 地址的另一個原因是，在我們最大的集群上，任何時候都可能有大約20萬個 IP 地址正在使用。當我們測試基於路由的 Pod 網絡時，我們發現可以有效使用的路由數量存在明顯的限制。
避免封裝會增加對底層 SDN 或路由引擎的需求，但它使我們的網絡配置變得簡單。無需任何其他適配器即可添加 VPN 或隧道，我們不需要擔心由於網絡的某些部分具有較低的 MTU 而導致數據包碎片。網絡策略和流量監控非常簡單，數據包的源和目的地都很明確。
我們在主機上使用 iptables 標記來跟蹤每個命名空間和 Pod 的網絡資源使用情況。這可以讓研究人員可視化他們的網絡使用模式，特別是，由於我們的很多實驗都有不同的網絡和 Pod 內部通信模式，因此這對排查可能出現瓶頸的地方會很有幫助。
iptables mangle 規則可以用來標記符合特定條件的數據包，以下是我們用來檢測流量是內部流量還是外部流量的規則，同時也可以看到 FORWARD 規則包含了來自 Pods 的流量，與來自主機的 INPUT 和 OUTPUT 流量的對比：
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"標記後，iptables 將啟動計數器來跟蹤與此規則匹配的字節和數據包數量，你可以使用 iptables 命令來查看這些計數器：
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 */我們使用一個名為 iptables-exporter(https://github.com/madron/iptables-exporter/) 的開源 Prometheus exporter，然後將其部署到我們的監控系統中。
我們的網絡模型有一個特別的地方是，我們將節點、Pod 和 Service CIDR 範圍完全暴露給我們的研究人員。我們有一個中心輻射網絡模型，並使用本機節點和 Pod CIDR 來路由該流量。研究人員連接到中心，然後從那裡可以訪問任何單個集群。但是集群本身無法相互通信。這樣可確保集群保持隔離，沒有跨群集的依賴關係會破壞故障隔離。
我們使用 NAT 主機來轉換 Service CIDR，以處理來自群集外部的流量。這種設置使我們的研究人員在選擇實驗方式和選擇哪種網絡配置時具有極大的靈活性。
APIServerKubernetes APIServer 和 etcd 是集群健康運行的核心組件，因此我們需要特別關注這些系統的壓力。我們使用 kube-prometheus(https://github.com/coreos/kube-prometheus)提供的 Grafana 儀錶盤，以及其他內部儀錶盤。我們發現，在 APIServer 上 HTTP 狀態碼429（過多請求）和5xx（服務端錯誤）的告警速率是很有用的，通過他們能得知當前的 Kubernetns 集群的壓力。
雖然有些人在 kube 中運行 APIServer，但我們是在集群之外運行它們的。etcd 和 APIServer 都在各自的專用節點上運行。我們最大的集群運行5個 APIServer 和5個 etcd 節點，以分散負載，在其中一個節點宕機時將影響降到最低。自從我們在上一篇博文中將 Kubernetes Events 拆分到自己的 etcd 集群後，etcd 就沒有出現過明顯的問題了，APIServer 是無狀態的，通常很容易在自愈實例組或 scaleset 中運行。
此外 APIServer 會佔用相當大的內存，並且會隨著群集中節點的數量增加而線性擴展。對於有7500個節點的集群，我們觀察到每個 APIServer 使用了高達70GB的堆內存，不過這完全在我們的物理硬體能力範圍之內。
APIServer 的一大壓力是 Endpoints 上的 WATCH 操作，有一些服務，例如 kubelet 和 node-exporter，集群中的每個節點都有這些組件。當從集群中添加或刪除節點時，將觸發 WATCH 事件。而且由於每個節點本身通常都通過 kube-proxy 來 WATCH kubelet 服務，因此這些響應所需的帶寬將是 N^2 ，這是非常龐大的，偶爾甚至會達到1GB/s或更高。在 Kubernetes 1.17 中推出的 EndpointSlices 特性帶了很大的改善，它讓這個負載降低了1000倍。
一般來說，我們非常關注所有隨集群大小而擴展的 APIServer 請求，我們儘量避免 DaemonSet 與 APIServer 交互。如果確實需要這樣做，那麼引入中間緩存服務，例如 Datadog Cluster Agent，這是避免集群瓶頸的一個好的方式。
隨著我們集群的增長，我們對集群的實際自動伸縮操作比較少，但是當一次自動縮放過多時，我們偶爾還是會遇到一些問題，當新節點加入集群時，會生成很多請求，如果一次添加數百個節點可能會使 APIServer 容量過載，即使只需幾秒鐘就可以消除這種情況。
Prometheus 和 Grafana 的監控指標我們使用 Prometheus 收集監控指標，並使用 Grafana 進行圖形展示以及告警。我們首先部署 kube-prometheus，它收集各種各樣的指標來用於可視化儀錶板配置。隨著時間的推移，我們添加了很多自己的儀錶板、指標和告警。
隨著我們添加越來越多的節點，我們對 Prometheus 收集的大量指標而苦惱，儘管 kube-prometheus 提供了很多有用的數據，但其中一些我們實際上從未使用過，而有些則過於精細而無法有效地收集、存儲和查詢。我們使用 Prometheus 的 relabel 規則(https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config)來刪除其中的某些指標。
有一段時間，我們一直在努力解決一個問題，即 Prometheus 會消耗越來越多的內存，直到最終由於內存不足錯誤（OOM）使容器崩潰。即使在應用程式上投入了大量的內存容量之後，這種情況似乎仍會發生。更糟糕的是，當它真的崩潰時，在啟動時要花幾個小時才能重放 write-ahead-log 日誌文件才能正常。
最終，我們追蹤到這些 OOM 的來源是 Grafana 與 Prometheus 之間的交互，其中 Grafana 會在 Prometheus 上使用 /api/v1/series 這個接口並查詢{le!=""}，對於有大量結果的查詢，/api/v1/series 在時間和空間上都是不受限制的，但這將消耗越來越多的內存和時間。即使在請求者放棄並關閉連接後，它也會繼續增長。對於我們來說，內存永遠是不夠用的，Prometheus 最終都會崩潰。為此我們為 Prometheus 提交了一個patch(https://github.com/openai/prometheus/pull/1)，將這個 API 包含在一個 Context 中來強制超時，從而完全修復了這個 bug。
雖然 Prometheus 崩潰的頻率比較小，但在我們確實需要重新啟動它的時候，WAL replay 仍然是一個問題。在 Prometheus 收集新指標和服務查詢之前，經常需要花費幾個小時來重放所有 WAL 日誌。在 Robust Perception 的幫助下，我們發現配置 GOMAXPROCS=24 後會對 Prometheus 有很大的改善。
目前我們正在嘗試新的方案來增加我們的監控能力，在下面未解決問題部分有介紹。
健康檢查對於一個如此龐大的集群，我們當然要依靠自動化來檢測並從集群中移除異常的節點。隨著時間的推移，我們已經建立了一些健康檢查系統。
被動健康檢查有些健康檢查是被動的，並且始終在所有節點上運行。它們監控基本的系統資源，例如網絡可達性、磁碟損壞或磁碟容量、GPU 錯誤等。GPU 表現出的問題有很多不同的方式，但一個常見的問題是 Uncorrectable ECC error.，Nvidia 的數據中心 GPU 管理器工具可以很容易地查詢這個錯誤以及其他的一些 Xid 錯誤。我們跟蹤這些錯誤的一種方法是通過 dcgm-exporter(https://github.com/NVIDIA/gpu-monitoring-tools#dcgm-exporter)將指標抓取到我們的監控系統 Prometheus 中，當指標 DCGM_FI_DEV_XID_ERRORS 出現時，表示最近發生的錯誤代碼，此外，NVML 設備查詢 API 暴露了有關 GPU 的運行狀況的詳細信息。
一旦我們檢測到錯誤，它們通常可以通過重置 GPU 或系統來修復它們，儘管在某些情況下，它確實需要從底層上進行物理更換 GPU。
健康檢查的另一種形式是跟蹤來自上遊雲供應商的維護事件，大部分的雲提供商都會提供一種方法，以了解當前的虛擬機是否即將面臨即將發生的維護事件，而該事件最終會導致中斷。虛擬機可能需要重新啟動，以便應用底層的管理程序補丁，或者將物理節點換成其他硬體。
這些被動健康檢查在所有節點的後臺持續運行，如果健康檢查一開始就失敗，節點將自動被停用，因此不會在該節點上調度新的 Pod，對於更嚴重的健康檢查失敗，我們還將嘗試驅逐容器，以讓所有當前節點運行的容器立即退出。這些還是由 Pod本身決定，可以通過 Pod Disruption Budget 進行配置，決定是否要讓這種配置生效。最終，在所有 Pod 終止後或7天後，我們將強制停掉虛擬機。
主動 GPU 測試不幸的是，並非所有的 GPU 問題都可以通過 DCGM 獲知對應的錯誤代碼，我們已經建立了自己的測試庫，這些測試使用 GPU 來捕獲額外的問題，並確保硬體和驅動程序按預期運行，這些測試不能在後臺運行，它們需要獨佔使用 GPU 幾秒鐘或幾分鐘才能運行。
我們首先在啟動時在節點上運行這些測試，我們稱之為預檢系統，一開始，所有節點均以預檢汙點和標籤加入集群，此汙點會阻止在節點上調度普通的 Pod，將 DaemonSet 配置為在帶有此標籤的所有節點上運行預檢測試 Pod，成功完成測試後，測試本身將去除汙點和標籤，然後該節點即可用於常規用途。
然後，我們還將在節點的生命期內定期運行這些測試。我們將其作為 CronJob 運行，使其可以在集群中的所有可用節點上運行，當然這是隨機的，無法控制要測試的節點，但是我們發現，隨著時間的流逝，它可以提供足夠的覆蓋範圍，並且幹擾影響最小。
配額和資源使用當我們擴大集群規模時，研究人員開始發現自己很難獲得分配給他們的所有容量。傳統的作業調度系統有很多不同的功能，可以在團隊之間公平地運行工作任務，而 Kubernetes 沒有這些特性。隨著時間的推移，我們從那些作業調度系統中獲得了靈感，並以 Kubernetes 原生的方式構建了一些功能。
團隊汙點我們在每個集群中都有一個服務 team-resource-manager，它有多種功能。它的數據源是一個 ConfigMap，它為特定集群中所有研究團隊指定了一些元組標籤（節點選擇器、要應用的團隊標籤、分配數量等），它將與集群中的當前節點進行協調，並使用 openai.com/team=teamname:NoSchedule 標籤來保留適當數量的節點。
team-resource-manager 還有一個準入 webhook 服務，以便在提交每個作業時，根據提交者的團隊成員身份應用相應的容忍度，使用汙點可以使我們靈活地約束 Kubernetes Pod 調度器，例如允許對優先級較低的 Pod 允許 any 容忍，這樣就可以讓團隊互相借用對方的能力，而不需要重量級的協調。
CPU 和 GPU balloons除了使用 cluster-autoscaler 動態擴展我們的虛擬機支持的集群之外，我們還使用它來修復（刪除和重新添加）集群中不健康的成員，為此，我們將集群的最小大小設置為零，將集群的最大大小設置為可用容量來實現。但是，如果 cluster-autoscaler 看到空閒節點，它將嘗試縮小到需要的容量。由於多種原因（虛擬機啟動延遲、預先分配的成本、上面提到的 APIServer 影響），這種空閒擴展並不理想。
因此，我們為我們的 CPU 和 GPU 主機引入了一個 balloon 式部署。此部署包含一個有「最大大小」低優先級 Pod 數的 ReplicaSet，這些 Pod 佔用節點內的資源，因此 autoscaler 不認為它們是空閒的。但是，由於它們的優先級較低，調度程序可以立即將它們逐出，以便為實際工作騰出空間。（我們選擇使用 Deployment 而不是 DaemonSet，以避免 DaemonSet 被視為節點上的空閒工作負載。）
調度爭用我們的實驗通常涉及一個或多個 StatefulSet，每個 StatefulSet 都負責不同部分的訓練工作。對於優化器來說，研究人員需要 StatefulSet 的所有成員都被調度好，然後才能進行訓練。
但是，默認情況下，Kubernetes 不一定會優先滿足來自一個 StatefulSet 的所有請求。例如，如果兩個實驗都請求集群100%的容量，那麼 Kubernetes 可能只調度每個實驗的一半 Pod，而不是調度一個或另一個實驗的全部容量，從而導致死鎖，最終導致兩個實驗都無法進行。
我們嘗試了一些自定義調度程序的方式，但是遇到了一些極端情況，這些情況導致與普通 Pod 的調度方式發生衝突。Kubernetes 1.18引入了用於核心 Kubernetes 調度程序的插件架構，這使得在本地添加此類功能變得更加容易。最近我們落地了 Coscheduling 插件(https://github.com/kubernetes/enhancements/pull/1463)，是解決這個問題的好辦法。
未解決的問題在擴展 Kubernetes 集群時，我們仍有很多問題需要解決。其中幾個問題包括：
監控指標在我們的規模中，我們有很多問題都是與 Prometheus 的內置 TSDB 存儲引擎相關，因為它的壓縮很緩慢，一旦需要重啟，就需要很長的時間來重放 WAL，查詢還會導致 query processing would load too many samples 錯誤，當前，我們正在遷移到另一個與 Prometheus 兼容的存儲和查詢引擎，期待未來的有機會介紹!
Pod 網絡 traffic shaping隨著我們集群規模的擴大，每個 Pod 都會被計算為有一定的外網帶寬，每個人對帶寬的總需求已經變得相當大了，並且我們的研究人員現在在無意間對外網的訪問（例如，下載數據和安裝軟體包）帶來了巨大的資源壓力。
結論我們發現 Kubernetes 是一個非常靈活的平臺，可以滿足我們的研究需求，它有能力擴展以滿足我們所需要的最苛刻的工作負載。不過還有很多地方需要改進，OpenAI 的超級計算團隊將繼續探索 Kubernetes 如何擴展。
原文連結：https://openai.com/blog/scaling-kubernetes-to-7500-nodes/