Perché vedo un `UnresponsiveMountHelperContainerUtility` errore perFile Storage for VPC ?

Cloud privato virtuale

L'app che utilizza la crittografia in transito (EIT) con un profilo zonale dp2 File Storage for VPC genera un errore UnresponsiveMountHelperContainerUtility.

Risolvi i problemi relativi ai sistemi di archiviazione file VPC che non rispondono utilizzando la tecnologia EIT (Encrypted In Transit).

Viene visualizzato un messaggio di errore simile a quello riportato nell'esempio seguente:

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

O l'EIT non è abilitato sui tuoi pool di worker, oppure il pod della tua app è stato pianificato su un nodo del pool di worker in cui l'EIT non è abilitato. Si verifica una delle seguenti condizioni:

ENABLE_EIT " false " o " EIT_ENABLED_WORKER_POOLS " è vuoto nella configmap.
Il pool di worker su cui è in esecuzione il pod non è elencato in EIT_ENABLED_WORKER_POOLS.
Sui nodi di lavoro RHCOS, i pacchetti EIT sono stati installati, ma il nodo non è stato ancora riavviato per attivarli.
Sui nodi di lavoro RHCOS, è stato eseguito un precedente ciclo di disinstallazione e reinstallazione senza riavvio intermedio, lasciando il pacchetto in uno stato corrotto "già stratificato".

Risolvere il problema

Seguire i passaggi riportati di seguito per individuare e risolvere il problema.

Verifica quali nodi hanno l'EIT abilitato

Esamina la mappa di configurazione “ file-csi-driver-status ” per verificare su quali nodi sono installati i pacchetti EIT e assicurati che la configurazione sia corretta.

Descrivi lo stato della configmap per verificare su quali nodi sia abilitato l'EIT. Cerca la chiave “ EIT_ENABLED_WORKER_NODES ”, che elenca i nomi dei pool di worker e gli indirizzi IP dei nodi in cui l’installazione di EIT è stata completata.
```
kubectl describe cm file-csi-driver-status -n kube-system
```
Output di esempio:
```
EIT_ENABLED_WORKER_NODES:
----
default:
- 10.240.0.89
- 10.240.0.87
- 10.240.0.88
```
Un valore vuoto indica che su nessun nodo è stato ancora installato l'EIT.
Verificare che l'impostazione " ENABLE_EIT " sia impostata su " true " e che il pool di worker di destinazione sia elencato in " EIT_ENABLED_WORKER_POOLS".
```
kubectl describe cm addon-vpc-file-csi-driver-configmap -n kube-system
```

Verifica che il pod della tua app sia in esecuzione su un nodo abilitato per EIT

Elenca i tuoi pod per scoprire su quale nodo sono stati pianificati, quindi verifica incrociando i dati con l'elenco della sezione precedente.

Elenca i tuoi pod e prendi nota dell'indirizzo IP del nodo su cui è in esecuzione ciascun pod.
```
kubectl get pods -A -o wide
```
Verifica che l'IP del nodo corrisponda all'elenco presente all'indirizzo EIT_ENABLED_WORKER_NODES indicato al punto 1. Se il pod si trova su un nodo che non è presente in tale elenco, procedere in uno dei seguenti modi:
- Spostare il pod su un nodo abilitato per EIT utilizzando i selettori di nodo o le regole di affinità.
- Aggiungi il pool di worker che contiene quel nodo a EIT_ENABLED_WORKER_POOLS nella configmap e attendi che l'operatore esegua la riconciliazione.

Considerazioni specifiche relative al sistema operativo

L'installazione dei pacchetti necessari varia a seconda del sistema operativo del nodo di lavoro.

Ubuntu e RHEL

Non è richiesto il riavvio. I pacchetti diventano attivi subito dopo l'installazione. Se l'IP del nodo compare in EIT_ENABLED_WORKER_NODES e il pod si trova su quel nodo, l'EIT dovrebbe funzionare correttamente. Se il socket continua a non essere presente, controllare i log del pod dell'operatore di archiviazione per verificare la presenza di errori di installazione.

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

RHCOS / CoreOS

RHCOS è un sistema operativo immutabile. I pacchetti non sono attivi finché il nodo non viene riavviato, anche se l'IP del nodo compare già in EIT_ENABLED_WORKER_NODES.

Node Viene visualizzato come compatibile con EIT, ma il montaggio continua a non riuscire

Se l'indirizzo IP del nodo è presente nell'elenco EIT_ENABLED_WORKER_NODES ma continua a comparire l'errore " UnresponsiveMountHelperContainerUtility ", significa che il nodo non è stato riavviato dopo l'installazione dei pacchetti. La presa /var/lib/ibmshare.sock non è disponibile fino a dopo il riavvio.

