Red Hat Enterprise Linux Container Compatibility Matrix
Red Hat Enterprise Linux includes powerful container technology that enables new levels of workload isolation and portability. While containers have strong isolation between other containers, they directly depend on the underlying Linux host and kernel for critical interfaces. There are known limitations with mixing and matching versions of the operating system in the container image and the container host, and this article provides guidance and support limits.
| ⇓ Container Image / Container Host ⇒ | RHEL 7 Host | RHEL 8 Host* | RHEL 9 Host* |
|---|---|---|---|
| RHEL 6 Image | Supported | Supported | Unsupported |
| RHEL/UBI 7 Image | Supported | Supported | Supported |
| RHEL/UBI 8 Image | Supported | Supported | Supported |
| RHEL/UBI 9 Image | Unsupported | Supported | Supported |
* Please refer to the document, RHEL Versions Utilized by RHCOS and OpenShift Container Platform to map the version of RHEL CoreOS used by a given OpenShift release to the major RHEL versions listed here.
Red Hat works to enable compatibility between a range of major versions of RHEL (as described above), providing customers the operational flexibility to run a range of container images and hosts in production environments. These combinations extend many applications’ useful life cycles and ease upgrade concerns.
Red Hat Support may choose to differentiate between “fully compatible” and “workload specific” configurations (described below) for the purposes of providing support. Please discuss this with your support associate.
Guidelines for Container Compatibility
In specific use cases, Red Hat recommends aligning the major version of the RHEL-based container image and the RHEL container host. Red Hat also recommends following the Red Hat Container Support Policy because other container engines and runtimes are not supported.
In RHEL versions 8 and 9, Red Hat provides container images for each of the supported architectures (Intel/Amd x86, Arm AArch64, IBM POWER, and zSeries). In general, the correct hardware architecture will automatically be detected and the correct image will be used. Using mismatched hardware architectures (e.g. running an AArch64 container image on a x86 container host) is not recommended or supported, and likely will not work. The container image and host architectures must match for container images to run properly and be supported. The container host’s hardware must also meet the minimum hardware requirements for the container image in order to run the image correctly (e.g. RHEL 9 container images for IBM POWER LE require POWER9 hardware).
There are known limitations when running a newer container image on an older container host and while this configuration often works, such a configuration can introduce additional risk and compatibility problems. If customers run into these limitations, Red Hat recommends upgrading the container host.
When containers run with privilege (ex. podman run —privileged) and/or modify the underlying host, Red Hat recommends aligning the major version between container image and container host (ex. RHEL 9 image on a RHEL 9 host). This recommendation also applies when containers are granted security privileges to interact with other containers for the purposes of inspection or monitoring. Aligning the major versions of the image and host ensures the highest degree of compatibility and eliminates many of the edge-cases that users encounter when mixing different versions of container images (userspace) with container hosts (kernels).
Finally, customers may run into challenges when running extremely old images on newer container hosts (ex. RHEL 6 container image on RHEL 9 host). In these situations Red Hat recommends using a version supported in the table above (e.g. RHEL 7, RHEL 8, or RHEL 9 image on a RHEL 9 host.).
Detailed Support Conditions
The configurations defined below do not supersede the Red Hat Enterprise Linux 9: Application Compatibility Guide and support for Red Hat software provided within a container image is still governed by those guidelines. Refer to the guidelines below for more specific definitions for workloads.
Fully Compatible (Recommended)
A “Fully compatible” configuration is one where the major version of the container host matches the major version of the container base image, e.g. RHEL8 host running a container based on a UBI8 base image.
“Fully compatible” configurations are recommended for development and deployment of applications that need the most compatibility between the container image and the host.
“Fully Compatible” configurations mean the container image and the container host are fully supported and tested together. This configuration ensures that all low-level kernel subsystems use matching userspace and kernel driver components. Running privileged containers is supported but certain workloads may require that the minor version of the container host match the minor version of the container image.
Workload Specific
A “Workload specific” configuration is one where the major version of the container host does not match the major version of the container base image, e.g. RHEL8 host running a container based on a UBI7 base image.
- Users can expect to run older container images on newer container hosts in a supportable way if they meet all of the following conditions:
- The major version of Red Hat Enterprise Linux in the container image is still within the supported RHEL Life Cycle. For example, when RHEL 8 reaches the Extended Life Phase, proper ELS subscriptions are required to support RHEL 8 container images regardless of the underlying container host version used.
- The application is running as an unprivileged container. Running privileged containers, e.g. passing —privileged, reduces the isolation and exposes a tighter connection between container and host interfaces and is not supported in these configurations.
“Fully compatible” configurations are recommended for development and deployment of applications that need the most compatibility between the container image and the host.
- All previous “Workload Specific” support conditions apply
- The user can show support that the issue reproduces with a “Fully Compatible” configuration and has the same underlying cause
- The user is responsible for validating compatibility of the container image (application) and container host
- The user shows (via strace or systemtap traces) that the container image (application) requires only syscalls, and that all syscall features (includes flags, options, and paths) are present in the underlying container host kernel
** While many commonly deployed workloads will function when the host version is older than the container image version, they may still fail either at startup or later at runtime. Over time userspace components from newer container images will require newer kernel features to work properly and older kernels will not be able to meet these requirements. This combination has the most risk of running into software version misalignment and serious failures including, but not limited to, unscheduled downtime or data loss. Users must be prepared to migrate to “Fully Compatible” configuration. Testing of application compatibility is not done by Red Hat, and support is limited to commercially reasonable effort to assist with the analysis, but not to provide bug fixes to resolve incompatibility.