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 aufgrund fehlender Konfiguration 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 (Azure Container Storage) 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>
Azure Container Storage kann aufgrund von Einschränkungen durch die Azure Policy nicht installiert werden
Azure Container Storage kann nicht installiert werden, wenn Einschränkungen durch die Azure Policy vorhanden sind. Insbesondere basiert Azure Container Storage auf privilegierten Containern. Sie können Azure Policy so konfigurieren, dass privilegierte Container blockiert werden. Wenn sie blockiert sind, könnte die Installation von Azure Container Storage abbrechen wegen einer Zeitüberschreitung oder fehlschlagen, und es werden möglicherweise Fehler in den gatekeeper-controller-Protokollen angezeigt, z. B.:
$ kubectl logs -n gatekeeper-system deployment/gatekeeper-controller
...
{"level":"info","ts":1722622443.9484184,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: prereq, securityContext: {\"privileged\": true, \"runAsUser\": 0}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-prereq-gt58x","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622443.9839077,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: metrics-exporter, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-metrics-exporter-286np","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0515249,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: csi-node, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-csi-node-7hcd7","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0729053,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: io-engine, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-io-engine-84hwx","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0742755,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-x6q5n","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622449.2412128,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-b5nfg","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
Um die Blockierung zu beheben, müssen Sie den acstor-Namespace zur Ausschlussliste Ihrer Azure Policy hinzufügen. Azure Policy wird verwendet, um Regeln für die Verwaltung von Ressourcen in Azure zu erstellen und zu erzwingen, einschließlich AKS-Clustern. In einigen Fällen können Richtlinien die Erstellung von Azure Container Storage-Pods und -Komponenten blockieren. Weitere Details zum Arbeiten mit Azure Policy for Kubernetes finden Sie unter Azure Policy für Kubernetes.
Führen Sie die folgenden Schritte aus, um den acstor-Namespace zur Ausschlussliste hinzuzufügen:
- Erstellen Sie Ihr Azure Kubernetes-Cluster.
- Aktivieren Sie Azure Policy für AKS.
- Erstellen Sie eine Richtlinie, von der Sie vermuten, dass sie die Installation von Azure Container Storage blockiert.
- Versuchen Sie, Azure Container Storage im AKS-Cluster zu installieren.
- Überprüfen Sie die Protokolle für den Gatekeeper-Controller-Pod, um alle Richtlinienverletzungen zu bestätigen.
- Fügen Sie den
acstor-Namespace und denazure-extensions-usage-system-Namespace zur Ausschlussliste der Richtlinie hinzu. - Versuchen Sie erneut, Azure Container Storage im AKS-Cluster zu installieren.
Azure Container Storage kann nicht in Knotenpools mit Taints installiert und aktiviert werden
Sie können Knotentaints in den Knotenpools konfigurieren, um die Planung von Pods in diesen Knotenpools einzuschränken. Das Installieren und Aktivieren von Azure Container Storage in diesen Knotenpools kann blockiert werden, da die erforderlichen Pods in diesen Knotenpools nicht erstellt werden können. Das Verhalten gilt sowohl für den Systemknotenpool beim Installieren als auch für die Benutzerknotenpools beim Aktivieren.
Sie können die Knotentaints mit dem folgenden Beispiel überprüfen:
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": [
"sku=gpu:NoSchedule"
]
}
]
Sie können diese Taints vorübergehend entfernen, um die Blockierung aufzuheben und nach der Installation wieder zu konfigurieren und erfolgreich zu aktivieren. Sie können zum Azure-Portal > AKS-Cluster > Knotenpools gehen, auf Ihren Knotenpool klicken und die Makel im Abschnitt „Makel und Labels“ entfernen. Oder Sie können den folgenden Befehl verwenden, um Taints zu entfernen und die Änderung zu bestätigen.
$ az aks nodepool update -g $resourceGroup --cluster-name $clusterName --name $nodePoolName --node-taints ""
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": null
}
]
Wiederholen Sie die Installation oder Aktivierung, nachdem Sie die Knotentaints erfolgreich entfernt haben. Nach erfolgreichem Abschluss können Sie die Knotentaints zurücksetzen, um die Podplanungsbeschränkungen wieder aufzunehmen.
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.
Der Pool für die kurzzeitige Speicherung beansprucht die Kapazität nicht, wenn die kurzzeitigen Festplatten von anderen Daemonsets verwendet werden
Wenn ein kurzlebiger Speicherpool auf einem Knotenpool mit temporären SSD- oder lokalen NVMe-Festplatten aktiviert wird, wird möglicherweise keine Kapazität von diesen Festplatten beansprucht, wenn andere Daemonsets diese verwenden.
Führen Sie die folgenden Schritte aus, damit Azure Container Storage diese lokalen Datenträger ausschließlich verwalten kann:
Führen Sie den folgenden Befehl aus, um die beanspruchte Kapazität nach kurzzeitigem Speicherpool anzuzeigen:
$ kubectl get sp -A NAMESPACE NAME CAPACITY AVAILABLE USED RESERVED READY AGE acstor ephemeraldisk-nvme 0 0 0 0 False 82sDieses Beispiel zeigt null Kapazität, die vom
ephemeraldisk-nvme-Speicherpool beansprucht wird.Führen Sie den folgenden Befehl aus, um den nicht beanspruchten Status dieser lokalen Blockgeräte zu bestätigen und das vorhandene Dateisystem auf den Festplatten zu überprüfen:
$ kubectl get bd -A NAMESPACE NAME NODENAME SIZE CLAIMSTATE STATUS AGE acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff aks-nodepoolnvme-38618677-vmss000001 1920383410176 Unclaimed Active 22m acstor blockdevice-9c8096fc47cc2b41a2ed07ec17a83527 aks-nodepoolnvme-38618677-vmss000000 1920383410176 Unclaimed Active 23m $ kubectl describe bd -n acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff Name: blockdevice-1f7ad8fa32a448eb9768ad8e261312ff … Filesystem: Fs Type: ext4 …Dieses Beispiel zeigt, dass die Blockgeräte den Status
Unclaimedhaben und dass auf der Festplatte ein Dateisystem vorhanden ist.Bestätigen Sie, dass Sie ausschließlich Azure Container Storage zum Verwalten der lokalen Datenträger verwenden möchten, bevor Sie fortfahren.
Stoppen Sie die Daemonsets oder Komponenten, die lokale Datenträger verwalten, und entfernen Sie sie.
Melden Sie sich bei jedem Knoten an, der lokale Datenträger hat.
Entfernen Sie vorhandene Dateisysteme von allen lokalen Datenträgern.
Starten Sie ndm daemonset neu, um nicht verwendete lokale Datenträger zu ermitteln.
$ kubectl rollout restart daemonset -l app=ndm -n acstor daemonset.apps/azurecontainerstorage-ndm restarted $ kubectl rollout status daemonset -l app=ndm -n acstor --watch … daemon set "azurecontainerstorage-ndm" successfully rolled outWarten Sie einige Sekunden und überprüfen Sie, ob der kurzlebige Speicherpool die Kapazität von lokalen Datenträgern beansprucht.
$ kubectl wait -n acstor sp --all --for condition=ready storagepool.containerstorage.azure.com/ephemeraldisk-nvme condition met $ kubectl get bd -A NAMESPACE NAME NODENAME SIZE CLAIMSTATE STATUS AGE acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff aks-nodepoolnvme-38618677-vmss000001 1920383410176 Claimed Active 4d16h acstor blockdevice-9c8096fc47cc2b41a2ed07ec17a83527 aks-nodepoolnvme-38618677-vmss000000 1920383410176 Claimed Active 4d16h $ kubectl get sp -A NAMESPACE NAME CAPACITY AVAILABLE USED RESERVED READY AGE acstor ephemeraldisk-nvme 3840766820352 3812058578944 28708241408 26832871424 True 4d16hDieses Beispiel zeigt, dass der
ephemeraldisk-nvme- Speicherpool die Kapazität von lokalen NVMe-Datenträgern auf den Knoten erfolgreich beansprucht.
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, über die Grenze hinaus zu erweitern, zeigt das interne PVC eine Fehlermeldung über die Beschränkungen der Festplattengröße oder des Caching-Typs an. 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 vorhandenen 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.
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 könnte eine Ausgabe angezeigt werden, 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 ausgeführt werden, wird die Lautstärke nicht angehängt, da der Metadatenspeicher offline ist und die automatische Wiederherstellung fehlgeschlagen ist. Falls ja, öffnen Sie ein Supportticket beim Azure-Support.