NFS 파일 스토리지 권한에 대한 그룹 ID 오류와 함께 내 앱이 실패하는 이유는 무엇입니까?

파일 스토리지 그룹 ID 권한 오류 해결.

클래식 인프라

NFS 스토리지를 작성하거나 기존 NFS 스토리지를 클러스터에 추가하면 앱의 컨테이너 배치가 실패합니다. 그룹 ID(GID) 오류 메시지가 표시됩니다.

사용자 및 사용자 ID(UID)를 지정하지 않은 이미지로부터 컨테이너를 작성하는 경우에는 기본적으로 Dockerfile에 있는 모든 명령어가 루트 사용자(UID: 0)에 의해 실행됩니다.

그러나 NFS 파일 공유를 컨테이너에 마운트할 경우 컨테이너 내부의 사용자 ID 0는 NFS 호스트 시스템의 사용자 ID nobody에 맵핑됩니다. 그러나 볼륨 마운트 경로는 nobody가 아닌 사용자 ID root가 소유합니다. 이 보안 기능은 루트 스쿼시로도 알려져 있습니다. 루트 스쿼시는 실제 NFS 호스트 파일 시스템에 대한 사용자 ID 루트 권한을 부여하지 않고 컨테이너를 마운트하여 NFS 내에서 데이터를 보호합니다.

Kubernetes 를 사용하여 DaemonSetNFSv4 파일 공유에 대해 모든 워커 노드의 스토리지 마운트 경로에 루트 권한을 부여하려면 이 설정을 사용하십시오.

볼륨 마운트 경로에 대한 루트 권한을 허용하려면 작업자 노드에서 configmap을 설정해야 합니다. configmap은 NFS 호스트 시스템에서 컨테이너의 루트 사용자 ID nobody으로 사용자 ID 0를 맵핑합니다. 이 프로세스는 비루트 스쿼시라고도 합니다. 모든 작업자 노드를 업데이트하는 효과적인 방법은 클러스터의 모든 작업자 노드에서 지정된 팟(Pod)을 실행하는 디먼 세트를 사용하는 것입니다. 이 경우 디먼 세트로 제어되는 팟(Pod)은 볼륨 마운트 경로에 대한 루트 권한을 사용으로 설정하도록 각 작업자 노드를 업데이트합니다.

배치는 디먼 세트 팟(Pod)이 호스트 파일 시스템에 액세스하는 데 필요한 권한 모드에서 실행될 수 있도록 구성됩니다. 권한 모드에서 팟(Pod)을 실행하면 보안 위험이 발생할 수 있으므로 이 옵션 사용 시 주의해야 합니다.

디먼 세트를 실행하는 중에 클러스터에 추가된 새 작업자 노드가 자동으로 업데이트됩니다.

시작하기 전에:

지속적 스토리지를 작성하십시오.
Red Hat OpenShift 클러스터에 액세스하십시오.

다음 단계를 완료하십시오.

norootsquash 데몬 세트 배포용 YAML 파일을 복사합니다.
norootsquash 디먼 세트 배치를 작성하십시오.
```
oc apply -f norootsquash.yaml
```
스토리지 볼륨이 마운트되는 팟(Pod)의 이름을 가져오십시오. 이 팟(Pod)은 norootsquash 팟(Pod)과 동일하지 않습니다.
```
oc get pods
```
팟(Pod)에 로그인하십시오.
```
oc exec -it mypod /bin/bash
```
마운트 경로에 대한 권한이 root인지 확인하십시오.
```
root@mypod:/# ls -al /mnt/myvol/
total 8
drwxr-xr-x 2 root root 4096 Feb  7 20:49 .
drwxr-xr-x 1 root root 4096 Feb 20 18:19 .
```
이 출력 결과를 보면, 첫 번째 행의 UID가 이제 root 소유로 변경되었음을 알 수 있습니다(이전에는 nobody 소유였습니다).
nobody가 UID를 소유하고 있는 경우에는 팟(Pod)을 종료하고 클러스터의 작업자 노드를 다시 부팅하십시오. 노드가 다시 부팅될 때까지 기다리십시오.
```
ibmcloud oc worker reboot --cluster MY_CLUSTER --worker MY_WORKER1,MY_WORKER2
```
권한을 확인하려면 4단계 및 5단계를 반복하십시오.