Warum sehe ich ein UnresponsiveMountHelperContainerUtility Fehler fürFile Storage for VPC ?

Virtual Private Cloud

Ihre App, die die Übertragung mit Verschlüsselung (EIT) mit einem zonalen „ dp2 “-Profil File Storage for VPC verwendet, schlägt mit dem Fehler „ UnresponsiveMountHelperContainerUtility “ fehl.

Fehlerbehebung bei nicht reagierenden VPC-Dateispeichersystemen mit EIT (Encrypted In Transit).

Es wird eine Fehlermeldung angezeigt, die dem folgenden Beispiel ähnelt:

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

Entweder ist EIT in Ihren Worker-Pools nicht aktiviert, oder Ihr App-Pod wird auf einem Knoten des Worker-Pools eingeplant, auf dem EIT nicht aktiviert ist. Eine der folgenden Bedingungen trifft zu:

  • ENABLE_EIT „ false “ oder „ EIT_ENABLED_WORKER_POOLS “ ist in der ConfigMap leer.
  • Der Worker-Pool, auf dem der Pod ausgeführt wird, ist unter „ EIT_ENABLED_WORKER_POOLS “ nicht aufgeführt.
  • Auf den RHCOS-Arbeitsknoten sind die EIT-Pakete zwar installiert, der Knoten wurde jedoch noch nicht neu gestartet, um sie zu aktivieren.
  • Auf den RHCOS-Arbeitsknoten wurde zuvor ein Deinstallations- und Neuinstallationszyklus ohne dazwischenliegenden Neustart durchgeführt, wodurch das Paket in einem fehlerhaften „bereits in die Layer integrierten“ Zustand verblieb.

Problemlösung

Führen Sie die folgenden Schritte aus, um die Ursache zu ermitteln und zu beheben.

Prüfen, bei welchen Knoten EIT aktiviert ist

Überprüfen Sie die Configmap „ file-csi-driver-status “, um festzustellen, auf welchen Knoten EIT-Pakete installiert sind, und vergewissern Sie sich, dass die Konfiguration korrekt ist.

  1. Beschreiben Sie die Status-Configmap, um zu sehen, auf welchen Knoten EIT aktiviert ist. Suchen Sie nach dem Schlüssel „ EIT_ENABLED_WORKER_NODES “, in dem die Namen der Worker-Pools und die IP-Adressen der Knoten aufgeführt sind, auf denen die EIT-Installation abgeschlossen ist.

    oc describe cm file-csi-driver-status -n kube-system

    Beispielausgabe:

    EIT_ENABLED_WORKER_NODES:
----
default:
- 10.240.0.89
- 10.240.0.87
- 10.240.0.88

    Ein leerer Wert bedeutet, dass auf noch keinem Knoten EIT installiert wurde.

  2. Stellen Sie sicher, dass unter „ ENABLE_EIT “ die Option „ true “ ausgewählt ist und dass der Ziel-Worker-Pool unter „ EIT_ENABLED_WORKER_POOLS “ aufgeführt ist.

    oc describe cm addon-vpc-file-csi-driver-configmap -n kube-system

Stellen Sie sicher, dass Ihr App-Pod auf einem EIT-fähigen Knoten ausgeführt wird

Listen Sie Ihre Pods auf, um herauszufinden, auf welchem Knoten sie eingeplant sind, und vergleichen Sie die Ergebnisse dann mit der Liste aus dem vorherigen Abschnitt.

  1. Listen Sie Ihre Pods auf und notieren Sie sich die IP-Adresse des Knotens, auf dem der jeweilige Pod ausgeführt wird.

    oc get pods -A -o wide

  2. Vergleichen Sie die IP-Adresse des Knotens mit der Liste unter EIT_ENABLED_WORKER_NODES aus Schritt 1. Befindet sich der Pod auf einem Knoten, der nicht in dieser Liste aufgeführt ist, führen Sie einen der folgenden Schritte aus:

    • Verschieben Sie den Pod mithilfe von Knotenselektoren oder Affinitätsregeln auf einen EIT-fähigen Knoten.
    • Fügen Sie den Worker-Pool, der diesen Knoten enthält, in der ConfigMap unter „ EIT_ENABLED_WORKER_POOLS “ hinzu und warten Sie, bis der Operator die Daten abgeglichen hat.

Betriebssystemspezifische Überlegungen

Die erforderlichen Pakete werden je nach Betriebssystem des Worker-Knotens unterschiedlich installiert.

Ubuntu und RHEL

Es ist kein Warmstart erforderlich. Die Pakete werden unmittelbar nach der Installation aktiviert. Wenn die IP-Adresse des Knotens unter EIT_ENABLED_WORKER_NODES angezeigt wird und sich der Pod auf diesem Knoten befindet, sollte EIT funktionieren. Sollte der Socket weiterhin fehlen, überprüfen Sie die Pod-Protokolle des Speicherbetreibers auf Installationsfehler.

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

RHCOS / CoreOS

RHCOS ist ein unveränderliches Betriebssystem. Die Pakete sind erst nach einem Neustart des Knotens aktiv, auch wenn die IP-Adresse des Knotens bereits unter EIT_ENABLED_WORKER_NODES aufgeführt ist.

Node Wird als EIT-fähig angezeigt, aber das Einbinden schlägt dennoch fehl

Wenn die IP-Adresse des Knotens unter „ EIT_ENABLED_WORKER_NODES “ aufgeführt ist, Sie aber dennoch die Fehlermeldung „ UnresponsiveMountHelperContainerUtility “ erhalten, wurde der Knoten seit der Installation der Pakete nicht neu gestartet. Der Socket „ /var/lib/ibmshare.sock “ existiert erst nach einem Neustart.

