1.4. 확인된 문제


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

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

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

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

  • MCO(Machine Config Operator) Pod가 CrashLoopBackOff 상태로 변경되는 문제와 Pod의 openshift.io/scc 주석이 기본 hostmount-anyuid 값 대신 sandboxed-containers-operator-scc 를 표시하는 문제가 발생할 수 있습니다.

    이 경우, 샌드박스-containers-operator-scc SCC의 seLinuxOptions 전략을 덜 제한적인 RunAsAny 로 변경하므로 승인 프로세스가 hostmount-anyuid SCC보다 우선하지 않습니다.

    1. 다음 명령을 실행하여 seLinuxOptions 전략을 변경합니다.

      $ oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "RunAsAny"}}'
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 MCO Pod를 다시 시작합니다.

      $ oc scale deployments/machine-config-operator -n openshift-machine-config-operator --replicas=0
      Copy to Clipboard Toggle word wrap
      $ oc scale deployments/machine-config-operator -n openshift-machine-config-operator --replicas=1
      Copy to Clipboard Toggle word wrap
    3. 다음 명령을 실행하여 sandbox-containers-operator-sccseLinuxOptions 전략을 MustRunAs 의 원래 값으로 되돌립니다.

      $ oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "MustRunAs"}}'
      Copy to Clipboard Toggle word wrap
    4. 다음 명령을 실행하여 hostmount-anyuid SCC가 MCO Pod에 적용되는지 확인합니다.

      $ oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o yaml | grep scc
      openshift.io/scc: hostmount-anyuid
      Copy to Clipboard Toggle word wrap

      (BZ#2057545)

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

    $ lscpu
    Copy to Clipboard Toggle word wrap

    출력 예

    CPU(s):                          16
    On-line CPU(s) list:             0-12,14,15
    Off-line CPU(s) list:            13
    Copy to Clipboard Toggle word wrap

    사용 가능한 오프라인 CPU 목록은 예기치 않은 방식으로 실행되도록 실행에서 변경될 수 있습니다.

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

    metadata:
      annotations:
        io.katacontainers.config.hypervisor.default_vcpus: "16"
    Copy to Clipboard Toggle word wrap

    (KATA-1376)

  • 런타임 설치 진행률이 kataConfig CR의 상태 섹션에 표시됩니다. 그러나 다음 조건이 모두 해당되는 경우 진행률이 표시되지 않습니다.

    • 클러스터에는 멤버가 없는 머신 구성 풀 worker (machinecount=0)가 있습니다.
    • 설치에 필요한 노드를 선택하려면 kataConfigPoolSelector 가 지정되지 않습니다.

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

  • KataConfig CR을 생성하고 openshift-sandboxed-containers-operator 네임스페이스 아래에 Pod 상태를 관찰하면 모니터 Pod에 대한 재시작 횟수가 많이 표시됩니다. 모니터 Pod는 샌드박스-containers 확장 설치의 일부로 설치된 특정 SELinux 정책을 사용합니다. 모니터 Pod가 즉시 생성되지만 SELinux 정책을 아직 사용할 수 없으므로 Pod 생성 오류가 발생하고 Pod가 다시 시작됩니다. 확장 설치에 성공하면 SELinux 정책을 사용할 수 있고 모니터 Pod가 실행 중 상태로 전환됩니다. 이는 OpenShift 샌드박스 컨테이너 Operator 기능에는 영향을 미치지 않습니다. (KATA-1338)
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat