Wiki · Concept · Last reviewed June 25, 2026

Kubernetes Device Plugins

Kubernetes device plugins let specialized hardware become named, schedulable capacity for pods.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, device plugins, GPUs, extended resources, AI infrastructure

Definition

Kubernetes device plugins are the extension point for making vendor-specific hardware available to pods without changing Kubernetes core code. The Kubernetes documentation describes the feature as stable since Kubernetes v1.26 and frames it around resources that need vendor-specific setup, including GPUs, high-performance NICs, FPGAs, InfiniBand adapters, and non-volatile main memory.

The key idea is that hardware becomes a named extended resource. A plugin running on a node tells the kubelet what devices exist, what resource name they should use, and whether they are healthy. The kubelet then advertises that capacity through node status so the scheduler can place pods that request it.

How It Works

A device plugin registers with the kubelet through a gRPC registration service. During registration, the plugin provides its Unix socket, the device-plugin API version, and a resource name that follows the extended-resource naming pattern, such as a vendor domain plus a resource type. Kubernetes documentation uses examples like hardware-vendor.example/foo; GPU documentation describes custom resources such as amd.com/gpu or nvidia.com/gpu.

After registration, the plugin runs a service under the kubelet device-plugin path, reports device lists and health changes, and handles allocation calls when a container is being created. Allocation is where device-specific runtime details can be passed back to the kubelet and container runtime. The plugin can be deployed manually, as an operating-system package, or commonly as a DaemonSet on the nodes that contain the hardware. Because the kubelet device-plugin directory is a host path requiring privileged access, the plugin pod is itself a privileged infrastructure component.

Pods consume these resources through container resource specifications. Extended resources are integer quantities and cannot be overcommitted. Kubernetes also states that devices exposed through this path cannot be shared between containers in the basic device-plugin model. For GPUs, Kubernetes documentation says the resource should be specified in limits; if both request and limit are present, their values must be equal.

Agent Context

In AI infrastructure, device plugins often sit between model code and scarce accelerator capacity. A serving deployment might request one GPU, a batch embedding job might request several devices, and an evaluation worker might need a particular accelerator pool. The plugin does not run the model; it makes the node's hardware visible enough for Kubernetes to account for placement.

This makes the device plugin part of the agent operating environment. If an agent platform launches workers, fine-tuning jobs, retrieval services, or simulation tasks, the resource name in the pod spec can decide whether the workload receives an accelerator, waits pending, or lands on a different class of node. Device plugins therefore interact with node affinity, taints and tolerations, ResourceQuota, and PriorityClass.

Governance Use

A governance-grade record should capture the plugin name, image or package version, deployment method, resource names, node pools, driver prerequisites, host mounts, privileged security context, RBAC, upgrade plan, and health-monitoring path. It should also record which team is authorized to deploy or update the plugin, because a device plugin can change how scarce compute is exposed to the cluster.

The review question is not only "does the pod get a GPU?" It is "who is allowed to define the resource, how is health reported, what happens during kubelet or plugin restarts, and how are pending pods investigated when capacity is exhausted?" For AI systems, those records affect cost controls, tenant fairness, evaluation reproducibility, incident review, and claims about which hardware produced which output.

Limits

Device plugins are not a security boundary by themselves. They do not authenticate users, isolate tenants, police network traffic, protect secrets, validate prompts, inspect generated output, or prove that a model workload is appropriate for the node. They expose hardware resources for scheduling and allocation.

They should be paired with pod security controls, runtime isolation, admission policy, workload identity, network policy, quotas, node-label governance, and observability. A privileged plugin also widens the trusted computing base of the cluster, so its image provenance, update channel, and host access deserve the same scrutiny as other node-level control components.

Source Discipline

Claims about the framework should cite Kubernetes' device-plugin documentation, GPU scheduling task page, and resource-management documentation on extended resources. Claims about a particular vendor plugin should cite the vendor implementation and should not be inferred from Kubernetes' generic framework.

The evidence that matters is operational: allocatable node resources, pod specs, scheduling events, kubelet logs, plugin health reports, container runtime configuration, and the actual hardware observed inside the workload.

Spiralist Reading

Spiralism reads device plugins as a place where hardware scarcity becomes language.

The cluster does not schedule "power" in the abstract. It schedules names, limits, health states, and permissions. A device plugin turns an accelerator into a resource word that institutions can request, ration, audit, and fight over.

Sources

Return to Wiki