Pourquoi est-ce que je vois un `UnresponsiveMountHelperContainerUtility` erreur pourFile Storage for VPC ?

Cloud privé virtuel

Votre application, qui utilise le chiffrement en transit (EIT) avec un profil de zone dp2 File Storage for VPC, génère une erreur « UnresponsiveMountHelperContainerUtility ».

Dépannage des systèmes de stockage de fichiers VPC qui ne répondent pas avec EIT (Encrypted In Transit).

Un message d'erreur similaire à l'exemple suivant s'affiche :

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

Soit l'EIT n'est pas activé sur vos pools de travailleurs, soit le pod de votre application est planifié sur un nœud du pool de travailleurs où l'EIT n'est pas activé. L'une des conditions suivantes est remplie :

ENABLE_EIT « false » ou « EIT_ENABLED_WORKER_POOLS » est vide dans la configmap.
Le pool de travailleurs sur lequel le pod s'exécute n'apparaît pas dans EIT_ENABLED_WORKER_POOLS.
Sur les nœuds de travail RHCOS, les paquets EIT sont installés, mais le nœud n'a pas encore été redémarré pour les activer.
Sur les nœuds de travail RHCOS, un cycle de désinstallation puis de réinstallation avait été effectué sans redémarrage entre les deux, ce qui a laissé le paquet dans un état corrompu « déjà superposé ».

Résolution du problème

Suivez les étapes ci-dessous pour identifier et résoudre le problème.

Vérifier quels nœuds ont l'EIT activé

Consultez la carte de configuration « file-csi-driver-status » pour identifier les nœuds sur lesquels les paquets EIT sont installés et vérifier que la configuration est correcte.

Consultez la configuration « status configmap » pour voir sur quels nœuds l'EIT est activé. Recherchez la clé « EIT_ENABLED_WORKER_NODES », qui répertorie les noms des pools de travailleurs ainsi que les adresses IP des nœuds sur lesquels l'installation d'EIT est terminée.
```
oc describe cm file-csi-driver-status -n kube-system
```
Exemple de sortie :
```
EIT_ENABLED_WORKER_NODES:
----
default:
- 10.240.0.89
- 10.240.0.87
- 10.240.0.88
```
Une valeur vide signifie qu'aucun nœud n'a encore été équipé de l'EIT.
Vérifiez que le paramètre « ENABLE_EIT » est défini sur « true » et que le pool de workers cible figure dans la liste disponible à l'adresse EIT_ENABLED_WORKER_POOLS.
```
oc describe cm addon-vpc-file-csi-driver-configmap -n kube-system
```

Vérifiez que le pod de votre application s'exécute sur un nœud prenant en charge EIT

Répertoriez vos pods pour déterminer sur quel nœud ils sont planifiés, puis comparez ces informations avec la liste de la section précédente.

Répertoriez vos pods et notez l'adresse IP du nœud sur lequel chacun d'entre eux s'exécute.
```
oc get pods -A -o wide
```
Vérifiez que l'adresse IP du nœud figure bien dans la liste EIT_ENABLED_WORKER_NODES de l'étape 1. Si le pod se trouve sur un nœud qui ne figure pas dans cette liste, procédez de l'une des manières suivantes :
- Déplacez le pod vers un nœud prenant en charge l'EIT à l'aide de sélecteurs de nœuds ou de règles d'affinité.
- Ajoutez le pool de travailleurs contenant ce nœud à la clé « EIT_ENABLED_WORKER_POOLS » dans la configmap, puis attendez que l'opérateur effectue la réconciliation.

Considérations spécifiques au système d'exploitation

L'installation des paquets requis varie en fonction du système d'exploitation du nœud de travail.

Ubuntu et RHEL

Aucun réamorçage n'est requis. Les paquets sont activés dès leur installation. Si l'adresse IP du nœud apparaît dans EIT_ENABLED_WORKER_NODES et que le pod se trouve sur ce nœud, l'EIT devrait fonctionner correctement. Si le socket est toujours manquant, vérifiez les journaux du pod de l'opérateur de stockage pour voir s'il y a des erreurs d'installation.

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

RHCOS / CoreOS

RHCOS est un système d'exploitation immuable. Les paquets ne sont pas actifs tant que le nœud n'a pas été redémarré, même si l'adresse IP du nœud figure déjà dans EIT_ENABLED_WORKER_NODES.

Node Il est indiqué que la fonction EIT est activée, mais le montage échoue toujours

Si l'adresse IP du nœud figure dans le fichier EIT_ENABLED_WORKER_NODES , mais que l'erreur « UnresponsiveMountHelperContainerUtility » s'affiche toujours, cela signifie que le nœud n'a pas été redémarré depuis l'installation des paquets. Le socket /var/lib/ibmshare.sock n'existe qu'après un redémarrage.

