本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 遇見高效能計算
任何使用過 Docker 的人都深知容器所帶來的巨大效率提升。雖然 Kubernetes 在容器編排方面表現出色，但高效能計算 (HPC) 應用在 Kubernetes 上部署可能會很棘手。
在這篇文章中，我將討論使用 Kubernetes 執行 HPC 工作負載的一些挑戰，解釋當前組織如何應對這些挑戰，並提出一種在共享 Kubernetes 叢集上支援混合工作負載的方法。我們還將提供關於客戶 IHME 的案例研究資訊和連結，展示 Kubernetes 如何無縫擴充套件以服務其 HPC 工作負載，同時保持 HPC 使用者熟悉的擴充套件性和介面。
HPC 工作負載的獨特挑戰
在 Kubernetes 中，排程的基本單元是 Pod：一個或多個排程到叢集主機的 Docker 容器。Kubernetes 假定工作負載是容器。雖然 Kubernetes 有 Cron Job 和 Job 執行至完成的概念，但部署在 Kubernetes 上的應用程式通常是長時間執行的服務，例如 Web 伺服器、負載均衡器或資料儲存。雖然它們具有高度動態性，Pod 進出頻繁，但它們與 HPC 應用程式模式大相徑庭。
傳統的 HPC 應用程式通常表現出不同的特徵
- 在金融或工程模擬中，一個作業可能包含數萬個短時執行任務，需要低延遲和高吞吐量的排程，才能在可接受的時間內完成模擬。
- 計算流體動力學 (CFD) 問題可能在數百甚至數千個節點上並行執行，使用訊息傳遞庫來同步狀態。這需要專門的排程和作業管理功能來分配和啟動此類作業，然後對其進行檢查點、暫停/恢復或回填。
- 其他 HPC 工作負載可能需要專用資源，如 GPU，或者需要訪問有限的軟體許可證。組織可能會強制執行關於誰可以使用何種型別的資源的策略，以確保專案獲得足夠的資源並按時完成。
HPC 工作負載排程器已經發展到能夠精確支援這些型別的工作負載。示例包括 Univa Grid Engine、IBM Spectrum LSF 和 Altair 的 PBS Professional。管理 HPC 工作負載的站點已經開始依賴諸如陣列作業、可配置搶佔、基於使用者、組或專案的配額以及各種其他功能。
容器與 HPC 之間的界限模糊
HPC 使用者認為容器的價值與為其他組織帶來價值的原因相同。將邏輯打包到容器中，使其具有可移植性，與環境依賴項隔離，並易於與其他容器交換，這顯然具有價值。然而，轉向容器可能很困難。
HPC 工作負載通常在命令列級別整合。作業不是透過編碼，而是透過命令列作為二進位制檔案或充當包裝器的簡單 shell 指令碼提交到佇列。HPC 站點使用的工程、科學和分析應用程式有數百個，它們都採用這種方法，並與流行的工作負載排程器進行了成熟且經過認證的整合。
雖然將工作負載打包到 Docker 容器中，釋出到登錄檔，並提交工作負載的 YAML 描述對 Kubernetes 使用者來說是第二天性，但這對於大多數 HPC 使用者來說是陌生的。執行 R、MATLAB 或 Stata 模型的分析師只想儘快提交模擬，監控其執行，並儘快獲得結果。
現有方法
為了應對遷移到容器的挑戰，執行容器和 HPC 工作負載的組織有幾個選擇
- 維護獨立的 инфраструктура
對於在 HPC 上有沉沒投資的站點，這可能是一種首選方法。與其擾亂現有環境，不如在單獨的叢集上部署新的容器化應用程式，讓 HPC 環境保持不變。挑戰在於，這會帶來叢集孤立的代價，增加基礎設施和管理成本。
- 在現有 HPC 工作負載管理器下執行容器化工作負載
對於執行傳統 HPC 工作負載的站點，另一種方法是使用現有的作業提交機制來啟動作業，這些作業反過來在一個或多個目標主機上例項化 Docker 容器。採用這種方法的站點可以在對環境的干擾最小的情況下引入容器化工作負載。領先的 HPC 工作負載管理器，如 Univa Grid Engine Container Edition 和 IBM Spectrum LSF 正在增加對 Docker 容器的原生支援。Shifter 和 Singularity 也是支援這種部署的重要開源工具。雖然這對於有簡單需求並希望堅持使用其 HPC 排程器的站點來說是一個很好的解決方案，但他們將無法訪問原生 Kubernetes 功能，這可能會限制管理 Kubernetes 擅長的長時間執行服務的靈活性。
- 使用 Kubernetes 中的原生作業排程功能
對現有 HPC 應用程式投入較少的站點可以使用 Kubernetes 中現有的排程設施來處理 執行至完成的作業。雖然這是一個選項，但對於許多 HPC 使用者來說可能不切實際。HPC 應用程式通常要麼針對大規模吞吐量進行最佳化，要麼針對大規模並行性進行最佳化。在這兩種情況下，啟動和關閉延遲都會產生顯著影響。對於當前的容器化微服務來說可以接受的延遲，將使此類應用程式無法擴充套件到所需的級別。
所有這些解決方案都涉及權衡。第一個選項不允許共享資源（增加成本），而第二個和第三個選項要求客戶選擇單個排程器，從而限制了未來的靈活性。
Kubernetes 上的混合工作負載
更好的方法是在同一個共享環境中原生支援 HPC 和容器工作負載。理想情況下，使用者應該看到適合其工作負載或工作流型別的環境。
支援混合工作負載的一種方法是允許 Kubernetes 和 HPC 工作負載管理器在同一叢集上共存，透過限制資源以避免衝突。雖然簡單，但這意味著兩個工作負載管理器都無法充分利用叢集。
另一種方法是使用與 Kubernetes 排程器協調的對等排程器。Univa 的 Navops Command 就是採用這種第三種方法的解決方案，它增強了 Kubernetes 排程器的功能。Navops Command 提供自己的 Web 介面和 CLI，並允許在 Kubernetes 上啟用額外的排程策略，而不會影響 Kubernetes 排程器和現有容器化應用程式的操作。Navops Command 透過 Pod 規範中的“schedulerName”屬性作為對等排程器插入 Kubernetes 架構，工作負載可以選擇使用它而不是 Kubernetes 原生排程器，如下圖所示。
透過這種方法，Kubernetes 充當資源管理器，將資源提供給獨立的 HPC 排程器。叢集管理員可以使用視覺化介面根據策略分配資源，或者透過 Web UI 簡單地拖動滑塊，將 Kubernetes 環境的不同比例分配給非容器 (HPC) 工作負載以及原生 Kubernetes 應用程式和服務。
從客戶端的角度來看，HPC 排程器作為部署在 Kubernetes Pods 中的服務執行，其操作方式與在裸機叢集上完全相同。Navops Command 提供額外的排程功能，包括資源預留、執行時配額、工作負載搶佔等。這種環境同樣適用於本地部署、基於雲的部署或混合部署。
在 IHME 部署混合工作負載
在混合工作負載方面取得成功的一個客戶是健康計量與評估研究所 (IHME)，它是華盛頓大學的一個獨立健康研究中心。為支援其全球公認的全球健康資料交換 (GHDx)，IHME 運營著一個規模龐大的環境，由 500 個節點和 20,000 個核心組成，在 Kubernetes 上執行混合的分析、HPC 和基於容器的應用程式。此案例研究描述了 IHME 如何使用 Navops Command 在共享 Kubernetes 叢集上成功託管現有 HPC 工作負載。
對於部署新叢集、希望訪問 Kubernetes 豐富功能但又需要靈活性來執行非容器化工作負載的站點，這種方法值得一試。它為站點提供了在 Kubernetes 和 HPC 工作負載之間共享基礎設施的機會，而不會擾亂現有應用程式和業務流程。它還允許他們按照自己的節奏將 HPC 工作負載遷移到使用 Docker 容器。