Problembehandlung für Azure Container Storage
Azure Container Storage ist ein cloudbasierter Dienst zum Verwalten, Bereitstellen und Orchestrieren von Volumes, der nativ für Container entwickelt wurde. Verwenden Sie diesen Artikel, um häufige Probleme mit Azure Container Storage zu beheben und Lösungen für Probleme zu finden.
Behandlung von Installationsproblemen
Azure Container Storage kann nicht installiert werden
Nach dem Ausführen von az aks create wird möglicherweise die folgende Meldung angezeigt: Azure Container Storage konnte nicht installiert werden. Der AKS-Cluster wird erstellt. Führen Sie az aks update zusammen mit --enable-azure-container-storage aus, um Azure Container Storage zu aktivieren.
Diese Meldung bedeutet, dass Azure Container Storage nicht installiert wurde, aber Ihr AKS-Cluster wurde ordnungsgemäß erstellt.
Führen Sie den folgenden Befehl aus, um Azure Container Storage im Cluster zu installieren und einen Speicherpool zu erstellen. Ersetzen Sie <cluster-name> und <resource-group> durch Ihre eigenen Werte. Ersetze <storage-pool-type> durch azureDisk, ephemeraldisk oder elasticSan.
az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>
Speicherpooltyp kann nicht auf NVMe festgelegt werden
Wenn Sie versuchen, Azure Container Storage mit kurzlebigem Datenträger zu installieren, insbesondere mit lokalem NVMe auf einem Cluster, in dem die VM-SKU keine NVMe-Laufwerke aufweist, erhalten Sie die folgende Fehlermeldung: --storage-pool-option kann nicht als NVMe festgelegt werden, da keiner der Knotenpools kurzlebige NVMe-Datenträger unterstützt.
Um das Problem zu beheben, erstellen Sie einen Knotenpool mit einer VM-SKU mit NVMe-Laufwerken, und versuchen Sie es erneut. Informationen finden Sie unter Datenspeicheroptimierte VMs.
Behandeln von Problemen mit Speicherpools
Führen Sie kubectl describe sp <storage-pool-name> -n acstor aus, um den Status Ihrer Speicherpools zu überprüfen. Hier sind einige Probleme, die auftreten können.
Fehler beim Erweitern eines Speicherpools mit Azure-Datenträgern
Wenn Ihr vorhandener Speicherpool kleiner als 4 TiB (4.096 GiB) ist, können Sie ihn nur auf bis zu 4.095 GiB erweitern. Wenn Sie versuchen, ihn darüber hinaus zu erweitern, erhält der interne PVC etwa folgende Fehlermeldungen: „Für Datenträger mit einer Größe von mehr als 4.095 GB wird nur der CachingType "None" unterstützt.“ oder „Der Datenträger "xxx“ mit einer Größe von 4.096 GB (<=4096 GB) kann nicht auf 16384 GB (>4096 GB) geändert, während er an einen ausgeführten virtuellen Computer angefügt ist. Beenden Sie Ihren virtuellen Computer, oder trennen Sie den Datenträger, und wiederholen Sie den Vorgang.
Um Fehler zu vermeiden, versuchen Sie nicht, den aktuellen Speicherpool auf mehr als 4.095 GiB zu erweitern, wenn er anfänglich kleiner als 4 TiB ist (4.096 GiB). Speicherpools, die größer als 4 TiB sind, können bis auf die maximal verfügbare Speicherkapazität erweitert werden.
Diese Einschränkung gilt nur bei Verwendung der Datenträger-SKUs Premium_LRS, Standard_LRS, StandardSSD_LRS, Premium_ZRS und StandardSSD_ZRS.
Die Elastic SAN-Erstellung schlägt fehl
Wenn Sie versuchen, einen Elastic SAN-Speicherpool zu erstellen, wird möglicherweise die folgende Meldung angezeigt: Azure Elastic SAN-Erstellung fehlgeschlagen: Maximale Elastic SAN-Anzahl für das Abonnement bereits erstellt. Dies bedeutet, dass Sie den Grenzwert für die Anzahl der Elastic SAN-Ressourcen erreicht haben, die in einer Region pro Abonnement bereitgestellt werden können. Sie können hier den Grenzwert überprüfen: Elastic SAN: Skalierbarkeit und Leistungsziele. Erwägen Sie das Löschen vorhandener Elastic SAN-Ressourcen im Abonnement, die nicht mehr verwendet werden, oder versuchen Sie, den Speicherpool in einer anderen Region zu erstellen.
Keine Blockgeräte gefunden
Wenn diese Meldung angezeigt wird, versuchen Sie wahrscheinlich, einen kurzlebigen Datenträgerspeicherpool in einem Cluster zu erstellen, in dem die VM-SKU keine NVMe-Laufwerke hat.
Um das Problem zu beheben, erstellen Sie einen Knotenpool mit einer VM-SKU mit NVMe-Laufwerken, und versuchen Sie es erneut. Informationen finden Sie unter Datenspeicheroptimierte VMs.
Speicherpooltyp bereits aktiviert
Wenn Sie versuchen, einen bereits aktivierten Speicherpooltyp zu aktivieren, wird die folgende Meldung angezeigt: Ungültiger --enable-azure-container-storage-Wert. Azure Container Storage ist bereits für den Speicherpooltyp <storage-pool-type> im Cluster aktiviert. Sie können überprüfen, ob bereits Speicherpools vorhanden sind, indem Sie kubectl get sp -n acstor ausführen.
Deaktivieren eines Speicherpooltyps
Wenn Sie einen Speicherpooltyp über az aks update --disable-azure-container-storage <storage-pool-type> deaktivieren oder Azure Container Storage über az aks update --disable-azure-container-storage all deinstallieren, erhalten Sie die folgende Meldung, wenn bereits ein Speicherpool dieses Typs vorhanden ist:
Wenn Sie Azure Container Storage für den Speicherpooltyp deaktivieren, erzwingt <storage-pool-type> die Löschung aller Speicherpools desselben Typs. Das wirkt auf die Anwendungen aus, die diese Speicherpools verwenden. Das erzwungene Löschen von Speicherpools kann auch zu Speicherverlust bei den verwendeten Ressourcen führen. Möchten Sie überprüfen, ob einer der Speicherpools vom Typ <storage-pool-type> verwendet wird, bevor Azure Container Storage deaktiviert wird? (J/N)
Wenn Sie „J“ auswählen, wird eine automatische Prüfung ausgeführt, um sicherzustellen, dass im Speicherpool keine persistenten Volumes erstellt werden. Wenn Sie „N“ auswählen, wird diese Prüfung umgangen und der Speicherpooltyp deaktiviert, alle vorhandenen Speicherpools gelöscht. Dadurch wird Ihre Anwendung potenziell beeinträchtigt.
Ressourcengruppe mit AKS-Cluster kann nicht gelöscht werden
Wenn Sie einen Elastic SAN-Speicherpool erstellt haben, können Sie die Ressourcengruppe, in der sich Ihr AKS-Cluster befindet, möglicherweise nicht löschen.
Um dieses Problem zu beheben, melden Sie sich beim Azure-Portal an, und klicken Sie auf Ressourcengruppen. Suchen Sie die von AKS erstellte Ressourcengruppe (der Ressourcengruppenname beginnt mit MC_). Wählen Sie das SAN-Ressourcenobjekt innerhalb dieser Ressourcengruppe aus. Entfernen Sie manuell alle Volumes und Volumegruppen. Versuchen Sie dann erneut, die Ressourcengruppe zu löschen, die Ihren AKS-Cluster enthält.
Beheben von Volumeproblemen
Pod mit ausstehender Erstellung wegen eines kurzlebigen Volumes größer als die verfügbare Kapazität
Ein kurzlebiges Volume wird einem einzelnen Knoten zugewiesen. Wenn Sie die Größe von kurzlebigen Volumes für Ihre Pods konfigurieren, sollte die Größe kleiner als die verfügbare Kapazität des kurzlebigen Datenträgers eines einzelnen Knotens sein. Andernfalls befindet sich die Poderstellung im Status „Ausstehend“.
Verwenden Sie den folgenden Befehl, um zu überprüfen, ob sich die Poderstellung im Status „Ausstehend“ befindet.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
fiopod 0/1 Pending 0 17s
In diesem Beispiel befindet sich der Pod fiopod im Pending-Status.
Verwenden Sie den folgenden Befehl, um zu überprüfen, ob das Warnereignis für die persistente Erstellung des Pods vorhanden ist.
$ kubectl describe pod fiopod
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 40s default-scheduler 0/3 nodes are available: waiting for ephemeral volume controller to create the persistentvolumeclaim "fiopod-ephemeralvolume". preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling..
In diesem Beispiel zeigt der Pod das Warnereignis zum Erstellen eines dauerhaften Volumeanspruchs fiopod-ephemeralvolume.
Verwenden Sie den folgenden Befehl, um zu überprüfen, ob der persistente Volumeanspruch aufgrund unzureichender Kapazität nicht bereitgestellt werden kann.
$ kubectl describe pvc fiopod-ephemeralvolume
...
Warning ProvisioningFailed 107s (x13 over 20m) containerstorage.csi.azure.com_aks-nodepool1-29463073-vmss000000_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx failed to provision volume with StorageClass "acstor-ephemeraldisk-temp": rpc error: code = Internal desc = Operation failed: GenericOperation("error in response: status code '507 Insufficient Storage', content: 'RestJsonError { details: \"Operation failed due to insufficient resources: Not enough suitable pools available, 0/1\", message: \"SvcError :: NotEnoughResources\", kind: ResourceExhausted }'")
In dem Beispiel wird Insufficient Storage als Grund für Volumenbereitstellungsfehler dargestellt.
Führen Sie den folgenden Befehl aus, um die verfügbare Kapazität des kurzlebigen Datenträgers eines einzelnen Knotens zu überprüfen.
$ kubectl get diskpool -n acstor
NAME CAPACITY AVAILABLE USED RESERVED READY AGE
ephemeraldisk-temp-diskpool-jaxwb 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-wzixx 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-xbtlj 75660001280 75031990272 628011008 560902144 True 21h
In diesem Beispiel ist die verfügbare Kapazität des temporären Datenträgers für einen einzelnen Knoten 75031990272 Byte oder 69 GiB.
Passen Sie die Volumespeichergröße unter der verfügbaren Kapazität an und stellen Sie Ihren Pod erneut bereit. Siehe unter Bereitstellen eines Pods mit einem generischen kurzlebigen Volume.
Das Volume kann nicht angefügt werden, weil der Metadatenspeicher offline ist.
Azure Container Storage verwendet etcd, einen verteilten, zuverlässigen Schlüsselwertspeicher, um Metadaten von Volumes zu speichern und zu verwalten und dadurch Volumeorchestrierungsvorgänge zu unterstützen. etcd wird in drei Pods ausgeführt, um Hochverfügbarkeit und Resilienz zu gewährleisten. Wenn weniger als zwei etcd-Instanzen ausgeführt werden, hält Azure Container Storage Volumeorchestrierungsvorgänge an, ermöglicht aber gleichzeitig den Datenzugriff auf die Volumes. Azure Container Storage erkennt automatisch, wenn eine etcd-Instanz offline ist, und stellt sie wieder her. Wenn Sie jedoch nach dem Neustart eines AKS-Clusters Volumeorchestrierungsfehler feststellen, ist es möglich, dass eine etcd-Instanz nicht automatisch wiederhergestellt werden konnte. Befolgen Sie die Anweisungen in diesem Abschnitt, um den Integritätsstatus der etcd-Instanzen zu ermitteln.
Führen Sie den folgenden Befehl aus, um eine Liste der Pods abzurufen.
kubectl get pods
Daraufhin wird eine Ausgabe angezeigt, die in etwa wie folgt aussieht.
NAME READY STATUS RESTARTS AGE
fiopod 0/1 ContainerCreating 0 25m
Beschreiben Sie den Pod:
kubectl describe pod fiopod
In der Regel werden Volumefehlermeldungen angezeigt, wenn der Metadatenspeicher offline ist. In diesem Beispiel hat fiopod den Status ContainerCreating, und die Warnung FailedAttachVolume gibt an, dass die Erstellung aufgrund eines Volumeanfügefehlers aussteht.
Name: fiopod
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25m default-scheduler Successfully assigned default/fiopod to aks-nodepool1-xxxxxxxx-vmss000009
Warning FailedAttachVolume 3m8s (x6 over 23m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" : timed out waiting for external-attacher of containerstorage.csi.azure.com CSI driver to attach volume xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Sie können auch den folgenden Befehl ausführen, um den Status der etcd-Instanzen zu überprüfen:
kubectl get pods -n acstor | grep "^etcd"
Die Ausgabe sollte ähnlich wie folgt aussehen, wobei alle Instanzen den Zustand „Wird ausgeführt“ haben:
etcd-azurecontainerstorage-bn89qvzvzv 1/1 Running 0 4d19h
etcd-azurecontainerstorage-phf92lmqml 1/1 Running 0 4d19h
etcd-azurecontainerstorage-xznvwcgq4p 1/1 Running 0 4d19h
Wenn weniger als zwei Instanzen den Zustand „Wird ausgeführt“ haben, können Sie daraus schließen, dass das Volume nicht angefügt werden kann, weil der Metadatenspeicher offline ist, und dass die automatische Wiederherstellung nicht erfolgreich war. Erstellen Sie in diesem Fall ein Supportticket beim Azure-Support.