이전에는 OpenShift 샌드박스 컨테이너를 업그레이드해도 기존 KataConfig CR을 자동으로 업데이트하지 않았습니다. 결과적으로 이전 배포의 모니터링 Pod가 재시작되지 않았으며 오래된 kataMonitor 이미지로 계속 실행됩니다.

릴리스 1.3.2부터 kataMonitorImage 가 KataConfig CR에서 제거되었으며 모든 모니터 Pod의 업그레이드는 Operator에 의해 내부적으로 처리됩니다.

(KATA-1650)

이전에는 사용자가 연결이 끊긴 클러스터에 OpenShift 샌드박스 컨테이너를 설치할 수 없었습니다. kata-monitor 컨테이너 이미지의 가져오기 사양은 다이제스트 대신 태그를 사용했습니다. 이로 인해 ImageContentSourcePolicy 리소스로 이미지가 미러링되지 않았습니다.

이번 릴리스에서는 OpenShift 샌드박스 컨테이너 Operator의 모든 컨테이너 이미지가 포함되도록 CSV spec.relatedImages 섹션이 업데이트되었습니다. 결과적으로 모든 컨테이너 가져오기 사양은 태그 대신 다이제스트를 사용하므로 연결이 끊긴 환경에서 OpenShift 샌드박스 컨테이너를 설치할 수 있습니다.

(KATA-2038)

OpenShift 샌드박스 컨테이너를 사용하는 경우 Red Hat OpenShift 클러스터의 hostPath 볼륨에서 마운트된 파일 또는 디렉터리에 액세스할 때 SELinux 거부가 표시될 수 있습니다. 권한 있는 샌드박스 컨테이너가 SELinux 검사를 비활성화하지 않기 때문에 권한 있는 샌드박스 컨테이너를 실행하는 경우에도 이러한 거부가 발생할 수 있습니다.

호스트의 SELinux 정책에 따라 기본적으로 샌드박스 워크로드에서 호스트 파일 시스템을 완전히 격리할 수 있습니다. 또한 virtiofsd 데몬 또는 QEMU의 잠재적인 보안 결함에 대해 더 강력한 보호 기능을 제공합니다.

마운트된 파일 또는 디렉터리에 호스트에 특정 SELinux 요구 사항이 없는 경우 로컬 영구 볼륨을 대안으로 사용할 수 있습니다. 컨테이너 런타임의 SELinux 정책에 따라 파일이 자동으로 container_file_t 로 레이블이 다시 지정됩니다. 로컬 볼륨을 사용한 영구 스토리지를 참조하십시오.

마운트된 파일 또는 디렉터리에 호스트의 특정 SELinux 레이블이 있을 것으로 예상되는 경우 자동 레이블은 옵션이 아닙니다. 대신 virtiofsd 데몬이 이러한 특정 라벨에 액세스할 수 있도록 호스트에서 사용자 지정 SELinux 규칙을 설정할 수 있습니다. (KATA-469)

일부 OpenShift 샌드박스 컨테이너 Operator Pod는 컨테이너 CPU 리소스 제한을 사용하여 Pod에 사용 가능한 CPU 수를 늘립니다. 이러한 Pod는 요청된 것보다 적은 CPU를 수신할 수 있습니다. 컨테이너 내에서 기능을 사용할 수 있는 경우 oc rsh <pod >를 사용하여 Pod에 액세스하고 lscpu 명령을 실행하여 CPU 리소스 문제를 진단할 수 있습니다.

$ lscpu

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

오프라인 CPU 목록은 실행에서 실행으로 예기치 않게 변경될 수 있습니다.

이 문제를 해결하려면 Pod 주석을 사용하여 CPU 제한을 설정하지 않고 추가 CPU를 요청할 수 있습니다. 프로세서 할당 방법이 다르기 때문에 Pod 주석을 사용하는 CPU 요청은 이 문제의 영향을 받지 않습니다. CPU 제한을 설정하지 않고 Pod의 메타데이터에 다음 주석을 추가해야 합니다.

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

(KATA-1376)

런타임 설치 진행률은 kataConfig CR(사용자 정의 리소스)의 status 섹션에 표시됩니다. 그러나 다음 조건이 모두 true인 경우 진행률이 표시되지 않습니다.

이 경우 Operator는 노드에 컨트롤 플레인 및 작업자 역할이 모두 있는 통합 클러스터라고 가정하기 때문에 컨트롤 플레인 노드에서 설치가 시작됩니다. kataConfig CR의 status 섹션은 설치 중에 업데이트되지 않습니다. (KATA-1017)

컨테이너의 보안 컨텍스트에서 SELinux MCS(Multi-Category Security) 레이블을 설정하면 Pod가 시작되지 않고 다음 오류가 발생합니다.

Error: CreateContainer failed: EACCES: Permission denied: unknown

샌드박스 컨테이너가 생성될 때 런타임은 컨테이너의 보안 컨텍스트에 액세스할 수 없습니다. 즉 virtiofsd 는 적절한 SELinux 레이블로 실행되지 않으며 컨테이너의 호스트 파일에 액세스할 수 없습니다. 결과적으로 MCS 레이블을 사용하여 컨테이너별로 샌드박스 컨테이너의 파일을 격리할 수 없습니다. 즉, 모든 컨테이너가 샌드박스 컨테이너 내의 모든 파일에 액세스할 수 있습니다. 현재 이 문제에 대한 해결방법이 없습니다.

(KATA-1875)

샌드박스된 컨테이너 워크로드를 중지하면 다음 QEMU 오류 메시지가 작업자 노드 시스템 저널에 기록됩니다.

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

이러한 오류는 무해하며 무시할 수 있습니다.

시스템 저널 로그에 액세스하는 방법에 대한 자세한 내용은 Red Hat 지원에 대한 OpenShift 샌드박스 컨테이너 데이터 수집을 참조하십시오.

(KATA-2133)

웹 콘솔을 사용하여 OpenShift 샌드박스 컨테이너 Operator를 설치할 때 설치를 클릭한 후 UI에 잘못된 Operator 버전이 표시될 수 있습니다.

설치 창의 회색 텍스트에 잘못된 버전이 표시되고 다음과 같이 표시됩니다.

Red Hat에서 제공하는 <version number >.

올바른 Operator가 설치되어 있어야 합니다. Operator → 설치된 Operator 로 이동하여 OpenShift 샌드박스 컨테이너 Operator 아래에 나열된 올바른 버전을 확인할 수 있습니다.

(KATA-2161)

OpenShift 샌드박스 컨테이너가 있는 피어 Pod를 사용하는 경우 KataConfig CR을 생성하고 enablePeerPods 필드를 true 로 설정할 때 kata-remote-cc 런타임 클래스가 생성됩니다. 결과적으로 사용자는 kata 런타임 클래스 외에도 KataConfig CR에서 kata-remote-cc 런타임 클래스를 확인해야 하며 사용자는 기술적으로 동일한 클러스터에서 표준 Kata Pod 및 peer-pod Kata Pod를 모두 실행할 수 있어야 합니다.

클러스터 관리자는 KataConfig CR을 검사할 때 Status.runtimeClass 필드에서 kata 만 찾습니다. 런타임 클래스 kata-remote-cc 가 나타나지 않습니다. 현재 이 문제에 대한 해결방법이 없습니다.

(KATA-2164)

OpenShift 샌드박스 컨테이너에서 이전 버전의 Buildah 툴을 사용하는 경우 다음 오류와 함께 빌드가 실패합니다.

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

subprocess exited with status 1

quay.io 에서 사용할 수 있는 최신 Buildah 버전을 사용해야 합니다.

(KATA-1278)