Kubernetes 遇上高效能運算

任何使用過 Docker 的人都會了解容器在效率方面可實現的巨大提升。雖然 Kubernetes 擅長協調容器，但高效能運算 (HPC) 應用程式可能很難在 Kubernetes 上部署。

在這篇文章中，我將討論在 Kubernetes 上執行 HPC 工作負載的一些挑戰，說明組織目前如何應對這些挑戰，並針對在共用 Kubernetes 叢集上支援混合工作負載提出一種方法。我們也將提供資訊和連結，前往客戶 IHME 的案例研究，展示如何擴展 Kubernetes 以無縫地服務其 HPC 工作負載，同時保留 HPC 使用者熟悉的擴展性和介面。

HPC 工作負載獨特的挑戰

在 Kubernetes 中，排程的基本單位是 Pod：排程到叢集主機的一個或多個 Docker 容器。Kubernetes 假設工作負載是容器。雖然 Kubernetes 具有Cron Jobs 和 Jobs 的概念，可以運行到完成，但在 Kubernetes 上部署的應用程式通常是長時間運行的服務，例如 Web 伺服器、負載平衡器或資料儲存庫，雖然它們高度動態，Pod 來來去去，但它們與 HPC 應用程式模式大不相同。

傳統的 HPC 應用程式通常展現出不同的特性

• 在金融或工程模擬中，一個 Job 可能由數以萬計的短時間運行的任務組成，需要低延遲和高吞吐量的排程，才能在可接受的時間內完成模擬。
• 計算流體力學 (CFD) 問題可能會跨越數百甚至數千個節點並行執行，使用訊息傳遞函式庫來同步狀態。這需要專門的排程和 Job 管理功能來分配和啟動此類 Job，然後進行檢查點、暫停/恢復或回填。
• 其他 HPC 工作負載可能需要專門的資源，例如 GPU，或需要存取有限的軟體授權。組織可能會強制執行關於哪些類型的資源可以由誰使用的政策，以確保專案資源充足並按時完成。

HPC 工作負載排程器已經發展到完全支援這些類型的工作負載。範例包括 Univa Grid Engine、IBM Spectrum LSF 和 Altair 的 PBS Professional。管理 HPC 工作負載的站點已經開始依賴諸如陣列 Job、可配置的搶佔、使用者、群組或專案配額以及各種其他功能等功能。

模糊容器和 HPC 之間的界線

HPC 使用者認為容器很有價值，原因與其他組織相同。將邏輯封裝在容器中以使其可移植、與環境依賴性隔離，並易於與其他容器交換，顯然具有價值。但是，轉換到容器可能很困難。

HPC 工作負載通常在命令列層級整合。Job 不是需要編碼，而是透過命令列以二進位檔案或充當包裝器的簡單 Shell 腳本的形式提交到佇列。HPC 站點使用的工程、科學和分析應用程式實際上數以百計，它們採用這種方法，並且與流行的工作負載排程器具有成熟且經過認證的整合。

雖然對於 Kubernetes 使用者來說，將工作負載封裝到 Docker 容器中、發佈到登錄檔以及提交工作負載的 YAML 描述是第二天性，但對於大多數 HPC 使用者來說，這是陌生的。在 R、MATLAB 或 Stata 中運行模型分析師只想快速提交他們的模擬、監控他們的執行，並儘快獲得結果。

現有方法

為了應對遷移到容器的挑戰，運行容器和 HPC 工作負載的組織有幾種選擇

• 維護獨立的基礎架構

對於在 HPC 中有沉沒成本的站點，這可能是首選方法。與其破壞現有的環境，不如在單獨的叢集上部署新的容器化應用程式，並保持 HPC 環境不動可能更容易。挑戰在於，這會以叢集孤島化為代價，增加基礎架構和管理成本。

• 在現有的 HPC 工作負載管理器下運行容器化工作負載

