Driver containers are the first layer of the software stack used to enable kernel modules on Kubernetes.
OpenShift and Kubernetes clusters are designed not to allow (easy) access to the underlying operating system and only allow commands to be run via containers. Therefore to use a kernel module on OpenShift or Kubernetes it needs to be containerised. When the container is run as a pod it then needs to run the command to load the kernel module (either insmod or modprobe). These images are commonly known as Driver Containers.
Building a kernel module inside a Dockerfile is made more complicated by the large number of additional packages that are required for the build process (e.g. a C compiler), and the libraries that are needed that are tied to the exact kernel version the kmod will run on. Getting these right can be an annoying process of trial and error, and leaving them in a driver-container that is deployed in production both bloats the container image (often by hundreds of MB), and leaves an additional attack surface for no value. This process can be fiddly and repetitive.
The Driver Toolkit removes this complexity and provides a simple framework for creating standardised Driver Containers
The Driver Toolkit (DTK from now on) is a container image in the OpenShift payload which is meant to be used as a base image on which to build driver containers. The DTK image contains the kernel packages commonly required as dependencies to build or install kernel modules as well as a few tools needed in driver containers. The version of these packages will match the kernel version running on the RHCOS nodes in the corresponding OpenShift release.
The list of the packages installed in the DTK can be found in the Dockerfile.
An example of using DTK on an OpenShift cluster using OpenShift's BuildConfig resource type can be found at the DTK github repository. This is the recommended method for using it.