OpenShift sandboxed containers 1.2 release notes

Previously, using loop devices in a sandboxed container was not possible due to missing kernel modules. With this release, these kernel modules are included in the package. (KATA-1334)

Previously, the MachineConfigPool (MCP) object created by the Operator to track nodes with the Kata runtime installed was not automatically removed on deletion of the KataConfig custom resource (CR). With this release, the deletion of the KataConfig CR results in the removal of the kata-oc MCP object. (KATA-1184)

Previously, when you created a kataConfigPoolSelector field and changed it, the OpenShift sandboxed containers Operator did not apply the change. With this release, the Operator acts on changes to the kataConfigPoolSelector field in the custom resource definition and adapts installations of the runtime on nodes accordingly. (KATA-1190)

Previously, the SourceImage field was displayed on the web console and using the field had no effect on the installation. With this release, the unused SourceImage field is no longer displayed when creating the KataConfig CR from the web console. (KATA-1015)

If you are using OpenShift sandboxed containers, you might receive SELinux denials when accessing files or directories mounted from the hostPath volume in an OpenShift Container Platform cluster. These denials can occur even when running privileged sandboxed containers because privileged sandboxed containers do not disable SELinux checks.

You might encounter an issue where the Machine Config Operator (MCO) pod changes to a CrashLoopBackOff state and the openshift.io/scc annotation of the pod displays sandboxed-containers-operator-scc instead of the default hostmount-anyuid value.

The OpenShift sandboxed containers Operator pods that use container CPU resource limits to increase the number of available CPUs for the pod might receive fewer CPUs than requested. If the functionality is available inside the container, you can diagnose CPU resources by using oc rsh <pod> and running the lscpu command.

$ lscpu

CPU(s):                          16
On-line CPU(s) list:             0-12,14,15
Off-line CPU(s) list:            13

metadata:
  annotations:
    io.katacontainers.config.hypervisor.default_vcpus: "16"

The progress of the runtime installation is shown in the status section of the kataConfig CR. However, the progress is not shown if all of the following conditions are true:

When creating the KataConfig CR and observing the pod status under the openshift-sandboxed-containers-operator namespace, a huge number of restarts for monitor pods is shown. The monitor pods use a specific SELinux policy that is installed as part of sandboxed-containers extension installation. The monitor pod gets created immediately, however the SELinux policy is not yet available, which results in a pod creation error, followed by a pod restart. When the extension installation succeeds, the SELinux policy is available and the monitor pod transitions to a Running state. This does not affect any of the OpenShift sandboxed containers Operator functionality. (KATA-1338)