Um zu überprüfen, ob ein Neustart ansteht, führen Sie auf dem betroffenen Knoten die folgenden Befehle aus:

  1. Öffnen Sie auf dem betroffenen Knoten mithilfe der CLI „ OpenShift “ eine Debug-Shell.

    oc debug node/<nodeName>

  2. Überprüfen Sie in der Debug-Shell, ob EIT-Pakete bereitgestellt, aber noch nicht aktiv sind.

    chroot /host
rpm-ostree status

    Suchen Sie in der Ausgabe nach einer ausstehenden oder in der Warteschlange befindlichen Ebene, in der „ mount-helper “ und „ mount-helper-container “ aufgeführt sind. Wenn die Pakete in einer Ebene erscheinen, die nicht mit „ (booted) “ gekennzeichnet ist, ist ein Neustart erforderlich, um sie zu aktivieren.

    Beispielausgabe, die die für den nächsten Systemstart vorbereiteten Pakete anzeigt:

    State: idle
Deployments:
  ● ostree-unverified-registry:...
    ...
    LayeredPackages: mount-helper mount-helper-container
  ostree-unverified-registry:...  (booted)
    ...

Um dieses Problem zu beheben, entleeren Sie den betroffenen RHCOS-Knoten und starten Sie ihn neu, um Auswirkungen auf laufende Workloads zu vermeiden.

  1. Ermitteln Sie die Worker-IDs der unter EIT_ENABLED_WORKER_NODES aufgeführten Knoten, indem Sie deren IP-Adressen abgleichen.

    ibmcloud ks workers --cluster CLUSTER_ID

  2. Entleeren Sie den Knoten, um alle laufenden Pods vor dem Neustart sicher zu beenden.

    oc drain <node-name> --ignore-daemonsets --delete-emptydir-data

  3. Starten Sie den heruntergefahrenen Knoten neu.

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

  4. Sobald der Knoten wieder online ist und sich im Status „ Ready “ befindet, heben Sie die Sperre auf, damit darauf wieder Workloads eingeplant werden können.

    oc uncordon <node-name>

Die Installation schlägt unter RHCOS mit der Fehlermeldung „bereits in Ebenen angeordnet“ fehl

Wenn Sie EIT zuvor in einem RHCOS-Worker-Pool deinstalliert und anschließend wieder aktiviert haben, ohne den Knoten zwischendurch neu zu starten, schlägt der Installationsauftrag des Speicheroperators möglicherweise mit einer Fehlermeldung ab, die in etwa wie folgt lautet:

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

Das liegt daran, dass „ rpm-ostree uninstall “ die Entfernung lediglich vorbereitet. Die Pakete bleiben bis zum nächsten Neustart in der aktuellen Boot-Ebene vorhanden. Wenn der Benutzer versucht, „ rpm-ostree install “ erneut auszuführen, werden die Pakete als bereits installiert angezeigt.

So beheben Sie das Problem:

  1. Entleeren Sie den Knoten, um alle laufenden Pods vor dem Neustart sicher zu beenden.

    oc drain <node-name> --ignore-daemonsets --delete-emptydir-data

  2. Starten Sie den RHCOS-Knoten neu, um die ausstehende Deinstallation durchzuführen.

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

  3. Sobald der Knoten wieder online ist und sich im Status „ Ready “ befindet, heben Sie die Sperre auf, damit darauf wieder Workloads eingeplant werden können.

    oc uncordon <node-name>

  4. Nachdem der Knoten wieder online ist, sind die zuvor installierten Pakete nicht mehr vorhanden. Der Speicherbetreiber installiert sie im nächsten Abgleichzyklus automatisch wieder, in der Regel innerhalb weniger Minuten.

  5. Nachdem der Betreiber den Knoten unter „ EIT_ENABLED_WORKER_NODES “ als EIT-fähig gemeldet hat, führen Sie ein „Drain“ durch und starten Sie den Knoten erneut, um die neu installierten Pakete zu aktivieren. Heben Sie anschließend die Sperre auf.

Der vollständige Ablauf für die Deinstallation und anschließende Neuinstallation von RHCOS lautet: Neustart nach der Deinstallation → Neuinstallation durch den Betreiber → erneuter Neustart zur Aktivierung.

Neue Knoten wurden zu einem EIT-fähigen Worker-Pool hinzugefügt

Wenn ein neuer Knoten einem Worker-Pool beitritt, der bereits unter EIT_ENABLED_WORKER_POOLS aufgeführt ist, installiert der Speicherbetreiber während des nächsten Abgleichzyklus automatisch EIT-Pakete auf dem neuen Knoten. Es ist keine Aktualisierung der ConfigMap erforderlich.

Bei RHCOS-Knoten müssen Sie den Knoten nach der Installation weiterhin leeren und neu starten, bevor EIT aktiv wird. Entleeren Sie den Knoten, starten Sie ihn neu und trennen Sie ihn anschließend vom Netzwerk, um die Auswirkungen auf laufende Workloads zu minimieren. Solange der Knoten nicht neu gestartet wird, wird bei jedem Pod, der ein EIT-fähiges PVC verwendet und auf diesem neuen Knoten eingeplant ist, derselbe Fehler „ UnresponsiveMountHelperContainerUtility “ angezeigt. Ubuntu (IKS)- und RHEL-Knoten (ROKS) müssen nicht neu gestartet werden, wenn ein neuer Knoten hinzugefügt wird.