이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 9. Using the Generic Device Plugin


Important

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

Important

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.yaml file in the /etc/microshift directory.
  • You installed the OpenShift CLI (oc).
  • You have sudo privileges 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

  1. From your CLI using sudo privileges, open /etc/microshift/config.yaml in a text editor.
  2. Locate the genericDevicePlugin section. If it is not present, add it.
  3. Set the status parameter to Enabled and define the devices that should be exposed. Each device definition needs a name and one or more groups. Each group can specify devices using paths, for file-based devices, including glob patterns, or usbs, for USB devices using Vendor/Product IDs. You cannot mix paths and usbs within the same device group.

    GDP fields with default values

    apiServer:
    # ...
    genericDevicePlugin:
      devices:
      - groups:
        - paths:
          - path: /dev/ttyUSB* 
    1
    
          - path: /dev/ttyACM* 
    2
    
        name: serial
      - groups:
        - paths:
          - path: /dev/fuse 
    3
    
        name: fuse 
    4
    
      - groups:
        - usbs: 
    5
    
          - product: "0x7523" 
    6
    
            serial: ""
            vendor: "0x1a86" 
    7
    
        name: converter
      domain: device.microshift.io 
    8
    
      status: Enabled
    Copy to Clipboard Toggle word wrap

    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-config parameter might include pre-configured default paths for serial devices even if you have not explicitly configured them in config.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 count parameter 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, count defaults to 1.
  4. Save the config.yaml file.
  5. Restart the MicroShift service to apply the changes:

    $ sudo systemctl restart microshift
    Copy to Clipboard Toggle word wrap

    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" 
    1
    Copy to Clipboard Toggle word wrap
    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

    Capacity:
     cpu:                                2
     device.microshift.io/audio:         0
     device.microshift.io/capture:       0
     device.microshift.io/custom-device: 1
     device.microshift.io/dummy-video:   0
     device.microshift.io/fuse:          0
     device.microshift.io/serial:        5
     device.microshift.io/video:         0
    Allocatable:
     cpu:                                2
     device.microshift.io/audio:         0
     device.microshift.io/capture:       0
     device.microshift.io/custom-device: 1
     device.microshift.io/dummy-video:   0
     device.microshift.io/fuse:          0
     device.microshift.io/serial:        5
     device.microshift.io/video:         0
    Allocated resources:
     (Total limits may be over 100 percent, i.e., overcommitted.)
     Resource                           Requests     Limits
     --------                           --------     ------
     cpu                                450m (22%)   500m (25%)
     memory                             1550Mi (42%) 500Mi (13%)
     ephemeral-storage                  0 (0%)       0 (0%)
     hugepages-1Gi                      0 (0%)       0 (0%)
     hugepages-2Mi                      0 (0%)       0 (0%)
     device.microshift.io/audio         0            0
     device.microshift.io/capture       0            0
     device.microshift.io/custom-device 1            1
     device.microshift.io/dummy-video   1            1
     device.microshift.io/fuse          0            0
     device.microshift.io/serial        0            0
     device.microshift.io/video         0            0
    Copy to Clipboard Toggle word wrap

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

  1. Define the device request in your Pod specification:

    apiVersion: v1
    kind: Pod
    metadata:
      name: device-app
    spec:
      containers:
      - name: container
        image: <your_application_image> 
    1
    
        command: ["/path/to/your/app"] 
    2
    
        args: ["--device_path=/dev/video0"] 
    3
    
        resources:
          limits: 
    4
    
            device.microshift.io/video: 1 
    5
    
        securityContext: 
    6
    
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
          runAsNonRoot: true
          seccompProfile:
            type: "RuntimeDefault"
    Copy to Clipboard Toggle word wrap
    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 the name that you specified in your configuration file.
    5
    A request for one instance of the video device.
    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.
  2. Deploy the Kubernetes workload by applying the manifest to the MicroShift node by running the following command:

    $ oc apply -f <your-workload-manifest.yaml> 
    1
    Copy to Clipboard Toggle word wrap
    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 
    1
    Copy to Clipboard Toggle word wrap
    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.

Expand
Table 9.1. GDP configuration fields definitions table
ParameterDescription

genericDevicePlugin

The genericDevicePlugin section of the MicroShift configuration file defines the configurable parameters for the implementation of the MicroShift GenericDevicePlugin API. All of the following parameters in this table are subsections in the genericDevicePlugin section of the MicroShift configuration.

devices

Is a subgroup that lists the device definitions to be exposed by the plugin. Each Device entry contains a 'name' and a list of groups.

devices.groups

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.

devices.groups.count

Specifies how many times this group of devices can be mounted concurrently. If unspecified, Count defaults to 1. Setting a high count, for example, 1000 for /dev/fuse, is possible because are no inherent limits, but performance might be impacted depending on the host’s capabilities and the nature of the device.

devices.groups.paths

Lists the host device file paths. Paths can be glob patterns, for example, /dev/ttyUSB*, in which case each matched device is schedulable Count times. This field is exclusive with usbs; you cannot define both in the same device group.

devices.groups.paths.limit

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 1.

devices.groups.paths.mountPath

The file path at which the host device should be mounted within the container. When unspecified, mountPath defaults to path.

devices.groups.paths.path

The file path of a device on the host, for example, /dev/video0, /dev/ttyUSB*.

devices.groups.paths.permissions

The file-system permissions given to the mounted device. Applies only to mounts of type Device. Can be one or more of:

* r - allows the container to read from the specified device.

* w - allows the container to write to the specified device.

* m - allows the container to create device files that do not yet exist.

When unspecified, Permissions defaults to mrw.

devices.groups.paths.readOnly

Specifies whether the path should be mounted read-only. The values are true or false. Applies only to mounts of type Mount.

devices.groups.path.type

Describes what type of file-system node this path represents and thus how it should be mounted. The type can be Device or Mount. When unspecified, type defaults to Device.

devices.groups.usbs

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 usbs field is exclusive with paths.

devices.groups.usbs.product

The USB Product ID of the device to match on, for example, 0x7523.

devices.groups.usbs.serial

The serial number of the device to match on. A USB device must match exactly on all the given attributes to pass.

devices.groups.usbs.vendor

The USB Vendor ID of the device to match on, for example, 0x1a86

devices.name

A unique string representing the kind of device this specification describes, for example, serial, video, or fuse. This name is used in pod resource requests, for example, device.microshift.io/serial.

domain

domain is a subgroup that specifies the domain prefix with which devices are advertised and present in the node. For example, device.microshift.io/serial. The default value is device.microshift.io.

status

status is a subgroup that specifies the default GDP status. Enabled or Disabled are valid values.

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.

9.5.2. Additional resources

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat