검색

1.4. 확인된 문제

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

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.