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

클래식 인프라

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

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

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

Kubernetes DaemonSet 를 사용하여 NFSv4 파일 공유에 대한 모든 작업자 노드의 스토리지 마운트 경로에 대한 루트 권한을 사용으로 설정하십시오.

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

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

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

시작하기 전에:

단계:

norootsquash 디먼 세트 배치 YAML 파일 복사
norootsquash 디먼 세트 배치를 작성하십시오.
```
kubectl apply -f norootsquash.yaml
```
스토리지 볼륨이 마운트되는 팟(Pod)의 이름을 가져오십시오. 이 팟(Pod)은 norootsquash 팟(Pod)과 동일하지 않습니다.
```
kubectl get pods
```
팟(Pod)에 로그인하십시오.
```
kubectl 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 ks worker reboot --cluster <my_cluster> --worker <my_worker1>,<my_worker2>
```
권한을 확인하려면 4단계 및 5단계를 반복하십시오.