设备插件

Kubernetes 提供了一个设备插件框架，您可以使用它向 Kubelet 公布系统硬件资源。

供应商无需自定义 Kubernetes 本身的代码，而是可以实现一个设备插件，您可以手动部署该插件，也可以将其作为 守护进程集 部署。目标设备包括 GPU、高性能网卡、FPGA、InfiniBand 适配器以及其他可能需要特定于供应商的初始化和设置的类似计算资源。

设备插件注册

kubelet 导出一个 Registration gRPC 服务

service Registration {
	rpc Register(RegisterRequest) returns (Empty) {}
}

设备插件可以通过此 gRPC 服务向 kubelet 注册自身。在注册过程中，设备插件需要发送

• 其 Unix 套接字的名称。
• 构建该插件所依据的设备插件 API 版本。
• 它要公布的 ResourceName。这里 ResourceName 需要遵循 扩展资源命名方案，格式为 vendor-domain/resourcetype。（例如，NVIDIA GPU 被公布为 nvidia.com/gpu。）

成功注册后，设备插件会向 kubelet 发送其管理的设备列表，然后 kubelet 负责在 kubelet 节点状态更新中将这些资源公布到 API 服务器。例如，在一个设备插件向 kubelet 注册 hardware-vendor.example/foo 并报告节点上有两个正常设备后，节点状态将更新为公布该节点已安装并可用 2 个“Foo”设备。

然后，用户可以请求设备作为 Pod 规范的一部分（请参阅 container）。请求扩展资源类似于管理其他资源的请求和限制，但存在以下区别

• 扩展资源仅支持作为整数资源，并且不能超额分配。
• 设备不能在容器之间共享。

示例

假设 Kubernetes 集群正在运行一个设备插件，该插件在某些节点上公布资源 hardware-vendor.example/foo。下面是一个 Pod 请求此资源以运行演示工作负载的示例

---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: demo-container-1
      image: registry.k8s.io/pause:2.0
      resources:
        limits:
          hardware-vendor.example/foo: 2
#
# This Pod needs 2 of the hardware-vendor.example/foo devices
# and can only schedule onto a Node that's able to satisfy
# that need.
#
# If the Node has more than 2 of those devices available, the
# remainder would be available for other Pods to use.

设备插件实现

设备插件的一般工作流程包括以下步骤

1. 初始化。在此阶段，设备插件执行特定于供应商的初始化和设置，以确保设备处于就绪状态。

2. 插件启动一个 gRPC 服务，其 Unix 套接字位于主机路径 /var/lib/kubelet/device-plugins/ 下，该服务实现以下接口

   service DevicePlugin {
         // GetDevicePluginOptions returns options to be communicated with Device Manager.
         rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
   
         // ListAndWatch returns a stream of List of Devices
         // Whenever a Device state change or a Device disappears, ListAndWatch
         // returns the new list
         rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
   
         // Allocate is called during container creation so that the Device
         // Plugin can run device specific operations and instruct Kubelet
         // of the steps to make the Device available in the container
         rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
   
         // GetPreferredAllocation returns a preferred set of devices to allocate
         // from a list of available ones. The resulting preferred allocation is not
         // guaranteed to be the allocation ultimately performed by the
         // devicemanager. It is only designed to help the devicemanager make a more
         // informed allocation decision when possible.
         rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
   
         // PreStartContainer is called, if indicated by Device Plugin during registration phase,
         // before each container start. Device plugin can run device specific operations
         // such as resetting the device before making devices available to the container.
         rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
   }
   

   注意

   插件不需要为 GetPreferredAllocation() 或 PreStartContainer() 提供有用的实现。指示这些调用可用性的标志（如果有）应在调用 GetDevicePluginOptions() 返回的 DevicePluginOptions 消息中设置。kubelet 将始终调用 GetDevicePluginOptions() 以查看哪些可选函数可用，然后再直接调用它们。

3. 插件通过主机路径 /var/lib/kubelet/device-plugins/kubelet.sock 上的 Unix 套接字向 kubelet 注册自身。

   注意

   工作流程的顺序很重要。插件必须在向 kubelet 注册自身之前启动 gRPC 服务，才能成功注册。

4. 成功注册自身后，设备插件将以服务模式运行，在此期间，它会持续监控设备运行状况，并在任何设备状态发生变化时向 kubelet 报告。它还负责处理 Allocate gRPC 请求。在 Allocate 期间，设备插件可以执行特定于设备的准备工作；例如，GPU 清理或 QRNG 初始化。如果操作成功，设备插件将返回一个 AllocateResponse，其中包含用于访问已分配设备的容器运行时配置。kubelet 会将此信息传递给容器运行时。

   AllocateResponse 包含零个或多个 ContainerAllocateResponse 对象。在这些对象中，设备插件定义了必须对容器的定义进行的修改，以便提供对设备的访问权限。这些修改包括

   • 注释
   • 设备节点
   • 环境变量
   • 挂载
   • 完全限定的 CDI 设备名称

   注意

   设备管理器对完全限定的 CDI 设备名称的处理要求为 kubelet 和 kube-apiserver 启用 DevicePluginCDIDevices 特性门控。这在 Kubernetes v1.28 中作为 alpha 特性添加，并在 v1.29 中升级为 beta 特性。

