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 . Red Hat breaks the support into three tiers, Tier 1 being the highest compatibility, and Tier 3 being the lowest.

⇓ Container Image / Container Host ⇒ RHEL 7 Host RHEL 8 Host
RHEL 6 Userspace Tier 2: Workload Specific Tier 2: Workload Specific
RHEL 7 Userspace Tier 1: Fully Compatible Tier 2: Workload Specific
RHEL 8 Userspace Tier 3: Commercially Reasonable Support Tier 1: Fully Compatible

In general, Red Hat recommends tier 1, aligning the major versions of the RHEL based container image, commonly known as userspace, and the RHEL container host. 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 userspace with kernels. Tier 2 is for scenarios where it is either not possible or practical to align the versions of the container images and hosts, Red Hat recommends using the latest previous version as the container image, for example, a RHEL7 based container image on a RHEL8 host. Tier 3 describes running a newer container image on an older container host and while this configuration often works, there are known limitations. Running on a Tier 3 configuration can introduce additional risk and if possible, should be avoided. Please see the support conditions below.

  • Note: In addition to Tier 1, 2, and 3, software components that are granted the security privileges to interact with other containers for the purposes of inspection or monitoring and may have additional restrictions on container compatibility that are not documented here.

  • Note: The tiers described in this article cover the general support policy for RHEL. Other product offerings from Red Hat may operate outside of this matrix at their own discretion.

  • Support Conditions

    The tiers defined below do not supercede the RHEL Application Compatibility Guide and support for Red Hat software provided within a container image is still governed by those guidelines.

    Tier 1 - Fully Compatible

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

    Tier 2 - Workload Specific (Unprivileged)

    Tier 2 "Unprivileged" configurations mean that the combinations of container images and container hosts have support limitations. Any potential problems exposed will be handled per the Red Hat Enterprise Linux life cycle and support policy as described below. Users can expect to run older container images on newer container hosts in a supportable way if they meet all of the following conditions:

    1. The container image is still within the supported RHEL Life Cycle. For example when RHEL 6 reaches the Extended Life Phase, proper ELS subscriptions are required to support RHEL 6 container images regardless of the underlying container host version used. Also, if a RHEL6 bug is exposed when running on a RHEL7 host, the maintenance phase of RHEL6 will be a determining factor of whether or not the issue will be resolved.
    2. 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.
    3. The application or its dependencies does not interact directly with kernel-version-specific data structures (ioctl, /proc, /sys, routing, iptables, nftables, eBPF etc) or kernel-version-specific modules (KVM, OVS, SystemTap, etc.) Support for ioctls and access to /proc is limited to the most common use cases needed by unprivileged uses; all other uses require tier 1 compatibility.

    Tier 3 - Commercially Reasonable Support

    Tier 3 "Commercially Reasonable Support" configurations require the end user to test that it’s appropriate for their workload. While many commonly deployed workloads will function, 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 configuration 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 Tier 1 or Tier 2 if a solution to their issue is not possible. 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. Users can expect commercially reasonable support for running newer container images on older container hosts if they meet all of the following conditions:

    1. All Tier 2 support conditions apply.
    2. Red Hat Enterprise Linux life-cycle restrictions apply
    3. The user can show support that the Tier 3 issue reproduces with a Tier 1 configuration and has the same underlying cause.
    4. The user is responsible for validating compatibility of the container image (application) and container host.
    5. 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.