Enhancing Container Image Compatibility in Cloud-Native

In mission-critical sectors such as telecommunications, high-performance computing and AI, achieving consistent runtime behavior across large distributed clusters demands that containerized workloads run on hosts with precise operating system configurations and hardware capabilities. While the Open Container Initiative (OCI) provides a foundation for standardizing image formats and runtimes, it does not yet define a structured mechanism to express detailed host compatibility requirements. To fill this gap, the Kubernetes Node Feature Discovery (NFD) project has incorporated an image compatibility specification that lets image authors declare kernel versions, modules, device drivers and other system features required by their applications.

Background and Motivation

Container images typically rely on a minimal Linux userland (distroless or scratch), but many enterprise workloads need direct interaction with host resources:

• GPU and accelerator drivers: NVIDIA, AMD or Intel driver versions on the host must align with the CUDA, ROCm or oneAPI runtime libraries bundled in the container.
• Network fabrics: Low-latency interconnects such as InfiniBand (EFA), RoCE or Mellanox require specific kernel modules and firmware versions for MPI and RDMA-enabled workloads.
• Kernel features: Support for VFIO, write-protected huge page faults or advanced seccomp filters can be prerequisites for performance-sensitive or secure sandboxing scenarios.

Without a machine-readable compatibility manifest, operators must manually tag nodes and schedule pods using complex nodeSelector or nodeAffinity rules. This approach is error prone and does not scale across multi-cloud or hybrid-cloud footprints.

Node Feature Discovery Overview

NFD is a Kubernetes SIG-driven project that probes each node at startup, collecting details such as:

• CPU model, vendor ID, cache topology and flags
• Loaded kernel modules and parameters
• PCI device list, vendor and device IDs, class codes
• Custom user annotations (e.g. BIOS version, firmware level)

Collected features are exposed as NodeFeature labels or aggregated into NodeFeatureGroup Custom Resources, enabling logical grouping and weighted scheduling for workloads with strict host requirements.

Image Compatibility Specification

The OCI Image Compatibility WG defines a JSON/YAML schema that can be attached to OCI image manifests via the referrers API. A typical spec includes:

• version (string): API version, e.g. v1alpha1.
• compatibilities (array): Each entry has:

• description: Human-readable summary.
• rules: A NodeFeatureGroup selector that lists matchFeatures or matchExpressions.
• weight (optional): Scheduling affinity weight.
• tag (optional): Semantic grouping, e.g. gpu-compute.

Example snippet:

version: v1alpha1
compatibilities:
  - description: "Accelerated compute on NVIDIA A100 with VFIO"
    rules:
      - name: "gpu-and-iommu"
        matchFeatures:
          - feature: kernel.loadedmodule
            matchExpressions:
              vfio-pci: {op: Exists}
          - feature: pci.device
            matchExpressions:
              vendor: {op: In, value: ["0x10de"]}
              class:  {op: In, value: ["0x0300"]}

Integration with Container Runtimes

Beyond Kubernetes, compatibility metadata can be consumed by CRI-O, containerd and Singularity. The referrers API enables:

• oras v0.12 and higher to attach OCI artifacts of type application/vnd.nfd.image-compatibility.v1alpha1.
• containerd >=1.6 to resolve compatibility metadata via the ctr images plugin.
• Singularity 3.x to query OCI referrers and enforce host checks prior to singularity run.

“Standardized compatibility metadata will remove manual tagging and brittle scheduling logic, simplifying operations across hybrid-cloud fleets,” said Priya Kalra, maintainer of the OCI Image Compatibility WG.

Security Implications and Compliance

Specifying precise kernel modules and sysctl parameters not only improves performance but also tightens security boundaries. For example:

• Requiring a specific seccomp profile to be resident on the host ensures workloads are sandboxed uniformly.
• Enforcing minimum kernel versions can mitigate against known CVEs (e.g. Spectre/Meltdown patches).
• Auditing compatibility manifests alongside SBOMs (Software Bill of Materials) enhances compliance for regulated industries.

Client Validation Workflow

The nfd-client tool automates pre-deployment checks:

1. Fetch compatibility artifact via OCI referrers API.
2. Parse compatibilities rules and compare against node’s NFD labels or a standalone JSON inventory.
3. Output a pass/fail report in JSON, indicating missing features.

# Attach artifact to image (oras)
oras attach \
  --artifact-type application/vnd.nfd.image-compatibility.v1alpha1 \
  registry.example.com/myapp:latest \
  compat-spec.yaml:application/vnd.nfd.image-compatibility.spec.v1alpha1+yaml

# Validate host compatibility
nfd compat validate-node --image registry.example.com/myapp:latest

Future Directions and Standards Evolution

Working group discussions for a v1beta1 spec include:

• Version constraints (>=5.15 <5.20) for kernel and module parameters.
• Conditional expressions (if gpu.vendor=="NVIDIA" then require cuda>=11).
• Automatic host remediation via Kubernetes DaemonSets to install drivers or enable modules.

Upcoming Kubernetes 1.27 will offer native scheduler plugins to consume compatibility metadata directly, removing the need for custom predicates.

Conclusion

By embedding compatibility metadata into OCI images and leveraging Kubernetes NFD, organizations can declaratively match workloads to the exact host environments they require. This reduces manual operations, accelerates deployment of specialized workloads and strengthens security and compliance. As the OCI spec matures and runtime integrations deepen, cloud-native ecosystems will gain a unified, automated model for hardware and OS compatibility that scales across on-prem and public cloud clusters.

Get Involved

Contribute to the Kubernetes Node Feature Discovery project or the OCI Image Compatibility Working Group on GitHub. Your feedback and code contributions will help shape the next generation of container scheduling and runtime security.