处理 kubelet 重启

设备插件应检测 kubelet 重启并向新的 kubelet 实例重新注册自身。新的 kubelet 实例在启动时会删除 /var/lib/kubelet/device-plugins 下的所有现有 Unix 套接字。设备插件可以监控其 Unix 套接字的删除，并在发生此类事件时重新注册自身。

设备插件部署

您可以将设备插件部署为守护进程集、节点操作系统的软件包或手动部署。

规范目录 /var/lib/kubelet/device-plugins 需要特权访问权限，因此设备插件必须在特权安全上下文中运行。如果您要将设备插件部署为守护进程集，则必须将 /var/lib/kubelet/device-plugins 作为 卷 挂载到插件的 PodSpec 中。

如果您选择守护进程集方法，则可以依赖 Kubernetes 来：将设备插件的 Pod 放置到节点上，在发生故障后重启守护进程 Pod，以及帮助自动化升级。

API 兼容性

以前，版本控制方案要求设备插件的 API 版本与 Kubelet 的版本完全匹配。自从此特性在 v1.12 中升级为 Beta 版本后，这不再是硬性要求。API 是版本化的，并且自此特性升级为 Beta 版本后一直保持稳定。因此，kubelet 升级应该是无缝的，但在稳定之前，API 中仍然可能会有更改，因此不能保证升级不会中断。

作为一个项目，Kubernetes 建议设备插件开发人员

• 关注未来版本中设备插件 API 的变化。
• 支持多个版本的设备插件 API，以实现向后/向前兼容性。

要在需要升级到具有更新设备插件 API 版本的 Kubernetes 版本的节点上运行设备插件，请在升级这些节点之前将设备插件升级为同时支持这两个版本。采用这种方法将确保在升级过程中设备分配的持续运行。

监控设备插件资源

为了监控设备插件提供的资源，监控代理需要能够发现节点上正在使用的设备集，并获取元数据来描述指标应该与哪个容器相关联。由设备监控代理公开的 Prometheus 指标应该遵循 Kubernetes 指标指南，使用 pod、namespace 和 container Prometheus 标签来标识容器。

kubelet 提供了一个 gRPC 服务，用于发现正在使用的设备，并为这些设备提供元数据。

// PodResourcesLister is a service provided by the kubelet that provides information about the
// node resources consumed by pods and containers on the node
service PodResourcesLister {
    rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
    rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {}
    rpc Get(GetPodResourcesRequest) returns (GetPodResourcesResponse) {}
}

List gRPC 端点

List 端点提供有关正在运行的 Pod 的资源信息，包括独占分配的 CPU 的 ID、设备插件报告的设备 ID 以及分配这些设备的 NUMA 节点的 ID 等详细信息。此外，对于基于 NUMA 的机器，它还包含有关为容器保留的内存和巨页的信息。

从 Kubernetes v1.27 开始，List 端点可以提供有关 DynamicResourceAllocation API 在 ResourceClaims 中分配的正在运行的 Pod 的资源信息。要启用此功能，必须使用以下标志启动 kubelet：

--feature-gates=DynamicResourceAllocation=true,KubeletPodResourcesDynamicResources=true

// ListPodResourcesResponse is the response returned by List function
message ListPodResourcesResponse {
    repeated PodResources pod_resources = 1;
}

// PodResources contains information about the node resources assigned to a pod
message PodResources {
    string name = 1;
    string namespace = 2;
    repeated ContainerResources containers = 3;
}

// ContainerResources contains information about the resources assigned to a container
message ContainerResources {
    string name = 1;
    repeated ContainerDevices devices = 2;
    repeated int64 cpu_ids = 3;
    repeated ContainerMemory memory = 4;
    repeated DynamicResource dynamic_resources = 5;
}

// ContainerMemory contains information about memory and hugepages assigned to a container
message ContainerMemory {
    string memory_type = 1;
    uint64 size = 2;
    TopologyInfo topology = 3;
}

// Topology describes hardware topology of the resource
message TopologyInfo {
        repeated NUMANode nodes = 1;
}

// NUMA representation of NUMA node
message NUMANode {
        int64 ID = 1;
}

// ContainerDevices contains information about the devices assigned to a container
message ContainerDevices {
    string resource_name = 1;
    repeated string device_ids = 2;
    TopologyInfo topology = 3;
}

