Por que eu vejo um `UnresponsiveMountHelperContainerUtility` erro paraFile Storage for VPC ?

Nuvem Privada Virtual

Seu aplicativo, que utiliza criptografia em trânsito (EIT) com um perfil zonal do dp2 File Storage for VPC, apresenta falha com o erro UnresponsiveMountHelperContainerUtility.

Resolva problemas em sistemas de armazenamento de arquivos VPC que não respondem usando o EIT (Encrypted In Transit).

Você vê uma mensagem de erro semelhante ao exemplo a seguir:

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'.

Ou o EIT não está habilitado em seus pools de trabalhadores, ou o pod do seu aplicativo está agendado em um nó do pool de trabalhadores onde o EIT não está habilitado. Uma das seguintes condições é verdadeira:

ENABLE_EIT false ou está vazio no configmap. EIT_ENABLED_WORKER_POOLS
O conjunto de workers no qual o pod está sendo executado não está listado em EIT_ENABLED_WORKER_POOLS.
Nos nós de trabalho do RHCOS, os pacotes EIT estão instalados, mas o nó ainda não foi reiniciado para ativá-los.
Nos nós de trabalho do RHCOS, foi realizado um ciclo anterior de desinstalação e reinstalação sem reinicialização entre as duas etapas, o que deixou o pacote em um estado corrompido de “já em camadas”.

Resolvendo o problema

Siga as etapas a seguir para identificar e resolver a causa.

Verifique quais nós têm o EIT ativado

Analise o configmap file-csi-driver-status para verificar quais nós têm os pacotes EIT instalados e confirme se a configuração está correta.

Descreva o status do configmap para verificar quais nós têm o EIT ativado. Procure a chave EIT_ENABLED_WORKER_NODES , que lista os nomes dos pools de trabalhadores e os endereços IP dos nós nos quais a instalação do EIT foi concluída.
```
oc describe cm file-csi-driver-status -n kube-system
```
Saída de exemplo:
```
EIT_ENABLED_WORKER_NODES:
----
default:
- 10.240.0.89
- 10.240.0.87
- 10.240.0.88
```
Um valor vazio significa que ainda não foi instalado o EIT em nenhum nó.
Verifique se a opção “ ENABLE_EIT ” está definida como “ true ” e se o pool de workers de destino está listado em EIT_ENABLED_WORKER_POOLS.
```
oc describe cm addon-vpc-file-csi-driver-configmap -n kube-system
```

Verifique se o pod do seu aplicativo está em execução em um nó habilitado para EIT

Liste seus pods para descobrir em qual nó eles estão agendados e, em seguida, compare com a lista da seção anterior.

Liste seus pods e anote o endereço IP do nó no qual cada pod está sendo executado.
```
oc get pods -A -o wide
```
Verifique se o endereço IP do nó está na lista EIT_ENABLED_WORKER_NODES da Etapa 1. Se o pod estiver em um nó que não conste nessa lista, execute uma das seguintes ações:
- Mova o pod para um nó compatível com EIT usando seletores de nó ou regras de afinidade.
- Adicione o conjunto de workers que contém esse nó a EIT_ENABLED_WORKER_POOLS no configmap e aguarde a reconciliação do operador.

Considerações específicas do sistema operacional

A instalação dos pacotes necessários varia de acordo com o sistema operacional do nó de trabalho.

Ubuntu e RHEL

Nenhuma reinicialização é necessária. Os pacotes entram em operação imediatamente após a instalação. Se o IP do nó aparecer em EIT_ENABLED_WORKER_NODES e o pod estiver nesse nó, o EIT deve estar funcionando. Se o soquete ainda estiver faltando, verifique os logs do pod do operador de armazenamento para identificar erros de instalação.

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

RHCOS / CoreOS

O RHCOS é um sistema operacional imutável. Os pacotes não ficam ativos até que o nó seja reiniciado, mesmo que o endereço IP do nó já conste em EIT_ENABLED_WORKER_NODES.

Node aparece como compatível com EIT, mas a montagem continua falhando

Se o endereço IP do nó estiver listado em EIT_ENABLED_WORKER_NODES, mas você ainda receber o erro “ UnresponsiveMountHelperContainerUtility ”, isso significa que o nó não foi reiniciado desde que os pacotes foram instalados. O soquete /var/lib/ibmshare.sock só passa a existir após a reinicialização do sistema.

