看 OpenAI 使用鈔能力招喚 Kubernetes 7500 台節點!!! - Phil's Wor...

Facebook

Ref Ray 整理
OpenAI 如何用 Kubernetes 基礎建設。

chatGPT

OpenAI 採用 Kubernetes 主要 3 大效益
1 易搬遷 (Porability): 基於基礎架構即代碼 (Infrastructure as Code, IaC)、Kubernetes 聲明式宣告及一致的 API (Declarative & Consistent API)、容器映像檔不可變動性 (Container Immutable Image) 3 個特性，讓你可以在不同的雲端平台上運行你的雲原生程式

2 省成本 (Cost Savings): 在不同開發情境的時候，可以容易移動你的資源，例如：在開發階段可以使用本地的 Kubernetes 環境，如 minikube, kind, kubeadm, Docker Desktop 等，而在生產階段則可以使用大規模且受支援的 Kubernetes 環境，如 Azure Kubernetes Service 等，和 Kubernetes Cluster Autoscaler (CA) 自動調整叢集大小．透過彈性選擇適當的環境，降低整體成本，提升利用率，獲得更多硬體計算資源

3 增效率 (Improved Efficiency): 一名開發分散式系統系統的研究員，可以在 2 ~ 3 天內, 讓他的程式正確運行，1 ~ 2 週後就可以擴張到好幾百個 GPU 節點，相較於以前則是需要以月為單位的工作時間，保持開發快速迭代的效益

看 OpenAI 使用鈔能力: 7,500 節點規模

計算相關運行 MPI Jobs: 以 MPI 作為調度基礎，而非大量利用 Kubernetes 內建之 Scheduler, 最常見錯誤為 Uncorrectable ECC error

GPU 相關GPU 間通訊強化: 利用 NVIDIA NVlink 交叉通訊和 GPUDirect RDMA 與 NIC 直接通訊使整體系統輸送量極大化
多數 1 個節點放 1 個 Pod: 因 CPU / NUMA / PCI-E / Physical Server / Bandwidth 並非調度資源的主因，調度壓力極低，主要是 GPU 資源

儲存相關採用 Azure Blob Storage 作為主要儲存系統: 因為 Azure Blob Storage 易於擴展，且不需要 slow detach/attach 的額外操作

-Log-
Kubernetes 相關無進行過 etcd self-healing automation，最大的叢集單獨運行 5 個 API Server 和 5 個 etcd 節點
節點數量多，導致 API Server 記憶體吃重: 基於 7500 台節點叢集，每個 API Servers 需要 70GB 的記憶體

API Server 壓力最大來源是 Endpoints 上的 WATCH
Cluster Autoscaler 情境減少，因為叢集已經很大了

針對團隊資源分配實做 team-resource-manager
採用 CPU & GPU Balloons 讓 Cluster Autoscaler 不會認為節點閒置而進行移除，避免產生不必要的調度壓力
採用 Pod Anti-affinity 確保 Pod 最終會被平均地分佈到各個節點上, 採用 Coscheduling 批次處理，避免 all or nothing 的情況

log

Monitoring 相關採用 Promeheus 和 Grafana 作為監控系統
採用 kube-prometheus: 對於 HTTP 429 (Too Many Requests) 和 5XX (Server Error) 發送警報相當有效果

在佈天網惹

這只是剛開始？！