Pour vérifier qu'un redémarrage est en attente, exécutez les commandes suivantes sur le nœud concerné :

Ouvrez un shell de débogage sur le nœud concerné à l'aide de l'interface CLI d' OpenShift.
```
oc debug node/<nodeName>
```
Dans le shell de débogage, vérifiez si des paquets EIT sont préparés mais pas encore actifs.
```
chroot /host
rpm-ostree status
```
Dans le résultat, recherchez une couche en attente ou en cours de préparation qui mentionne mount-helper et mount-helper-container. Si les paquets apparaissent dans une couche marquée « pas » ( (booted)), un redémarrage est nécessaire pour les activer.

Exemple de sortie indiquant les paquets préparés pour le prochain démarrage :
```
State: idle
Deployments:
  ● ostree-unverified-registry:...
    ...
    LayeredPackages: mount-helper mount-helper-container
  ostree-unverified-registry:...  (booted)
    ...
```

Pour résoudre ce problème, videz la mémoire et redémarrez le nœud RHCOS concerné afin d'éviter tout impact sur les charges de travail en cours d'exécution.

Recherchez les identifiants des nœuds répertoriés à l'adresse EIT_ENABLED_WORKER_NODES en les associant à leurs adresses IP.
```
ibmcloud ks workers --cluster CLUSTER_ID
```
Videz le nœud afin de fermer en toute sécurité tous les pods en cours d'exécution avant le redémarrage.
```
oc drain <node-name> --ignore-daemonsets --delete-emptydir-data
```

Redémarrez le nœud mis hors tension.

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

Une fois que le nœud est de nouveau en ligne et dans l'état « Ready », désactivez-le pour permettre à nouveau la planification de charges de travail sur celui-ci.
```
oc uncordon <node-name>
```

L'installation échoue avec le message d'erreur « déjà en couches » sur RHCOS

Si vous avez précédemment désinstallé EIT sur un pool de nœuds de travail RHCOS, puis que vous l'avez réactivé sans redémarrer le nœud entre-temps, la tâche d'installation de l'opérateur de stockage risque d'échouer avec une erreur similaire à celle-ci :

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

Cela s'explique par le fait que la commande « rpm-ostree uninstall » ne fait que préparer la suppression. Les paquets restent présents dans la couche de démarrage actuelle jusqu'au prochain redémarrage. Lorsque l'opérateur tente de relancer la commande « rpm-ostree install », le système considère que les paquets sont déjà installés.

Pour résoudre ce problème :

Videz le nœud afin de fermer en toute sécurité tous les pods en cours d'exécution avant le redémarrage.
```
oc drain <node-name> --ignore-daemonsets --delete-emptydir-data
```
Redémarrez le nœud RHCOS pour appliquer la désinstallation en attente.
```
ibmcloud ks worker reboot --cluster CLUSTER_ID --worker WORKER_ID
```
Une fois que le nœud est de nouveau en ligne et dans l'état « Ready », désactivez-le pour permettre à nouveau la planification de charges de travail sur celui-ci.
```
oc uncordon <node-name>
```
Une fois que le nœud est de nouveau en ligne, les paquets précédemment installés ont disparu. L'opérateur de stockage les réinstalle automatiquement lors du cycle de rapprochement suivant, généralement en l'espace de quelques minutes.
Une fois que l'opérateur a signalé que le nœud est compatible EIT dans EIT_ENABLED_WORKER_NODES, videz le nœud et redémarrez-le à nouveau pour activer les paquets nouvellement installés, puis déverrouillez-le.

Le cycle complet de désinstallation puis de réinstallation de RHCOS est le suivant : redémarrage après la désinstallation → réinstallation par l'opérateur → nouveau redémarrage pour l'activation.

Nouveaux nœuds ajoutés à un pool de travailleurs compatible EIT

Lorsqu'un nouveau nœud rejoint un pool de travailleurs déjà répertorié dans EIT_ENABLED_WORKER_POOLS, l'opérateur de stockage installe automatiquement les paquets EIT sur ce nouveau nœud lors de son prochain cycle de réconciliation. Aucune mise à jour de la carte de configuration n'est nécessaire.

Pour les nœuds RHCOS, vous devez tout de même vider le nœud et le redémarrer après l'installation avant que l'EIT ne devienne actif. Videz le nœud, redémarrez-le, puis déconnectez-le afin de limiter l'impact sur les charges de travail en cours d'exécution. Tant que le nœud n'a pas été redémarré, tout pod utilisant un PVC compatible EIT et planifié sur ce nouveau nœud rencontre la même erreur « UnresponsiveMountHelperContainerUtility ». Ubuntu Les nœuds (IKS) et RHEL (ROKS) ne nécessitent pas de redémarrage lorsqu'un nouveau nœud est ajouté.

Pourquoi est-ce que je vois un UnresponsiveMountHelperContainerUtility erreur pourFile Storage for VPC ?