對於運行傳統 HPC 工作負載的站點，另一種方法是使用現有的 Job 提交機制來啟動 Job，而 Job 又會在一個或多個目標主機上實例化 Docker 容器。使用這種方法的站點可以以最小的環境破壞引入容器化的工作負載。領先的 HPC 工作負載管理器，例如 Univa Grid Engine Container Edition 和 IBM Spectrum LSF 正在新增對 Docker 容器的原生支援。Shifter 和 Singularity 也是支援此類型部署的重要開放原始碼工具。雖然這對於需求簡單且想要堅持使用 HPC 排程器的站點來說是一個很好的解決方案，但他們將無法存取原生 Kubernetes 功能，這可能會限制管理 Kubernetes 擅長的長時間運行服務的彈性。

• 在 Kubernetes 中使用原生 Job 排程功能

在現有 HPC 應用程式中投資較少的站點可以使用 Kubernetes 中現有的排程設施來處理 運行到完成的 Job。雖然這是一個選項，但對於許多 HPC 使用者來說可能不切實際。HPC 應用程式通常針對大規模吞吐量或大規模並行性進行了最佳化。在這兩種情況下，啟動和關閉延遲都具有區分性的影響。對於今天的容器化微服務來說似乎可以接受的延遲會使此類應用程式無法擴展到所需的水平。

所有這些解決方案都涉及權衡。第一種選項不允許資源共享（增加成本），第二種和第三種選項要求客戶選擇單一排程器，限制了未來的彈性。

Kubernetes 上的混合工作負載

更好的方法是在相同的共用環境中原生支援 HPC 和容器工作負載。理想情況下，使用者應該看到適合其工作負載或工作流程類型的環境。

支援混合工作負載的一種方法是允許 Kubernetes 和 HPC 工作負載管理器在同一個叢集上共存，限制資源以避免衝突。雖然簡單，但這意味著任何一個工作負載管理器都無法完全利用叢集。

另一種方法是使用與 Kubernetes 排程器協調的對等排程器。Univa 的 Navops Command 是採用第三種方法的解決方案，它增強了 Kubernetes 排程器的功能。Navops Command 提供自己的網頁介面和 CLI，並允許在 Kubernetes 上啟用額外的排程策略，而不會影響 Kubernetes 排程器和現有容器化應用程式的運作。Navops Command 透過 Pod 規格中的 'schedulerName' 屬性插入 Kubernetes 架構，作為工作負載可以選擇使用的對等排程器，而不是 Kubernetes 庫存排程器，如下所示。

透過這種方法，Kubernetes 充當資源管理器，使資源可用於單獨的 HPC 排程器。叢集管理員可以使用可視化介面根據策略分配資源，或只需透過網頁 UI 拖曳滑桿，即可將 Kubernetes 環境的不同比例分配給非容器（HPC）工作負載以及原生 Kubernetes 應用程式和服務。

從用戶端的角度來看，HPC 排程器作為部署在 Kubernetes Pod 中的服務運行，其運作方式與在裸機叢集上相同。Navops Command 提供額外的排程功能，包括資源預留、運行時間配額、工作負載搶佔等。此環境同樣適用於內部部署、雲端或混合部署。

在 IHME 部署混合工作負載

健康指標與評估研究所 (IHME) 是一個在混合工作負載方面取得成功的客戶，它是華盛頓大學的一個獨立健康研究中心。為了支援他們全球公認的全球健康資料交換 (GHDx)，IHME 運營著一個規模相當大的環境，由 500 個節點和 20,000 個核心組成，在 Kubernetes 上運行著分析、HPC 和基於容器的應用程式的混合。 此案例研究 描述了 IHME 使用 Navops Command 在共用 Kubernetes 叢集上託管現有 HPC 工作負載的成功經驗。

對於部署想要存取 Kubernetes 中豐富功能但需要靈活運行非容器化工作負載的新叢集的站點來說，這種方法值得一看。它為站點提供了在 Kubernetes 和 HPC 工作負載之間共享基礎架構的機會，而不會破壞現有的應用程式和業務流程。它也允許他們以自己的步調將 HPC 工作負載遷移到使用 Docker 容器。

• ←上一篇
下一篇→