Openshift 4.19: Cgroups v1 removal

Objective

As OpenShift 4.19 removes support for cgroup v1 on new installations, validating workload compatibility becomes an important step during upgrade planning.

Chapter 1. OpenShift Container Platform 4.19 release notes

As the official documentation mentioned, the OpenShift 4.19 version is deprecated, and you would be blocked if you do not plan to change it.

A simple way to test container runtime behavior is to use Java’s built-in container-awareness diagnostics.

Modern OpenJDK versions support both cgroup v1 and v2 detection and expose this information directly through the JVM.

The following article can be a good one to start the discussion from the middleware side:

Java 17: What's new in OpenJDK's container awareness | Red Hat Developer

Test Environment

My environment is an OpenShift Cluster with 4.18, but we need to validate if the cgroup v1 is set :

oc get  nodes.config/cluster -o yaml

...

spec:
  cgroupMode: v1

Cluster versions installed previously from 4.14 have this setup set.

Running the Test Container

Use the Red Hat OpenJDK 17 image:

apiVersion: v1
kind: Pod
metadata:
  name: cgroup-test
spec:
  containers:
  - name: java
    image: registry.access.redhat.com/ubi9/openjdk-17
    command:
      - java
    args:
      - -XshowSettings:system
      - -version
    resources:
      limits:
        cpu: "1"
        memory: 512Mi

output on cgroupv1

Operating System Metrics:
Provider: cgroupv1
Effective CPU Count: 1
Memory Limit: 512.00M

$ oc logs cgroup-test -n default 

Openshift cgroupvs setup and validation

The biggest change from v1 to v2 is how the files are managed.

As we can see above, the cgroups v2 is more modular.

Validating Directly on Node

You can also confirm the host cgroup version:

oc debug node/<node>
chroot /host
stat -fc %T /sys/fs/cgroup

Expected outputs:

cgroup v1

tmpfs

cgroup v2

cgroup2fs

Changing from cgroups v1 to v2

After all applications are adapted to recognize the cgroups v2, now we are fine to set up the cgroups v2:

$ oc edit nodes.config/cluster 

...

spec:
  cgroupMode: v2

Verify the machine config pools

oc get mcp 

Monitoring the OpenShift cluster operators

oc get co 

After all cluster rollout, I ran my JAVA Pod, then I can see the new version running on the POD

Rollback

If a rollback is necessary for any reason, you just change it to v1 again :

$ oc edit nodes.config/cluster 

...

spec:
  cgroupMode: v1

Then the cluster rollout will start again.

Conclusion

You will be able to update to OpenShift 4.19 after all adjustments in the required application images and change the cgroup v2.