本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
Kubernetes 1.26: Device Manager 進階至 GA
裝置外掛（Device Plugin）框架在 Kubernetes v1.8 版本中引入，作為一個獨立於供應商的框架，無需修改 Kubernetes 核心程式碼即可實現外部裝置的發現、通告和分配。該功能在 v1.10 版本中升級為 Beta。隨著 Kubernetes v1.26 的最新發布，裝置管理器（Device Manager）現已正式可用（GA）。
在 kubelet 內部，裝置管理器透過 Unix 套接字使用 gRPC 與裝置外掛進行通訊。裝置管理器和裝置外掛都透過分別提供和連線到暴露的 gRPC 服務，同時充當 gRPC 的伺服器和客戶端。裝置外掛提供一個 gRPC 服務，kubelet 連線該服務以進行裝置發現、通告（作為擴充套件資源）和分配。裝置管理器連線到由 kubelet 提供的 Registration gRPC 服務，以向 kubelet 註冊自身。
有關 Pod 如何請求由裝置外掛暴露給叢集的裝置的示例，請參閱文件。
以下是一些裝置外掛的實現示例：
自裝置外掛框架引入以來的顯著發展
Kubelet API 移至 kubelet staging 倉庫
面向外部的 deviceplugin API 包在 v1.17 中從 k8s.io/kubernetes/pkg/kubelet/apis/ 移至 k8s.io/kubelet/pkg/apis/。有關此更改背後原因的更多詳細資訊，請參閱 將面向外部的 kubelet API 移至 staging。
裝置外掛 API 更新
引入了額外的 gRPC 端點
GetDevicePluginOptions由裝置外掛用於向DeviceManager傳達選項，以指示是否支援PreStartContainer、GetPreferredAllocation或其他未來的可選呼叫，並可以在將裝置提供給容器之前呼叫這些介面。GetPreferredAllocation允許裝置外掛將分配偏好轉發給DeviceManager，以便後者可以在其分配決策中納入此資訊。DeviceManager將在 Pod 准入時呼叫外掛，請求從可用裝置列表中為給定大小的請求提供首選的裝置分配，從而做出更明智的決策。例如，在為容器分配裝置時，指定裝置間的約束以表明對連線性最佳的裝置集的偏好。- 如果在註冊階段由裝置外掛指定，
PreStartContainer會在每個容器啟動前被呼叫。它允許裝置外掛在所請求的裝置上執行特定於裝置的操作。例如，在容器開始執行前重新配置或重新程式設計 FPGA。
引入這些更改的拉取請求如下：
隨著上述端點的引入，kubelet 中的裝置管理器與裝置外掛之間的互動如下圖所示：
裝置外掛框架概述
裝置外掛註冊流程的語義變化
裝置外掛程式碼被重構，將 `plugin` 包分離到 devicemanager 包下，為引入 v1beta2 裝置外掛 API 奠定基礎。這將允許在 devicemanager 中增加同時為多個裝置外掛 API 提供支援的能力。
透過這次重構工作，裝置外掛現在必須在向 kubelet 註冊之前啟動其 gRPC 服務。以前，這兩個操作是非同步的，裝置外掛可以在啟動其 gRPC 伺服器之前註冊自己，但現在情況已不再如此。更多詳情，請參閱 PR #109016 和 Issue #112395。
動態資源分配
在 Kubernetes 1.26 中，受 Kubernetes 中處理持久卷（Persistent Volumes）方式的啟發，引入了動態資源分配（Dynamic Resource Allocation），以滿足具有更復雜資源需求的裝置，例如：
- 將裝置初始化和分配與 Pod 生命週期解耦。
- 促進容器和 Pod 之間裝置的動態共享。
- 支援自定義的特定於資源的引數。
- 啟用特定於資源的設定和清理操作。
- 不僅支援節點本地資源，還支援網路附加資源。
裝置外掛 API 現在穩定了嗎？
不，裝置外掛 API 仍然不穩定；當前可用的最新裝置外掛 API 版本是 v1beta1。社群計劃引入 v1beta2 API，以同時為多個外掛 API 提供服務。每個 API 呼叫都帶有請求/響應型別，這將允許在不明確提升 API 版本的情況下增加對新 API 版本的支援。
除此之外，社群中還有一些現有的提議，旨在引入額外的端點 KEP-3162：向裝置管理器 API 新增 Deallocate 和 PostStopContainer。