이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 9. Using the Generic Device Plugin
The Generic Device Plugin for MicroShift is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
The Generic Device Plugin (GDP) for MicroShift enables your containerized applications to securely access physical host devices, such as serial ports, video cameras, or sound cards directly from within Kubernetes pods. By using GDP, you can extend capabilities of MicroShift to support applications that require direct hardware interaction, such as Internet of Things (IoT) applications.
9.1. Understanding the Generic Device Plugin 링크 복사링크가 클립보드에 복사되었습니다!
The Generic Device Plugin (GDP) is a Kubernetes device plugin that enables applications running in pods to access host devices such as serial ports, cameras, and sound cards securely. This capability is especially important for edge and IoT environments where direct hardware interaction is a common requirement. The GDP integrates with the kubelet to advertise available devices to the node and facilitate their allocation to pods without requiring elevated privileges within the container itself.
The GDP is designed to handle devices that are initialized and managed by the operating system and do not require any special initialization procedures or drivers for a pod to use them.
Here are examples of generic devices that are suitable for the GDP:
-
Serial ports, for example,
/dev/ttyUSB*,/dev/ttyACM*. -
Video cameras, for example,
/dev/video0. -
Sound devices, for example,
/dev/snd,/dev/snd/controlC0. - USB devices specified by Vendor ID and Product ID, or, optionally, by the device serial number.
The following specialized devices are not suitable for the GDP:
- Devices that require specific initialization procedures beyond standard operating system management.
- Specialized hardware that needs additional drivers or kernel modules. Examples of this specialized hardware include GPUs and FPGAs. These types of devices typically require their own specialized device plugins.
9.2. Limitations and considerations for the Generic Device Plugin 링크 복사링크가 클립보드에 복사되었습니다!
Although the Generic Device Plugin (GDP) provides powerful capabilities for accessing host devices in MicroShift, it is important to understand its limitations and current status.
9.2.1. Devices not suited for the Generic Device Plugin 링크 복사링크가 클립보드에 복사되었습니다!
The GDP is designed for devices that are managed directly by the operating system and do not require special setup procedures. Devices that are not well-suited for the Generic Device Plugin include:
- Complex hardware requiring specialized drivers such as GPUs (graphics processing units) or FPGAs (field-programmable gate arrays). These types of hardware typically require dedicated device plugins that can perform unique initialization procedures, memory management, or queue resets before a pod can use them.
- Devices with specific vendor-supplied software stacks. Devices that require a complex software stack or proprietary APIs beyond direct file system access might require a specialized plugin.
9.2.2. Device identification and logging 링크 복사링크가 클립보드에 복사되었습니다!
When you use glob paths, for example, /dev/ttyUSB*, to expose multiple similar devices, the GDP allocates devices based on availability. However, if your application needs to connect to an exactly specified physical device, for example, serial device 3 out of 10, using broad glob paths might be insufficient. In such cases, configure individual device entries in the config.yaml file using more stable and unique identifiers such as:
-
Specific device paths, for example,
/dev/video0. -
Symbolic links provided by the operating system, for example,
/dev/serial/by-id/or/dev/serial/by-path/. - USB vendor ID, product ID, and serial number combinations for precise USB device targeting.
9.2.3. Performance considerations 링크 복사링크가 클립보드에 복사되었습니다!
The count parameter in the config.yaml file enables a device group to be scheduled multiple times concurrently. While there are no explicit limits set within the GDP for the count (for example, 1000 for /dev/fuse), the actual performance depends on the host system’s capabilities and the nature of the device itself. Running a very high number of concurrent processes that access the same device might affect performance.
9.3. Configuring the Generic Device Plugin 링크 복사링크가 클립보드에 복사되었습니다!
The Generic Device Plugin for MicroShift is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
The Generic Device Plugin (GDP) is disabled by default in MicroShift. To use the GDP, you must enable it and specify which host devices your Kubernetes applications can access. To enable the GDP, you must modify the MicroShift config.yaml file or create a configuration snippet file. For example, /etc/microshift/config.d/10-gdp.yaml.
Prerequisites
- You installed MicroShift.
-
You created a custom
config.yamlfile in the/etc/microshiftdirectory. -
You installed the OpenShift CLI (
oc). -
You have
sudoprivileges on the MicroShift host. -
You have identified the specific host devices that you want to expose to your MicroShift node. For example,
/dev/video0,/dev/ttyUSB*, or USB Vendor/Product IDs.
Procedure
-
From your CLI using
sudoprivileges, open/etc/microshift/config.yamlin a text editor. -
Locate the
genericDevicePluginsection. If it is not present, add it. Set the
statusparameter toEnabledand define thedevicesthat should be exposed. Each device definition needs anameand one or moregroups. Each group can specify devices usingpaths, for file-based devices, including glob patterns, orusbs, for USB devices using Vendor/Product IDs. You cannot mixpathsandusbswithin the same device group.GDP fields with default values
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Exposes all the USB serial devices that are matched by this glob.
- 2
- Exposes all the ACM serial devices that are matched by this glob.
- 3
- For example, the file path for a fuse device.
- 4
- For example, the name of the device.
- 5
- Exposes a specific USB device by Vendor ID and Product ID.
- 6
- For example, the Product ID for a CH340 serial converter
- 7
- For example, the Vendor ID for a CH340 serial converter.
- 8
- Default domain for the GDP.
Important-
The output of the
microshift show-configparameter might include pre-configured default paths for serial devices even if you have not explicitly configured them inconfig.yaml. These paths represent the default discovery settings if the Generic Device Plugin is enabled without specific user configuration. -
For consistency and precise device targeting, especially when dealing with multiple similar devices, consider using stable device paths like
/dev/serial/by-id/or specific USB Vendor, Product, or Serial IDs instead of broad glob patterns like/dev/ttyUSB*. -
The
countparameter in a device group allows a single device, or a set of devices matched by a glob, to be allocated multiple times concurrently to different pods. If omitted,countdefaults to1.
-
Save the
config.yamlfile. Restart the MicroShift service to apply the changes:
sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow Allow some time for MicroShift to restart and for the GDP to register its devices with the Kubelet.
Verification
You can check the available devices in your node by running the following command:
oc describe node <microshift_node_name> | grep "device.microshift.io"
$ oc describe node <microshift_node_name> | grep "device.microshift.io"1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Replace <microshift_node_name> with your node name.
Depending on your configuration, expect output that indicates that the devices are now discoverable and schedulable within your MicroShift node.
Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.4. Deploying applications that use generic devices 링크 복사링크가 클립보드에 복사되었습니다!
After the Generic Device Plugin (GDP) is configured and enabled in MicroShift, you can deploy Kubernetes workloads, such as pods, deployments, or StatefulSets, that request access to the host devices that you have exposed. Devices are made available inside the container without requiring the pod to run with elevated privileges.
Prerequisites
- You installed MicroShift.
- You enabled and configured GDP.
-
You installed OpenShift CLI (
oc).
Procedure
Define the device request in your
Podspecification:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Replace with your container image.
- 2
- Replace with the command for your application.
- 3
- For example, how your application might use the device.
- 4
- The resource name must follow the pattern
device.microshift.io/<device_name>, where<device_name>matches thenamethat you specified in your configuration file. - 5
- A request for one instance of the
videodevice. - 6
- Define and configure with the least privilege value to ensure that the container has only required permissions, such as access to the device file, and to restrict other capabilities for the container.
Deploy the Kubernetes workload by applying the manifest to the MicroShift node by running the following command:
oc apply -f <your-workload-manifest.yaml>
$ oc apply -f <your-workload-manifest.yaml>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Replace <your_workload_manifest> with the name of your workload manifest.
Results
After the pod is running, the specified host device is available at its original path, or mountPath if specified, inside the container. Your application can then interact with it as if it were a local device.
For example, if you requested device.microshift.io/serial, which maps to /dev/ttyUSB*, your application might find the device at /dev/ttyUSB0 or a similar path inside the container.
Verification
Verify device access by running the following command inside the running pod:
oc exec -it <pod_name> -- ls -l /dev/video0
$ oc exec -it <pod_name> -- ls -l /dev/video01 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Replace <pod_name> with the name of the pod.
9.5. Generic Device Plugin configuration reference 링크 복사링크가 클립보드에 복사되었습니다!
This section provides a detailed reference for the configuration parameters available for the Generic Device Plugin within the MicroShift config.yaml file.
| Parameter | Description |
|---|---|
|
|
The |
|
|
Is a subgroup that lists the device definitions to be exposed by the plugin. Each |
|
| Lists device groups. Devices within a group comprise a pool of devices under a common name. When you request a device from that pool, you can receive a device from different defined paths. |
|
|
Specifies how many times this group of devices can be mounted concurrently. If unspecified, |
|
|
Lists the host device file paths. Paths can be glob patterns, for example, |
|
|
Specifies up to how many times this device can be used in the group concurrently when other devices in the group yield more matches. For example, if one path in the group matches 5 devices and another matches 1 device but has a limit of 10, then the group provides 5 pairs of devices. When unspecified, the limit defaults to |
|
|
The file path at which the host device should be mounted within the container. When unspecified, |
|
|
The file path of a device on the host, for example, |
|
|
The file-system permissions given to the mounted device. Applies only to mounts of type
*
*
*
When unspecified, |
|
|
Specifies whether the path should be mounted read-only. The values are |
|
|
Describes what type of file-system node this |
|
|
Lists the USB specifications that this device group consists of. The vendor and product IDs must always match. The serial ID must match if provided, or skipped if the ID is empty, The |
|
|
The USB Product ID of the device to match on, for example, |
|
| The serial number of the device to match on. A USB device must match exactly on all the given attributes to pass. |
|
|
The USB Vendor ID of the device to match on, for example, |
|
|
A unique string representing the kind of device this specification describes, for example, |
|
|
|
|
|
|
9.5.1. Troubleshooting configuration issues 링크 복사링크가 클립보드에 복사되었습니다!
If you encounter errors such as "invalid configuration: failed to parse device" or "cannot define both path and usbs at the same time", it means you have incorrectly mixed paths and usbs fields within the same groups entry for a device. Each group must exclusively use either paths or usbs to define its devices.