Kubernetes Extended Resource 擴充套件資源使用簡介

凌虚發表於2024-11-06
套件

Kubernetes 除了提供基於 CPU 和記憶體的傳統計算資源排程外，還支援自定義的 Extended Resource 擴充套件資源，以便排程和管理其它各種型別的資源。

Extended Resource

Extended Resource 擴充套件資源的建立和使用過程如下圖所示：

  1. 定義資源：使用者或管理員透過 Kubernetes API 向特定的節點新增自定義的擴充套件資源（即修改節點的 status 資訊）。例如，圖中新增的資源 example.com/dongle，擁有 4 個單位。
  2. 節點同步資源：kubelet 會在定時同步節點狀態時，透過 GET /api/v1/nodes/<nodeName> 請求從 kube-apiserver 獲取節點的資源資訊，從而同步到該擴充套件資源的資料。
  3. 排程和使用：使用者建立一個請求 example.com/dongle 擴充套件資源的 Pod，Scheduler 會將該 Pod 排程到滿足條件的節點上。隨後該節點上的 kubelet 負責建立和啟動 Pod。

一旦 Extended Resource 被新增到節點上，Kubernetes 將自動管理該資源在 Pod 排程和建立過程中的分配和使用情況，無需使用者手動干預。

然而，節點的 status.allocatable 中的擴充套件資源資訊不會隨著 Pod 的建立和刪除實時更新。例如，假設某個 Pod 使用了 example.com/dongle 的 3 個單位資源，但在檢視節點狀態時，status.allocatable 中的 example.com/dongle 仍然顯示為 4 個單位。這種非實時更新設計的目的是為了減少對 kube-apiserver 和 etcd 的頻繁更新，避免增加系統負載。

此時你可能會疑惑，如果可分配資源資訊不實時更新，資源排程不會有問題嗎？答案是不會，因為 scheduler 和 kubelet 都會在各自的程序中記錄並追蹤資源的使用情況。

擴充套件資源的侷限性

雖然 Extended Resource 的設計看起來簡單，似乎只需透過 API 為節點新增資源即可，但其應用往往伴隨著以下挑戰：

  • 資源的配置和使用：例如，定義 GPU 作為 Extended Resource 後，Scheduler 可以正常完成排程，但容器實際使用 GPU 時，還需要適配驅動和執行時環境（如 NVIDIA 容器執行時）。這意味著擴充套件資源僅宣告和排程是不夠的，還需要配置支援相關硬體的容器環境。
  • 自動化管理需求：手動為每個節點逐一新增或修改擴充套件資源並不實際，特別是在有多個節點或複雜硬體需求的場景中。依賴人工管理難以保證擴充套件資源的一致性和效率。

因此，在實際應用中，為了更好地管理和使用擴充套件資源，通常會藉助 Device Plugin 和 Operator。Device Plugin 是 Kubernetes 提供的裝置管理機制，透過它可以自動檢測和管理擴充套件資源，如 GPU 等特殊硬體。Operator 則進一步簡化了資源部署和配置管理流程，自動執行資源的配置和排程。

想深入瞭解這方面內容，可以參考我之前的文章 《Kubernetes GPU 排程和 Device Plugin、CDI、NFD、GPU Operator 概述》。

總結

Extended Resource 為 Kubernetes 提供了靈活的擴充套件能力，使叢集能夠支援更多樣化的資源型別。然而在實踐中，它僅解決了資源宣告和排程的一部分問題。

(我是凌虛，關注我，無廣告，專注技術，不煽動情緒，歡迎與我交流)

參考資料：

  • https://kubernetes.io/docs/tasks/administer-cluster/extended-...
  • https://kubernetes.io/docs/tasks/configure-pod-container/exte...

相關文章