1.5. 확인된 문제

  • OpenShift 샌드박스 컨테이너를 사용하는 경우 컨테이너 수준에서 SELinux MCS(Multi-Category Security) 라벨을 설정하면 Pod가 다음 오류로 인해 시작되지 않습니다. 

    Error: CreateContainer failed: EACCES: Permission denied: unknown

    컨테이너 수준에서 설정된 MCS 라벨은 virtiofsd에는 적용되지 않습니다. kata 런타임은 VM을 생성할 때 컨테이너의 보안 컨텍스트에 액세스할 수 없습니다.

    즉 virtiofsd는 적절한 SELinux 레이블로 실행되지 않으며 VM의 컨테이너를 대신하여 호스트 파일에 액세스할 수 없습니다. 모든 컨테이너는 VM의 모든 파일에 액세스할 수 있습니다.

    (KATA-1875)

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

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

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

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

  • 일부 OpenShift 샌드박스 컨테이너 Operator Pod는 컨테이너 CPU 리소스 제한을 사용하여 Pod에 사용 가능한 CPU 수를 늘립니다. 이러한 Pod는 요청된 CPU보다 적은 수의 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(사용자 정의 리소스)의 상태 섹션에 표시됩니다. 그러나 다음 조건이 모두 해당되는 경우 진행률이 표시되지 않습니다.

    • 작업자 노드는 정의되어 있지 않습니다. oc get machineconfigpool 을 실행하여 머신 구성 풀의 작업자 노드 수를 확인할 수 있습니다.
    • 설치에 필요한 노드를 선택하려면 kataConfigPoolSelector 가 지정되지 않습니다.

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

  • 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)

  • 웹 콘솔의 KataConfig 탭에서 YAML 보기에서 KataConfig 생성 을 클릭하면 KataConfig YAML에 spec 필드가 없습니다. 양식 보기로 전환한 다음 YAML 보기로 돌아가 이 문제가 해결되어 전체 YAML이 표시됩니다. (KATA-1372)
  • 웹 콘솔의 KataConfig 탭에서 KataConfig CR이 이미 존재하는지 여부에 관계없이 404: Not found 오류 메시지가 표시됩니다. 기존 KataConfig CR에 액세스하려면 홈 > 검색 으로 이동합니다. 리소스 목록에서 KataConfig 를 선택합니다. (KATA-1605)

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

    다음 명령을 사용하여 kataMonitor 이미지를 업그레이드합니다. 

    $ oc patch kataconfig example-kataconfig --type merge --patch '{"spec":{"kataMonitorImage":"registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel8:1.3.0"}}'

    웹 콘솔에서 KataConfig YAML을 편집하여 kataMonitor 이미지를 업그레이드할 수도 있습니다.

    (KATA-1650)