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, era stato eseguito in precedenza un ciclo di disinstallazione e reinstallazione senza riavvio intermedio, lasciando il pacchetto in uno stato anomalo di "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 siano installati i pacchetti EIT e assicurati che la configurazione sia corretta.

Descrivi lo stato della configmap per verificare su quali nodi è 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.
```
oc 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".
```
oc 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.
```
oc get pods -A -o wide
```
Verifica che l'IP del nodo corrisponda all'elenco riportato all'indirizzo EIT_ENABLED_WORKER_NODES, come 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 mancare, controllare i log del pod dell'operatore di archiviazione per verificare la presenza di errori di installazione.

oc 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'indirizzo 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'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.
```
oc 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.
```
oc 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.
```
oc 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.
```
oc 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 provvede automaticamente a reinstallarli 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 storage 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 ?