나는 왜 `UnresponsiveMountHelperContainerUtility` 다음에 대한 오류File Storage for VPC ?

가상 사설 클라우드

존 기반 dp2 프로필( File Storage for VPC )을 사용하여 전송 중 암호화(EIT)를 적용한 앱에서 “ UnresponsiveMountHelperContainerUtility ” 오류가 발생합니다.

EIT(전송 중 암호화)를 사용하여 응답하지 않는 VPC 파일 스토리지 시스템의 문제를 해결합니다.

다음 예시와 유사한 오류 메시지가 표시됩니다:

Code: UnresponsiveMountHelperContainerUtility,
Description: Failed to mount target because unable to make connection to mount helper container service.,
BackendError: Failed to send EIT based request. Failed with error:
  Post "http://unix/api/mount": dial unix /var/lib/ibmshare.sock: connect: no such file or directory,
Action: Check if EIT is enabled from storage operator.
  Run command 'kubectl edit configmap addon-vpc-file-csi-driver-configmap -n kube-system'
  and set 'ENABLE_EIT' flag to 'true'.

사용자의 워커 풀에서 EIT가 활성화되어 있지 않거나, 앱 포드가 EIT가 활성화되지 않은 워커 풀 노드에 스케줄링된 것입니다. 다음 조건 중 하나가 성립합니다:

ENABLE_EIT configmap에서 false 또는 EIT_ENABLED_WORKER_POOLS 가 비어 있습니다.
포드가 실행되고 있는 워커 풀이 EIT_ENABLED_WORKER_POOLS 에 나열되어 있지 않습니다.
RHCOS 워커 노드에는 EIT 패키지가 설치되어 있지만, 이를 활성화하기 위해 노드를 아직 재부팅하지 않았습니다.
RHCOS 워커 노드에서, 이전에 재부팅 없이 제거 및 재설치 과정을 반복한 결과, 패키지가 “이미 레이어링된” 상태로 손상되었습니다.

문제 해결

원인을 파악하고 해결하려면 다음 단계를 따르십시오.

EIT가 활성화된 노드가 있는지 확인하세요

file-csi-driver-status 구성 맵을 검토하여 EIT 패키지가 설치된 노드가 어디인지 확인하고, 구성이 올바른지 확인하십시오.

EIT가 활성화된 노드가 어디인지 확인하려면 status configmap을 조회해 보세요. EIT_ENABLED_WORKER_NODES 키를 확인하십시오. 이 키에는 EIT 설치가 완료된 노드의 IP 주소와 워커 풀 이름이 나열되어 있습니다.
```
oc describe cm file-csi-driver-status -n kube-system
```
출력 예:
```
EIT_ENABLED_WORKER_NODES:
----
default:
- 10.240.0.89
- 10.240.0.87
- 10.240.0.88
```
값이 비어 있다면, 아직 EIT가 설치된 노드가 없다는 의미입니다.
ENABLE_EIT 가 true 로 설정되어 있는지, 그리고 대상 워커 풀이 EIT_ENABLED_WORKER_POOLS 에 나열되어 있는지 확인하십시오.
```
oc describe cm addon-vpc-file-csi-driver-configmap -n kube-system
```

앱 Pod가 EIT가 활성화된 노드에서 실행 중인지 확인하십시오

포드 목록을 확인하여 각 포드가 어떤 노드에 스케줄링되었는지 파악한 다음, 이전 섹션의 목록과 대조해 보십시오.

실행 중인 파드를 나열하고, 각 파드가 실행되고 있는 노드의 IP 주소를 기록해 두세요.
```
oc get pods -A -o wide
```
1단계에서 확인한 EIT_ENABLED_WORKER_NODES 목록과 노드 IP를 대조해 보십시오. 포드가 해당 목록에 포함되지 않은 노드에 있는 경우, 다음 중 하나를 수행하십시오
- 노드 선택기나 어피니티 규칙을 사용하여 포드를 EIT가 활성화된 노드로 이동합니다.
- 해당 노드가 포함된 워커 풀을 컨피그맵의 EIT_ENABLED_WORKER_POOLS 에 추가하고, 오퍼레이터가 재조정될 때까지 기다립니다.

운영 체제별 고려 사항

필요한 패키지는 워커 노드의 운영 체제에 따라 설치 방법이 다릅니다.

Ubuntu 그리고 RHEL

다시 부팅하지 않아도 됩니다. 패키지는 설치가 완료되는 즉시 활성화됩니다. 노드 IP가 EIT_ENABLED_WORKER_NODES 에 표시되고 해당 노드에 파드가 있다면, EIT는 정상적으로 작동해야 합니다. 소켓이 여전히 없는 경우, 스토리지 운영자 포드의 로그를 확인하여 설치 오류가 있는지 확인하십시오.

oc logs -n kube-system -l app=ibm-vpc-file-csi-operator --tail=100

RHCOS / CoreOS

RHCOS는 불변 운영 체제입니다. 노드의 IP 주소가 이미 EIT_ENABLED_WORKER_NODES 에 표시되어 있더라도, 노드를 재부팅하기 전까지는 패키지가 활성화되지 않습니다.

Node EIT 지원으로 표시되지만 마운트가 여전히 실패합니다

EIT_ENABLED_WORKER_NODES 에 노드 IP가 나열되어 있음에도 불구하고 여전히 “ UnresponsiveMountHelperContainerUtility ” 오류가 표시된다면, 패키지가 설치된 이후 해당 노드가 재부팅되지 않았기 때문입니다. /var/lib/ibmshare.sock 소켓은 시스템을 재부팅한 후에야 생성됩니다.