Para confirmar se há uma reinicialização pendente, execute os seguintes comandos no nó afetado:

Abra um shell de depuração no nó afetado usando a CLI do OpenShift.
```
oc debug node/<nodeName>
```
No shell de depuração, verifique se há pacotes EIT preparados, mas ainda não ativos.
```
chroot /host
rpm-ostree status
```
Na saída, procure por uma camada pendente ou em fase de preparação que inclua mount-helper e mount-helper-container. Se os pacotes aparecerem em uma camada que não esteja marcada como “ (booted) ”, será necessário reiniciar o sistema para ativá-los.

Exemplo de saída mostrando os pacotes preparados para a próxima inicialização:
```
State: idle
Deployments:
  ● ostree-unverified-registry:...
    ...
    LayeredPackages: mount-helper mount-helper-container
  ostree-unverified-registry:...  (booted)
    ...
```

Para resolver isso, esvazie e reinicie o nó RHCOS afetado para evitar impacto nas cargas de trabalho em execução.

Encontre os IDs dos workers correspondentes aos nós listados em EIT_ENABLED_WORKER_NODES, identificando-os a partir de seus endereços IP.
```
ibmcloud ks workers --cluster CLUSTER_ID
```
Drenar o nó para encerrar com segurança todos os pods em execução antes da reinicialização.
```
oc drain <node-name> --ignore-daemonsets --delete-emptydir-data
```

Reinicie o nó que ficou sem energia.

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

Depois que o nó estiver novamente online e no estado “ Ready ”, desative o uncordon para permitir que as cargas de trabalho sejam agendadas nele novamente.
```
oc uncordon <node-name>
```

A instalação da tarefa falha com o erro “já está em camadas” no RHCOS

Se você tiver desinstalado o EIT anteriormente em um pool de trabalhadores do RHCOS e, em seguida, o tiver reativado sem reiniciar o nó entre uma ação e outra, a tarefa de instalação do operador de armazenamento poderá falhar com um erro semelhante a:

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

Isso ocorre porque o comando rpm-ostree uninstall apenas prepara a remoção. Os pacotes permanecem na camada de inicialização atual até que ocorra uma reinicialização. Quando o operador tenta executar o comando rpm-ostree install novamente, o sistema reconhece os pacotes como já instalados.

Para resolver isso:

Drenar o nó para encerrar com segurança todos os pods em execução antes da reinicialização.
```
oc drain <node-name> --ignore-daemonsets --delete-emptydir-data
```

Reinicie o nó do RHCOS para aplicar a desinstalação pendente.

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

Depois que o nó estiver novamente online e no estado “ Ready ”, desative o uncordon para permitir que as cargas de trabalho sejam agendadas nele novamente.
```
oc uncordon <node-name>
```
Depois que o nó voltar a ficar online, os pacotes instalados anteriormente terão sido removidos. O operador de armazenamento os reinstala automaticamente no próximo ciclo de reconciliação, normalmente em poucos minutos.
Depois que a operadora informar que o nó está habilitado para EIT em EIT_ENABLED_WORKER_NODES, esvazie e reinicie o nó novamente para ativar os pacotes recém-instalados e, em seguida, remova o cordão de segurança.

O ciclo completo para desinstalar e reinstalar o RHCOS é: reiniciar após a desinstalação → o operador reinstala → reiniciar novamente para ativar.

Novos nós adicionados a um pool de trabalhadores habilitado para EIT

Quando um novo nó se junta a um pool de trabalhadores que já está listado em EIT_ENABLED_WORKER_POOLS, o operador de armazenamento instala automaticamente os pacotes EIT no novo nó durante seu próximo ciclo de reconciliação. Não é necessária nenhuma atualização do configmap.

No caso dos nós RHCOS, ainda é necessário esvaziar a memória e reiniciar o nó após a instalação para que o EIT entre em operação. Drenar o nó, reiniciá-lo e, em seguida, desconectá-lo para reduzir o impacto nas cargas de trabalho em execução. Até que o nó seja reiniciado, qualquer pod que utilize um PVC habilitado para EIT e seja agendado nesse novo nó receberá o mesmo erro “ UnresponsiveMountHelperContainerUtility ”. Ubuntu Os nós (IKS) e RHEL (ROKS) não exigem reinicialização quando um novo nó é adicionado.

Por que eu vejo um UnresponsiveMountHelperContainerUtility erro paraFile Storage for VPC ?