|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: "Image Compatibility In Cloud Native Environments" |
| 4 | +date: 2025-06-25 |
| 5 | +draft: false |
| 6 | +slug: image-compatibility-in-cloud-native-environments |
| 7 | +author: > |
| 8 | + Chaoyi Huang (Huawei), |
| 9 | + Marcin Franczyk (Huawei), |
| 10 | + Vanessa Sochat (Lawrence Livermore National Laboratory) |
| 11 | +--- |
| 12 | + |
| 13 | +In industries where systems must run very reliably and meet strict performance criteria such as telecommunication, high-performance or AI computing, containerized applications often need specific operating system configuration or hardware presence. |
| 14 | +It is common practice to require the use of specific versions of the kernel, its configuration, device drivers, or system components. |
| 15 | +Despite the existence of the [Open Container Initiative (OCI)](https://opencontainers.org/), a governing community to define standards and specifications for container images, there has been a gap in expression of such compatibility requirements. |
| 16 | +The need to address this issue has led to different proposals and, ultimately, an implementation in Kubernetes' [Node Feature Discovery (NFD)](https://kubernetes-sigs.github.io/node-feature-discovery/stable/get-started/index.html). |
| 17 | + |
| 18 | +[NFD](https://kubernetes-sigs.github.io/node-feature-discovery/stable/get-started/index.html) is an open source Kubernetes project that automatically detects and reports [hardware and system features](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/usage/customization-guide.html#available-features) of cluster nodes. This information helps users to schedule workloads on nodes that meet specific system requirements, which is especially useful for applications with strict hardware or operating system dependencies. |
| 19 | + |
| 20 | +## The need for image compatibility specification |
| 21 | + |
| 22 | +### Dependencies between containers and host OS |
| 23 | + |
| 24 | +A container image is built on a base image, which provides a minimal runtime environment, often a stripped-down Linux userland, completely empty or distroless. When an application requires certain features from the host OS, compatibility issues arise. These dependencies can manifest in several ways: |
| 25 | + |
| 26 | +- **Drivers**: |
| 27 | + Host driver versions must match the supported range of a library version inside the container to avoid compatibility problems. Examples include GPUs and network drivers. |
| 28 | +- **Libraries or Software**: |
| 29 | + The container must come with a specific version or range of versions for a library or software to run optimally in the environment. Examples from high performance computing are MPI, EFA, or Infiniband. |
| 30 | +- **Kernel Modules or Features:**: |
| 31 | + Specific kernel features or modules must be present. Examples include having support of write protected huge page faults, or the presence of VFIO |
| 32 | +- And more… |
| 33 | + |
| 34 | +While containers in Kubernetes are the most likely unit of abstraction for these needs, the definition of compatibility can extend further to include other container technologies such as Singularity and other OCI artifacts such as binaries from a spack binary cache. |
| 35 | + |
| 36 | +### Multi-cloud and hybrid cloud challenges |
| 37 | + |
| 38 | +Containerized applications are deployed across various Kubernetes distributions and cloud providers, where different host operating systems introduce compatibility challenges. |
| 39 | +Often those have to be pre-configured before workload deployment or are immutable. |
| 40 | +For instance, different cloud providers will include different operating systems like: |
| 41 | + |
| 42 | +- **RHCOS/RHEL** |
| 43 | +- **Photon OS** |
| 44 | +- **Amazon Linux 2** |
| 45 | +- **Container-Optimized OS** |
| 46 | +- **Azure Linux OS** |
| 47 | +- And more... |
| 48 | + |
| 49 | +Each OS comes with unique kernel versions, configurations, and drivers, making compatibility a non-trivial issue for applications requiring specific features. |
| 50 | +It must be possible to quickly assess a container for its suitability to run on any specific environment. |
| 51 | + |
| 52 | +### Image compatibility initiative |
| 53 | + |
| 54 | +An effort was made within the [Open Containers Initiative Image Compatibility](https://github.com/opencontainers/wg-image-compatibility) working group to introduce a standard for image compatibility metadata. |
| 55 | +A specification for compatibility would allow container authors to declare required host OS features, making compatibility requirements discoverable and programmable. |
| 56 | +The specification implemented in Kubernetes Node Feature Discovery is one of the discussed proposals. |
| 57 | +It aims to: |
| 58 | + |
| 59 | +- **Define a structured way to express compatibility in OCI image manifests.** |
| 60 | +- **Support a compatibility specification alongside container images in image registries.** |
| 61 | +- **Allow automated validation of compatibility before scheduling containers.** |
| 62 | + |
| 63 | +The concept has since been implemented in the Kubernetes Node Feature Discovery project. |
| 64 | + |
| 65 | +### Implementation in Node Feature Discovery |
| 66 | + |
| 67 | +The solution integrates compatibility metadata into Kubernetes via NFD features and the [NodeFeatureGroup](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/usage/custom-resources.html#nodefeaturegroup) API. |
| 68 | +This interface enables the user to match containers to nodes based on exposing features of hardware and software, allowing for intelligent scheduling and workload optimization. |
| 69 | + |
| 70 | +### Compatibility specification |
| 71 | + |
| 72 | +The compatibility specification is a structured list of compatibility objects containing *[Node Feature Groups](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/usage/custom-resources.html#nodefeaturegroup)*. |
| 73 | +These objects define image requirements and facilitate validation against host nodes. |
| 74 | +The feature requirements are described by using [the list of available features](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/usage/customization-guide.html#available-features) from the NFD project. |
| 75 | +The schema has the following structure: |
| 76 | + |
| 77 | +- **version** (string) - Specifies the API version. |
| 78 | +- **compatibilities** (array of objects) - List of compatibility sets. |
| 79 | + - **rules** (object) - Specifies [NodeFeatureGroup](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/usage/custom-resources.html#nodefeaturegroup) to define image requirements. |
| 80 | + - **weight** (int, optional) - Node affinity weight. |
| 81 | + - **tag** (string, optional) - Categorization tag. |
| 82 | + - **description** (string, optional) - Short description. |
| 83 | + |
| 84 | +An example might look like the following: |
| 85 | + |
| 86 | +```yaml |
| 87 | +version: v1alpha1 |
| 88 | +compatibilities: |
| 89 | +- description: "My image requirements" |
| 90 | + rules: |
| 91 | + - name: "kernel and cpu" |
| 92 | + matchFeatures: |
| 93 | + - feature: kernel.loadedmodule |
| 94 | + matchExpressions: |
| 95 | + vfio-pci: {op: Exists} |
| 96 | + - feature: cpu.model |
| 97 | + matchExpressions: |
| 98 | + vendor_id: {op: In, value: ["Intel", "AMD"]} |
| 99 | + - name: "one of available nics" |
| 100 | + matchAny: |
| 101 | + - matchFeatures: |
| 102 | + - feature: pci.device |
| 103 | + matchExpressions: |
| 104 | + vendor: {op: In, value: ["0eee"]} |
| 105 | + class: {op: In, value: ["0200"]} |
| 106 | + - matchFeatures: |
| 107 | + - feature: pci.device |
| 108 | + matchExpressions: |
| 109 | + vendor: {op: In, value: ["0fff"]} |
| 110 | + class: {op: In, value: ["0200"]} |
| 111 | +``` |
| 112 | +
|
| 113 | +### Client implementation for node validation |
| 114 | +
|
| 115 | +To streamline compatibility validation, we implemented a [client tool](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/reference/node-feature-client-reference.html) that allows for node validation based on an image's compatibility artifact. |
| 116 | +In this workflow, the image author would generate a compatibility artifact that points to the image it describes in a registry via the referrers API. |
| 117 | +When a need arises to assess the fit of an image to a host, the tool can discover the artifact and verify compatibility of an image to a node before deployment. |
| 118 | +The client can validate nodes both inside and outside a Kubernetes cluster, extending the utility of the tool beyond the single Kubernetes use case. |
| 119 | +In the future, image compatibility could play a crucial role in creating specific workload profiles based on image compatibility requirements, aiding in more efficient scheduling. |
| 120 | +Additionally, it could potentially enable automatic node configuration to some extent, further optimizing resource allocation and ensuring seamless deployment of specialized workloads. |
| 121 | +
|
| 122 | +### Examples of usage |
| 123 | +
|
| 124 | +1. **Define image compatibility metadata** |
| 125 | +A [container image](/docs/concepts/containers/images) can have metadata that describes its requirements based on features discovered from nodes, like kernel modules or CPU models. |
| 126 | +The previous compatibility specification example in this article exemplified this use case. |
| 127 | +
|
| 128 | +2. **Attach the artifact to the image** |
| 129 | +The image compatibility specification is stored as an OCI artifact. |
| 130 | +You can attach this metadata to your container image using the [oras](https://oras.land/) tool. |
| 131 | +The registry only needs to support OCI artifacts, support for arbitrary types is not required. |
| 132 | +Keep in mind that the container image and the artifact must be stored in the same registry. |
| 133 | +Use the following command to attach the artifact to the image: |
| 134 | +
|
| 135 | +```bash |
| 136 | +oras attach \ |
| 137 | +--artifact-type application/vnd.nfd.image-compatibility.v1alpha1 <image-url> \ |
| 138 | +<path-to-spec>.yaml:application/vnd.nfd.image-compatibility.spec.v1alpha1+yaml |
| 139 | +``` |
| 140 | + |
| 141 | +3. **Validate image compatibility** |
| 142 | +After attaching the compatibility specification, you can validate whether a node meets the image's requirements. |
| 143 | +This validation can be done using the [nfd client](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/reference/node-feature-client-reference.html): |
| 144 | + |
| 145 | +`nfd compat validate-node --image <image-url>` |
| 146 | + |
| 147 | +4. **Read the output from the client** |
| 148 | +Finally you can read the report generated by the tool or use your own tools to act based on the generated JSON report. |
| 149 | + |
| 150 | + |
| 151 | + |
| 152 | +## Conclusion |
| 153 | + |
| 154 | +The addition of image compatibility to Kubernetes through Node Feature Discovery underscores the growing importance of addressing compatibility in cloud native environments. |
| 155 | +It is only a start, as further work is needed to integrate compatibility into scheduling of workloads within and outside of Kubernetes. |
| 156 | +However, by integrating this feature into Kubernetes, mission-critical workloads can now define and validate host OS requirements more efficiently. |
| 157 | +Moving forward, the adoption of compatibility metadata within Kubernetes ecosystems will significantly enhance the reliability and performance of specialized containerized applications, ensuring they meet the stringent requirements of industries like telecommunications, high-performance computing or any environment that requires special hardware or host OS configuration. |
| 158 | + |
| 159 | +## Get involved |
| 160 | + |
| 161 | +Join the [Kubernetes Node Feature Discovery](https://kubernetes-sigs.github.io/node-feature-discovery/v0.17/contributing/) project if you're interested in getting involved with the design and development of Image Compatibility API and tools. |
| 162 | +We always welcome new contributors. |
0 commit comments