재시작이 대기 중인지 확인하려면, 해당 노드에서 다음 명령을 실행하십시오:

OpenShift CLI를 사용하여 문제가 발생한 노드에서 디버그 셸을 엽니다.
```
oc debug node/<nodeName>
```
디버그 셸에서 EIT 패키지가 스테이징되었으나 아직 활성화되지 않았는지 확인하십시오.
```
chroot /host
rpm-ostree status
```
출력 결과에서 mount-helper 및 mount-helper-container 이 나열된 보류 중이거나 준비 중인 레이어를 찾으십시오. 패키지가 ‘ (booted) ’로 표시되지 않은 레이어에 나타나는 경우, 해당 패키지를 활성화하려면 시스템을 재부팅해야 합니다.

다음 부팅을 위해 준비된 패키지를 보여주는 출력 예시:
```
State: idle
Deployments:
  ● ostree-unverified-registry:...
    ...
    LayeredPackages: mount-helper mount-helper-container
  ostree-unverified-registry:...  (booted)
    ...
```

이 문제를 해결하려면, 실행 중인 워크로드에 미치는 영향을 방지하기 위해 문제가 발생한 RHCOS 노드의 시스템을 종료한 후 재부팅하십시오.

EIT_ENABLED_WORKER_NODES 에 나열된 노드들의 IP 주소를 대조하여 해당 노드들의 워커 ID를 찾아보세요.
```
ibmcloud ks workers --cluster CLUSTER_ID
```
재부팅 전에 노드의 모든 실행 중인 파드를 안전하게 종료하십시오.
```
oc drain <node-name> --ignore-daemonsets --delete-emptydir-data
```

전원이 꺼진 노드를 재시작하십시오.

ibmcloud ks worker reboot --cluster CLUSTER_ID --worker WORKER_ID

노드가 다시 온라인 상태가 되고 ‘ Ready ’ 상태가 되면, 해당 노드의 uncordon을 해제하여 다시 워크로드를 스케줄링할 수 있도록 하십시오.
```
oc uncordon <node-name>
```

RHCOS에서 “이미 레이어링됨” 오류로 인해 설치 작업이 실패합니다

이전에 RHCOS 워커 풀에서 EIT를 제거한 후, 노드를 재부팅하지 않은 상태에서 다시 활성화한 경우, 스토리지 운영자 설치 작업이 다음과 유사한 오류와 함께 실패할 수 있습니다:

error: Packages are already layered: mount-helper-<version>.rpm mount-helper-container-<version>.rpm

rpm-ostree uninstall 는 삭제 작업을 스테이징 단계에서만 처리하기 때문에 이런 현상이 발생합니다. 재부팅이 이루어질 때까지 해당 패키지들은 현재 부팅 레이어에 그대로 남아 있습니다. 운영자가 rpm-ostree install 을 다시 실행하려고 하면, 해당 패키지들이 이미 설치된 것으로 표시됩니다.

이 문제를 해결하려면:

재부팅 전에 노드의 모든 실행 중인 파드를 안전하게 종료하십시오.
```
oc drain <node-name> --ignore-daemonsets --delete-emptydir-data
```
보류 중인 제거 작업을 적용하려면 RHCOS 노드를 재시작하십시오.
```
ibmcloud ks worker reboot --cluster CLUSTER_ID --worker WORKER_ID
```
노드가 다시 온라인 상태가 되고 ‘ Ready ’ 상태가 되면, 해당 노드의 uncordon을 해제하여 다시 워크로드를 스케줄링할 수 있도록 하십시오.
```
oc uncordon <node-name>
```
노드가 다시 온라인 상태가 되면, 이전에 설치되었던 패키지들은 사라집니다. 저장소 운영자는 다음 조정 주기 때, 대개 몇 분 이내에 이를 자동으로 다시 설치합니다.
운영자가 EIT_ENABLED_WORKER_NODES 에서 해당 노드가 EIT를 지원한다고 보고한 후, 노드를 다시 드레인하고 재부팅하여 새로 설치된 패키지를 활성화한 다음, 코든 상태를 해제하십시오.

RHCOS를 제거한 후 다시 설치하는 전체 절차는 다음과 같습니다: 제거 후 재부팅 → 운영자가 다시 설치 → 활성화하기 위해 다시 재부팅.

EIT가 활성화된 워커 풀에 새로운 노드가 추가됨

EIT_ENABLED_WORKER_POOLS 에 이미 등록된 워커 풀에 새로운 노드가 합류하면, 스토리지 운영자는 다음 조정 주기 동안 해당 새 노드에 EIT 패키지를 자동으로 설치합니다. 컨피그맵을 업데이트할 필요가 없습니다.

RHCOS 노드의 경우, 설치 후 EIT가 활성화되기 전에 반드시 노드의 데이터를 모두 삭제하고 재부팅해야 합니다. 노드의 데이터를 모두 비우고, 재부팅한 다음, 실행 중인 워크로드에 미치는 영향을 최소화하기 위해 연결을 해제하십시오. 노드가 재부팅될 때까지, EIT가 활성화된 PVC를 사용하고 해당 새 노드에 스케줄링된 모든 파드는 동일한 ‘ UnresponsiveMountHelperContainerUtility ’ 오류를 표시합니다. Ubuntu (IKS) 및 RHEL (ROKS) 노드는 새 노드가 추가될 때 재부팅할 필요가 없습니다.

나는 왜 UnresponsiveMountHelperContainerUtility 다음에 대한 오류File Storage for VPC ?