This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.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-sccSCC의seLinuxOptions전략을 덜 제한적인RunAsAny로 변경하므로 승인 프로세스가hostmount-anyuidSCC보다 우선하지 않습니다.다음 명령을 실행하여
seLinuxOptions전략을 변경합니다.oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "RunAsAny"}}'$ oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "RunAsAny"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 MCO Pod를 다시 시작합니다.
oc scale deployments/machine-config-operator -n openshift-machine-config-operator --replicas=0
$ oc scale deployments/machine-config-operator -n openshift-machine-config-operator --replicas=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc scale deployments/machine-config-operator -n openshift-machine-config-operator --replicas=1
$ oc scale deployments/machine-config-operator -n openshift-machine-config-operator --replicas=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
sandbox-containers-operator-scc의seLinuxOptions전략을MustRunAs의 원래 값으로 되돌립니다.oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "MustRunAs"}}'$ oc patch scc sandboxed-containers-operator-scc --type=merge --patch '{"seLinuxContext":{"type": "MustRunAs"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hostmount-anyuidSCC가 MCO Pod에 적용되는지 확인합니다.oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o yaml | grep scc
$ oc get pods -n openshift-machine-config-operator -l k8s-app=machine-config-operator -o yaml | grep scc openshift.io/scc: hostmount-anyuidCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod에 사용 가능한 CPU 수를 늘리기 위해 컨테이너 CPU 리소스 제한을 사용하는 OpenShift 샌드박스 컨테이너 Operator Pod는 요청된 CPU보다 적은 수의 CPU를 수신할 수 있습니다. 컨테이너 내에서 기능을 사용할 수 있는 경우
oc rsh <pod>를 사용하고lscpu명령을 실행하여 CPU 리소스를 진단할 수 있습니다.lscpu
$ lscpuCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
CPU(s): 16 On-line CPU(s) list: 0-12,14,15 Off-line CPU(s) list: 13
CPU(s): 16 On-line CPU(s) list: 0-12,14,15 Off-line CPU(s) list: 13Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사용 가능한 오프라인 CPU 목록은 예기치 않은 방식으로 실행되도록 실행에서 변경될 수 있습니다.
이 문제를 해결하려면 Pod 주석을 사용하여 CPU 제한을 설정하지 않고 추가 CPU를 요청할 수 있습니다. 프로세서 할당 방법은 다르며 Pod 주석을 통해 요청한 CPU는 이 문제의 영향을 받지 않습니다. CPU 제한을 설정하는 대신 Pod의 메타데이터에 다음
주석을추가해야 합니다.metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: "16"metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: "16"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 런타임 설치 진행률이
kataConfigCR의상태섹션에 표시됩니다. 그러나 다음 조건이 모두 해당되는 경우 진행률이 표시되지 않습니다.-
클러스터에는 멤버가 없는 머신 구성 풀
worker(machinecount=0)가 있습니다. -
설치에 필요한 노드를 선택하려면
kataConfigPoolSelector가 지정되지 않습니다.
이 경우 Operator는 노드가 마스터 및 작업자 역할이 모두 있는 통합 클러스터라고 가정하므로 마스터 노드에서 설치가 시작됩니다.
kataConfigCR의status섹션은 설치 중에 업데이트되지 않습니다. (KATA-1017)-
클러스터에는 멤버가 없는 머신 구성 풀
-
KataConfigCR을 생성하고openshift-sandboxed-containers-operator네임스페이스 아래에 Pod 상태를 관찰하면 모니터 Pod에 대한 재시작 횟수가 많이 표시됩니다. 모니터 Pod는샌드박스-containers확장 설치의 일부로 설치된 특정 SELinux 정책을 사용합니다. 모니터 Pod가 즉시 생성되지만 SELinux 정책을 아직 사용할 수 없으므로 Pod 생성 오류가 발생하고 Pod가 다시 시작됩니다. 확장 설치에 성공하면 SELinux 정책을 사용할 수 있고 모니터 Pod가실행 중상태로 전환됩니다. 이는 OpenShift 샌드박스 컨테이너 Operator 기능에는 영향을 미치지 않습니다. (KATA-1338)