Chapter 1. OpenShift sandboxed containers 1.4 release notes

Previously, upgrading OpenShift sandboxed containers did not automatically update the existing KataConfig CR. As a result, monitor pods from previous deployments were not restarted and continued to run with an outdated kataMonitor image.

Starting from release 1.3.2, the kataMonitorImage was removed from the KataConfig CR, and the upgrade for all monitor pods is handled internally by the Operator.

(KATA-1650)

Previously, users could not install OpenShift sandboxed containers on a disconnected cluster. The pull specification of the kata-monitor container image used a tag instead of a digest. This prevented the image from being mirrored with the ImageContentSourcePolicy resource.

With this release, the CSV spec.relatedImages section has been updated to ensure that all container images in the OpenShift sandboxed containers Operator are included. As a result, all container pull specifications now utilize digests instead of tags, enabling the installation of OpenShift sandboxed containers in disconnected environments.

(KATA-2038)

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

Following SELinux policy on the host guarantees full isolation of the host file system from the sandboxed workload by default. This also provides stronger protection against potential security flaws in the virtiofsd daemon or QEMU.

If the mounted files or directories do not have specific SELinux requirements on the host, you can use local persistent volumes as an alternative. Files are automatically relabeled to container_file_t, following the SELinux policy for container runtimes. See Persistent storage using local volumes.

Automatic relabeling is not an option when mounted files or directories are expected to have specific SELinux labels on the host. Instead, you can set custom SELinux rules on the host to allow the virtiofsd daemon to access these specific labels. (KATA-469)

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

lscpu

$ lscpu

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

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

The list of offline CPUs will likely change unpredictably from run to run.

As a workaround, you can use a pod annotation to request additional CPUs rather than setting a CPU limit. CPU requests that use pod annotation are not affected by this issue, because the processor allocation method is different. Rather than setting a CPU limit, the following annotation must be added to the metadata of the pod:

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

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

(KATA-1376)

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

In this case, the installation starts on the control plane nodes because the Operator assumes it is a converged cluster where nodes have both control plane and worker roles. The status section of the kataConfig CR is not updated during the installation. (KATA-1017)

When you set SELinux Multi-Category Security (MCS) labels in the security context of a container, the pod will not start and throw the following error:

Error: CreateContainer failed: EACCES: Permission denied: unknown

Error: CreateContainer failed: EACCES: Permission denied: unknown

The runtime does not have access to the security context of the containers when the sandboxed container is created. This means that virtiofsd does not run with the appropriate SELinux label and cannot access host files for the container. As a result, you cannot rely on MCS labels to isolate files in the sandboxed container on a per-container basis. This means that all containers can access all files within the sandboxed container. Currently, there is no workaround for this issue.

(KATA-1875)

When stopping a sandboxed container workload, the following QEMU error messages are logged to the worker node system journal:

qemu-kvm: Failed to write msg.
qemu-kvm: Failed to set msg fds.
qemu-kvm: vhost VQ 0 ring restore failed
qqemu-kvm: vhost_set_vring_call failed

qemu-kvm: Failed to write msg.
qemu-kvm: Failed to set msg fds.
qemu-kvm: vhost VQ 0 ring restore failed
qqemu-kvm: vhost_set_vring_call failed

These errors are harmless and can be ignored.

For more information on how to access the system journal logs, see Collecting OpenShift sandboxed containers data for Red Hat Support.

(KATA-2133)

When installing the OpenShift sandboxed containers Operator using the web console, the UI might display the incorrect operator version after clicking Install.

The incorrect version appears in gray text in the installation window and reads:

<Version number> provided by Red Hat.

The correct operator is installed. You can navigate to Operators Installed Operators to see the correct version listed beneath the OpenShift sandboxed containers Operator.

(KATA-2161)

When using peer pods with OpenShift sandboxed containers, the kata-remote-cc runtime class is created when you create the KataConfig CR and set the enablePeerPods field to true. As a result, users should see the kata-remote-cc runtime class in the KataConfig CR, in addition to the kata runtime class, and users should technically be able to run both standard Kata pods and peer-pod Kata pods on the same cluster.

As a cluster admin, when you examine the KataConfig CR, you will only find kata in the Status.runtimeClass field. The runtime class kata-remote-cc does not appear. Currently, there is no workaround for this issue.

(KATA-2164)

When using older versions of the Buildah tool in OpenShift sandboxed containers, the build fails with the following error:

process exited with error: fork/exec /bin/sh: no such file or directory

subprocess exited with status 1

process exited with error: fork/exec /bin/sh: no such file or directory

subprocess exited with status 1

You must use the latest version of Buildah, available at quay.io.

(KATA-1278)