// DynamicResource contains information about the devices assigned to a container by Dynamic Resource Allocation
message DynamicResource {
    string class_name = 1;
    string claim_name = 2;
    string claim_namespace = 3;
    repeated ClaimResource claim_resources = 4;
}

// ClaimResource contains per-plugin resource information
message ClaimResource {
    repeated CDIDevice cdi_devices = 1 [(gogoproto.customname) = "CDIDevices"];
}

// CDIDevice specifies a CDI device information
message CDIDevice {
    // Fully qualified CDI device name
    // for example: vendor.com/gpu=gpudevice1
    // see more details in the CDI specification:
    // https://github.com/container-orchestrated-devices/container-device-interface/blob/main/SPEC.md
    string name = 1;
}

GetAllocatableResources gRPC 端点

GetAllocatableResources 提供有关工作节点上最初可用资源的信息。它提供的信息比 kubelet 导出到 APIServer 的信息更多。

// AllocatableResourcesResponses contains information about all the devices known by the kubelet
message AllocatableResourcesResponse {
    repeated ContainerDevices devices = 1;
    repeated int64 cpu_ids = 2;
    repeated ContainerMemory memory = 3;
}

ContainerDevices 确实公开了拓扑信息，声明设备与哪些 NUMA 单元关联。NUMA 单元使用不透明的整数 ID 进行标识，其值与设备插件 在向 kubelet 注册时 报告的值一致。

gRPC 服务通过位于 /var/lib/kubelet/pod-resources/kubelet.sock 的 Unix 套接字提供。设备插件资源的监控代理可以作为守护进程或 DaemonSet 部署。规范目录 /var/lib/kubelet/pod-resources 需要特权访问权限，因此监控代理必须在特权安全上下文中运行。如果设备监控代理作为 DaemonSet 运行，则必须将 /var/lib/kubelet/pod-resources 作为 卷 挂载到设备监控代理的 PodSpec 中。

Get gRPC 端点

Get 端点提供有关正在运行的 Pod 的资源信息。它公开的信息类似于 List 端点中描述的信息。Get 端点需要正在运行的 Pod 的 PodName 和 PodNamespace。

// GetPodResourcesRequest contains information about the pod
message GetPodResourcesRequest {
    string pod_name = 1;
    string pod_namespace = 2;
}

要启用此功能，必须使用以下标志启动 kubelet 服务：

--feature-gates=KubeletPodResourcesGet=true

Get 端点可以提供与动态资源分配 API 分配的动态资源相关的 Pod 信息。要启用此功能，必须确保使用以下标志启动 kubelet 服务：

--feature-gates=KubeletPodResourcesGet=true,DynamicResourceAllocation=true,KubeletPodResourcesDynamicResources=true

设备插件与拓扑管理器的集成

拓扑管理器是一个 Kubelet 组件，允许以与拓扑对齐的方式协调资源。为此，设备插件 API 扩展了一个 TopologyInfo 结构体。

message TopologyInfo {
    repeated NUMANode nodes = 1;
}

message NUMANode {
    int64 ID = 1;
}

希望利用拓扑管理器的设备插件可以在设备注册过程中发送一个填充的 TopologyInfo 结构体，以及设备 ID 和设备的健康状况。然后，设备管理器将使用此信息咨询拓扑管理器并做出资源分配决策。

TopologyInfo 支持将 nodes 字段设置为 nil 或 NUMA 节点列表。这允许设备插件通告跨越多个 NUMA 节点的设备。

将 TopologyInfo 设置为 nil 或为给定设备提供空的 NUMA 节点列表表示设备插件对该设备没有 NUMA 亲和性偏好。

设备插件为设备填充的示例 TopologyInfo 结构体：

pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{&pluginapi.NUMANode{ID: 0,},}}}

设备插件示例

以下是一些设备插件实现的示例：

• Akri，它可以轻松地公开异构叶子设备（例如 IP 摄像头和 USB 设备）。
• AMD GPU 设备插件
• 用于通用 Linux 设备和 USB 设备的 通用设备插件
• 用于 Intel GPU、FPGA、QAT、VPU、SGX、DSA、DLB 和 IAA 设备的 Intel 设备插件
• 用于硬件辅助虚拟化的 KubeVirt 设备插件
• 用于容器优化操作系统的 NVIDIA GPU 设备插件
• RDMA 设备插件
• SocketCAN 设备插件
• Solarflare 设备插件
• SR-IOV 网络设备插件
• 用于 Xilinx FPGA 设备的 Xilinx FPGA 设备插件

下一步

• 了解如何使用设备插件 调度 GPU 资源
• 了解如何在节点上 通告扩展资源
• 了解 拓扑管理器
• 阅读有关使用 Kubernetes 为 TLS 入口提供硬件加速 的信息