Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 4. Known issues
This section describes known issues in OpenShift sandboxed containers 1.6.
4.1. Security
Sandboxed containers do not support SELinux multi-category security labels
When you set SELinux Multi-Category Security (MCS) labels in the security context of a container, the pod does not start. The following error is displayed in the pod log:
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.
Jira:KATA-1875
4.2. Performance and scaling
Increasing container CPU resource limits fails if CPUs are offline
Using container CPU resource limits to increase the number of available CPUs for a pod fails if the requested CPUs are offline. If the functionality is available, you can diagnose CPU resource issues by running the oc rsh <pod> command to access a pod and then running the lscpu command:
$ lscpu
Example output:
CPU(s): 16 On-line CPU(s) list: 0-12,14,15 Off-line CPU(s) list: 13
The list of offline CPUs is unpredictable and can change from run to run.
Workaround: Use a pod annotation to request additional CPUs, as in the following example:
metadata:
annotations:
io.katacontainers.config.hypervisor.default_vcpus: "16"Increasing the sizeLimit does not expand an ephemeral volume
You cannot use the sizeLimit parameter in the pod specification to expand ephemeral volumes because the volume size default is 50% of the memory assigned to the sandboxed container.
Workaround: Change the size by remounting the volume. For example, if the memory assigned to the sandboxed container is 6 GB and the ephemeral volume is mounted at /var/lib/containers, you can increase the size of this volume beyond the 3 GB default by running the following command:
$ mount -o remount,size=4G /var/lib/containers
Peer pod fails when its resource request annotations do not match system resources
The values of the io.katacontainers.config.hypervisor.default_vcpus and io.katacontainers.config.hypervisor.default_memory annotations follow the semantics for QEMU, which has the following limitations for peer pods:
If you set
io.katacontainers.config.hypervisor.default_memoryto less than256, the following error is displayed:Failed to create pod sandbox: rpc error: code = Unknown desc = CreateContainer failed: Memory specified in annotation io.katacontainers.config.hypervisor.default_memory is less than minimum required 256, please specify a larger value: unknown
-
If you set
io.katacontainers.config.hypervisor.default_memoryto256andio.katacontainers.config.hypervisor.default_vcpusto1, the smallest instance type or instance size is launched from the list. -
If you set
io.katacontainers.config.hypervisor.default_vcpusto0, all annotations are ignored and the default instance is launched.
Workaround: Set io.katacontainers.config.hypervisor.machine_type to the default AWS instance type or Azure instance size specified in the config map to enable flexible pod VM sizes.
Jira:KATA-2575, Jira:KATA-2577, Jira:KATA-2578
