Device Plugins [page]deterministic

Kubernetes provides a device plugin framework that you can use to advertise system hardware resources to the [kubelet](#gloss:kubelet).

Instead of customizing the code for Kubernetes itself, vendors can implement a device plugin that you deploy either manually or as a [daemonset](#gloss:daemonset). The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adapters, and other similar computing resources that may require vendor specific initialization and setup.

## Device plugin registration

The kubelet exports a `Registration` gRPC service:

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

A device plugin can register itself with the kubelet through this gRPC service. During the registration, the device plugin needs to send:

* The name of its Unix socket. * The Device Plugin API version against which it was built. * The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the [extended resource naming scheme](/docs/concepts/configuration/manage-resources-containers/#extended-resources) as `vendor-domain/resourcetype`. (For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.)

Following a successful registration, the device plugin sends the kubelet the list of devices it manages, and the kubelet is then in charge of advertising those resources to the API server as part of the kubelet node status update. For example, after a device plugin registers `hardware-vendor.example/foo` with the kubelet and reports two healthy devices on a node, the node status is updated to advertise that the node has 2 "Foo" devices installed and available.

Then, users can request devices as part of a Pod specification (see [`container`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)). Requesting extended resources is similar to how you manage requests and limits for other resources, with the following differences: * Extended resources are only supported as integer resources and cannot be overcommitted. * Devices cannot be shared between containers.

### Example {#example-pod}

Suppose a Kubernetes cluster is running a device plugin that advertises resource `hardware-vendor.example/foo` on certain nodes. Here is an example of a pod requesting this resource to run a demo workload:

```yaml --- apiVersion: v1 kind: Pod metadata: name: demo-pod spec: containers: - name: demo-container-1 image: registry.k8s.io/pause:3.8 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. ```

## Device plugin implementation

The general workflow of a device plugin includes the following steps:

1. Initialization. During this phase, the device plugin performs vendor-specific initialization and setup to make sure the devices are in a ready state.

1. The plugin starts a gRPC service, with a Unix socket under the host path `/var/lib/kubelet/device-plugins/` (this path is hardcoded and is not affected by the kubelet's `--root-dir` or any other configuration), that implements the following interfaces:

```gRPC 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 contain …(trimmed)