Per verificare se è in corso un riavvio, eseguire i seguenti comandi sul nodo interessato:

Aprire una shell di debug sul nodo interessato utilizzando la CLI di OpenShift.
```
oc debug node/<nodeName>
```
All'interno della shell di debug, verifica se i pacchetti EIT sono stati caricati ma non sono ancora attivi.
```
chroot /host
rpm-ostree status
```
Nell'output, cerca un livello in sospeso o in fase di elaborazione che riporti i seguenti indirizzi: mount-helper e mount-helper-container. Se i pacchetti compaiono in un livello che non è contrassegnato come " (booted)", è necessario riavviare il sistema per attivarli.

Esempio di output che mostra i pacchetti preparati per il prossimo avvio:
```
State: idle
Deployments:
  ● ostree-unverified-registry:...
    ...
    LayeredPackages: mount-helper mount-helper-container
  ostree-unverified-registry:...  (booted)
    ...
```

Per risolvere il problema, spegnere e riavviare il nodo RHCOS interessato, in modo da evitare ripercussioni sui carichi di lavoro in esecuzione.

Individua gli ID dei worker corrispondenti ai nodi elencati all'indirizzo EIT_ENABLED_WORKER_NODES, associandoli ai rispettivi indirizzi IP.
```
ibmcloud ks workers --cluster CLUSTER_ID
```
Svuotare il nodo per terminare in modo sicuro tutti i pod in esecuzione prima del riavvio.
```
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
```

Riavvia il nodo in stato di drenaggio.

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

Una volta che il nodo è tornato online e si trova nello stato " Ready ", rimuovine il blocco per consentire nuovamente la pianificazione dei carichi di lavoro su di esso.
```
kubectl uncordon <node-name>
```

L'installazione del processo fallisce con l'errore "già stratificato" su RHCOS

Se in precedenza è stato disinstallato EIT su un pool di worker RHCOS e successivamente è stato riattivato senza riavviare il nodo nel frattempo, il processo di installazione dell'operatore di archiviazione potrebbe non andare a buon fine, generando un errore simile al seguente:

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

Ciò accade perché rpm-ostree uninstall esegue solo la rimozione provvisoria. I pacchetti rimangono presenti nel livello di avvio corrente fino al riavvio del sistema. Quando l'operatore prova a eseguire nuovamente il comando rpm-ostree install , il sistema rileva che i pacchetti sono già installati.

Per risolvere il problema:

Svuotare il nodo per terminare in modo sicuro tutti i pod in esecuzione prima del riavvio.
```
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
```

Riavvia il nodo RHCOS per applicare la disinstallazione in sospeso.

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

Una volta che il nodo è tornato online e si trova nello stato " Ready ", rimuovine il blocco per consentire nuovamente la pianificazione dei carichi di lavoro su di esso.
```
kubectl uncordon <node-name>
```
Una volta che il nodo torna online, i pacchetti installati in precedenza non sono più presenti. L'operatore del sistema di archiviazione li reinstalla automaticamente nel ciclo di riconciliazione successivo, solitamente nel giro di pochi minuti.
Dopo che l'operatore ha segnalato che il nodo è abilitato per EIT in EIT_ENABLED_WORKER_NODES, spegnere e riavviare nuovamente il nodo per attivare i pacchetti appena installati, quindi rimuovere il cordone.

Il ciclo completo per la disinstallazione e la reinstallazione di RHCOS è il seguente: riavvio dopo la disinstallazione → reinstallazione da parte dell'operatore → nuovo riavvio per l'attivazione.

Nuovi nodi aggiunti a un pool di worker abilitato per EIT

Quando un nuovo nodo entra a far parte di un pool di worker già presente nell'elenco all'indirizzo EIT_ENABLED_WORKER_POOLS, l'operatore di archiviazione installa automaticamente i pacchetti EIT sul nuovo nodo durante il successivo ciclo di riconciliazione. Non è necessario aggiornare la configmap.

Per i nodi RHCOS, è comunque necessario svuotare la memoria e riavviare il nodo dopo l'installazione affinché l'EIT diventi attivo. Svuotare il nodo, riavviarlo e quindi disattivarlo per ridurre l'impatto sui carichi di lavoro in esecuzione. Fino al riavvio del nodo, qualsiasi pod che utilizzi un PVC con EIT abilitato e che sia stato pianificato su quel nuovo nodo visualizza lo stesso errore “ UnresponsiveMountHelperContainerUtility ”. Ubuntu I nodi (IKS) e RHEL (ROKS) non richiedono il riavvio quando viene aggiunto un nuovo nodo.

Perché vedo un UnresponsiveMountHelperContainerUtility errore perFile Storage for VPC ?