Beheben bekannter Probleme und Fehler beim Verwalten von Speicher in AKS Arc

Dieser Fehler bezüglich verweigerter Berechtigung gibt an, dass die Standardspeicherklasse möglicherweise nicht für Ihre Workloads geeignet ist. Er tritt bei Linux-Workloads auf, die unter einer Kubernetes-Version ab 1.19.x ausgeführt werden. Gemäß der bewährten Sicherheitsmethoden geben viele Linux-Workloads die securityContext fsGroup Einstellung für einen Pod an. Die Workloads können nicht auf AKS auf Azure Local gestartet werden, da die Standardspeicherklasse den fstype (=ext4) Parameter nicht angibt, sodass Kubernetes den Besitz von Dateien und persistenten Volumes basierend auf der fsGroup angeforderten Workload nicht ändern kann.

Um dieses Problem zu beheben, müssen Sie eine benutzerdefinierte Speicherklasse definieren, die Sie zum Bereitstellen von PVCs verwenden können.

Ein neuer Kubernetes-Workloadcluster wurde mit Kubernetes Version 1.16.10 erstellt und dann auf 1.16.15 aktualisiert. Nach der Aktualisierung befand sich der csi-msk8scsi-node-9x47m-Pod im Zustand ContainerCreating, und der kube-proxy-qqnkr-Pod war im Zustand Wird beendet hängen geblieben, wie in der folgenden Ausgabe gezeigt:

Error: kubectl.exe get nodes  
NAME              STATUS     ROLES    AGE     VERSION 
moc-lf22jcmu045   Ready      <none>   5h40m   v1.16.15 
moc-lqjzhhsuo42   Ready      <none>   5h38m   v1.16.15 
moc-lwan4ro72he   NotReady   master   5h44m   v1.16.15

\kubectl.exe get pods -A 

NAMESPACE     NAME                        READY   STATUS              RESTARTS   AGE 
    5h38m 
kube-system   csi-msk8scsi-node-9x47m     0/3     ContainerCreating   0          5h44m 
kube-system   kube-proxy-qqnkr            1/1     Terminating         0          5h44m  

Da kubelet in einem fehlerhaften Zustand beendet wurde und nicht mehr mit dem API-Server kommunizieren kann, besteht die einzige Lösung darin, den kubelet-Dienst neu zu starten. Nach dem Neustart wechselt der Cluster in den Status Wird ausgeführt.

Der Datenträgerspeicher kann aus absturzabbildigen Protokollen gefüllt werden, die erstellt werden. Dies ist auf ein abgelaufenes Geneva-Agent-Clientzertifikat zurückzuführen. Die Symptome können wie folgt aussehen:

• Dienste können nicht gestartet werden.
• Kubernetes-Pods, Bereitstellungen usw. können aufgrund unzureichender Ressourcen nicht gestartet werden.

Dieses Problem kann sich auf jeden Vorgang auswirken, der das Zuordnen von Speicherplatz oder das Schreiben neuer Dateien umfasst, sodass jeder Fehler "unzureichender Speicherplatz/Ressourcen" ein guter Hinweis ist. Um zu überprüfen, ob dieses Problem auf einem bestimmten Knoten vorhanden ist, führen Sie den folgenden Shellbefehl aus:

clouduser@moc-lwm2oudnskl $ sudo du -h /var/lib/systemd/coredump/

Dieser Befehl meldet den von den Diagnosedateien verbrauchten Speicherplatz.

Grundursache

Der Ablauf des Clientzertifikats, das zum Authentifizieren des Genfer Agents beim Dienstendpunkt verwendet wird, führt dazu, dass der Agent abstürzt, was zu einem Absturzabbild führt. Die Absturz-/Wiederholungsschleife des Agents beträgt etwa 5 Sekunden beim ersten Start, und es gibt kein Timeout. Dies bedeutet, dass alle paar Sekunden eine neue Datei (ca. 330 MB) auf dem Dateisystem des Knotens erstellt wird, was den Datenträgerspeicher schnell verbrauchen kann.

Abmilderung

Die bevorzugte Gegenmaßnahme besteht darin, ein Upgrade auf die neueste Version, Version 1.10.18.10425, durchzuführen, die über ein aktualisiertes Zertifikat verfügt. Führen Sie dazu zuerst ein manuelles Upgrade Ihrer Workloadcluster auf jede unterstützte Nebenversion durch, bevor Sie Ihren lokalen Azure-Host aktualisieren.

For more information about AKS Arc releases, and all the latest AKS on Azure Local news, subscribe to the AKS releases page.

Wenn das Upgrade keine Option ist, können Sie den mdsd-Dienst deaktivieren. Für jeden Mariner-Knoten:

1. Deaktivieren Sie den Genfer Agent mit den folgenden Shellbefehlen:

   sudo systemctl disable --now mdsd
   

2. Überprüfen Sie, ob der Genfer Agent erfolgreich deaktiviert wurde:

   sudo systemctl status mdsd
   

3. Löschen Sie gesammelte Dateien mit dem folgenden Befehl:

   sudo find /var/lib/systemd/coredump/ -type f -mmin +1 -exec rm -f {} \;
   sudo find /run/systemd/propagate -name 'systemd-coredump@*' -delete
   sudo journalctl --rotate && sudo journalctl --vacuum-size=500M
   

4. Starten Sie den Knoten neu:

   sudo reboot
   

Wenn Sie einen SMB- oder NFS-CSI-Treiber in Ihrer Bereitstellung installiert haben und ein Upgrade auf den Mai-Build von einer älteren Version durchführen, kann ein Fehler auftreten. Einer der Parameter, der aufgerufen createSubDirwird, wird nicht mehr akzeptiert. Wenn dies für Ihre Bereitstellung gilt, befolgen Sie die nachstehenden Anweisungen, um den Speicherklassenfehler zu beheben.

Wenn dieser Fehler auftritt, stürzt der Speicher pod ab, und die Protokolle geben an, dass der createSubDir Parameter ungültig ist.

Erstellen Sie die Speicherklasse neu.

Nach dem Löschen eines persistenten Volumes oder eines persistenten Volumeanspruchs in einer AKS Arc-Umgebung wird ein neues persistentes Volume erstellt, um derselben Freigabe zuzuordnen. Das Volume kann jedoch nicht erfolgreich eingebunden werden, und für den Pod kommt es zu einem Timeout mit dem Fehler NewSmbGlobalMapping failed.

Zur Umgehung des Fehlers beim Einbinden des neuen Volumes können Sie eine SSH-Verbindung mit dem Windows-Knoten herstellen, Remove-SMBGlobalMapping ausführen und die Freigabe bereitstellen, die dem Volume entspricht. Nach der Ausführung dieses Befehls sollte das Volume erfolgreich eingebunden werden können.

Nächste Schritte

• Problembehandlung: Übersicht, Feedback und Support
• Bekannte Probleme mit Windows Admin Center