Udostępnij za pośrednictwem


Rozwiązywanie problemów z usługą Azure Container Storage

Usługa Azure Container Storage to oparta na chmurze usługa zarządzania woluminami, wdrażania i orkiestracji wbudowana natywnie dla kontenerów. Skorzystaj z tego artykułu, aby rozwiązać typowe problemy z usługą Azure Container Storage i znaleźć rozwiązania problemów.

Rozwiązywanie problemów z instalacją

Nie można zainstalować usługi Azure Container Storage z powodu braku konfiguracji

Po uruchomieniu az aks createpolecenia może zostać wyświetlony komunikat Nie można zainstalować usługi Azure Container Storage. Klaster usługi AKS jest tworzony. Uruchom polecenie az aks update wraz z poleceniem --enable-azure-container-storage , aby włączyć usługę Azure Container Storage.

Ten komunikat oznacza, że usługa Azure Container Storage nie została zainstalowana, ale klaster usługi AKS (Azure Kubernetes Service) został prawidłowo utworzony.

Aby zainstalować usługę Azure Container Storage w klastrze i utworzyć pulę magazynów, uruchom następujące polecenie. Zastąp <cluster-name> wartości i <resource-group> własnymi wartościami. Zastąp ciąg <storage-pool-type> ciągiem azureDisk, ephemeraldisklub elasticSan.

az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>

Nie można zainstalować usługi Azure Container Storage z powodu ograniczeń usługi Azure Policy

Instalacja usługi Azure Container Storage może zakończyć się niepowodzeniem, jeśli obowiązują ograniczenia usługi Azure Policy. W szczególności usługa Azure Container Storage opiera się na kontenerach uprzywilejowanych. Usługę Azure Policy można skonfigurować tak, aby blokowała kontenery uprzywilejowane. Po zablokowaniu instalacja usługi Azure Container Storage może upłynął lub zakończyć się niepowodzeniem i mogą wystąpić błędy w gatekeeper-controller dziennikach, takie jak:

$ 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"}

Aby rozwiązać problem z blokowaniem, należy dodać acstor przestrzeń nazw do listy wykluczeń usługi Azure Policy. Usługa Azure Policy służy do tworzenia i wymuszania reguł zarządzania zasobami na platformie Azure, w tym klastrów usługi AKS. W niektórych przypadkach zasady mogą blokować tworzenie zasobników i składników usługi Azure Container Storage. Aby uzyskać więcej informacji na temat pracy z usługą Azure Policy dla platformy Kubernetes, zapoznaj się z usługą Azure Policy dla platformy Kubernetes.

Aby dodać acstor przestrzeń nazw do listy wykluczeń, wykonaj następujące kroki:

  1. Utwórz klaster usługi Azure Kubernetes.
  2. Włącz usługę Azure Policy dla usługi AKS.
  3. Utwórz podejrzane zasady blokujące instalację usługi Azure Container Storage.
  4. Spróbuj zainstalować usługę Azure Container Storage w klastrze usługi AKS.
  5. Sprawdź dzienniki zasobnika kontrolera gatekeeper, aby potwierdzić wszelkie naruszenia zasad.
  6. acstor Dodaj przestrzeń nazw i azure-extensions-usage-system przestrzeń nazw do listy wykluczeń zasad.
  7. Spróbuj ponownie zainstalować usługę Azure Container Storage w klastrze usługi AKS.

Nie można zainstalować i włączyć usługi Azure Container Storage w pulach węzłów z defektami

Można skonfigurować defekty węzłów w pulach węzłów , aby ograniczyć planowanie zasobników w tych pulach węzłów. Instalowanie i włączanie usługi Azure Container Storage w tych pulach węzłów może być zablokowane, ponieważ nie można utworzyć wymaganych zasobników w tych pulach węzłów. Zachowanie dotyczy zarówno puli węzłów systemowych podczas instalowania, jak i pul węzłów użytkownika podczas włączania.

Możesz sprawdzić defekty węzłów przy użyciu następującego przykładu:

$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
  {
    "PoolName": "nodepoolx",
    "nodeTaints": [
      "sku=gpu:NoSchedule"
    ]
  }
]

Te defekty można tymczasowo usunąć, aby odblokować i skonfigurować je ponownie po pomyślnym zainstalowaniu i włączeniu. Możesz przejść do pul węzłów klastra > usługi AKS w witrynie Azure Portal>, kliknąć pulę węzłów, usunąć defekty w sekcji "Taints and labels". Możesz też użyć następującego polecenia, aby usunąć defekty i potwierdzić zmianę.

$ 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
  }
]

Spróbuj ponownie zainstalować lub włączyć po pomyślnym usunięciu defektów węzła. Po pomyślnym zakończeniu można skonfigurować defekty węzłów w celu wznowienia ograniczeń planowania zasobników.

Nie można ustawić typu puli magazynów na NVMe

Jeśli spróbujesz zainstalować usługę Azure Container Storage z dyskiem efemerycznym, w szczególności z lokalnym dyskiem NVMe w klastrze, w którym jednostka SKU maszyny wirtualnej nie ma dysków NVMe, zostanie wyświetlony następujący komunikat o błędzie: Nie można ustawić opcji --storage-pool-as NVMe, ponieważ żadna z pul węzłów nie może obsługiwać efemerycznego dysku NVMe.

Aby rozwiązać ten problem, utwórz pulę węzłów przy użyciu jednostki SKU maszyny wirtualnej z dyskami NVMe i spróbuj ponownie. Zobacz Maszyny wirtualne zoptymalizowane pod kątem magazynu.

Rozwiązywanie problemów z pulą magazynów

Aby sprawdzić stan pul magazynów, uruchom polecenie kubectl describe sp <storage-pool-name> -n acstor. Poniżej przedstawiono niektóre problemy, które mogą wystąpić.

Efemeryczna pula magazynów nie twierdzi pojemności, gdy dyski efemeryczne są używane przez inne demony

Włączenie efemerycznej puli magazynów w puli węzłów z dyskami SSD tymczasowymi lub lokalnymi dyskami NVMe może nie podawać pojemności z tych dysków, jeśli używają ich inne demony.

Uruchom następujące kroki, aby umożliwić usłudze Azure Container Storage zarządzanie tymi dyskami lokalnymi wyłącznie:

  1. Uruchom następujące polecenie, aby wyświetlić żądaną pojemność przez efemeryjną pulę magazynów:

    $ kubectl get sp -A
    NAMESPACE   NAME                 CAPACITY   AVAILABLE   USED   RESERVED   READY   AGE
    acstor      ephemeraldisk-nvme   0          0           0      0          False   82s
    

    W tym przykładzie pokazano zero pojemności żądanej przez ephemeraldisk-nvme pulę magazynów.

  2. Uruchom następujące polecenie, aby potwierdzić nieodebrany stan tych lokalnych urządzeń blokowych i sprawdzić istniejący system plików na dyskach:

    $ 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
    …
    

    W tym przykładzie pokazano, że urządzenia blokowe są Unclaimed stanem i istnieje istniejący system plików na dysku.

  3. Przed kontynuowaniem upewnij się, że chcesz używać usługi Azure Container Storage do zarządzania dyskami danych lokalnych wyłącznie.

  4. Zatrzymaj i usuń demony lub składniki, które zarządzają lokalnymi dyskami danych.

  5. Zaloguj się do każdego węzła z lokalnymi dyskami danych.

  6. Usuń istniejące systemy plików ze wszystkich lokalnych dysków danych.

  7. Uruchom ponownie zestaw demonów ndm, aby odnaleźć nieużywane dyski danych lokalnych.

    $ 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 out
    
  8. Zaczekaj kilka sekund i sprawdź, czy efemeryczna pula magazynów twierdzi, że pojemność z lokalnych dysków danych.

    $ 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    4d16h
    

    W tym przykładzie pokazano, że ephemeraldisk-nvme pula magazynów pomyślnie twierdzi pojemność z lokalnych dysków NVMe w węzłach.

Błąd podczas próby rozwinięcia puli magazynów usługi Azure Disks

Jeśli istniejąca pula magazynów jest mniejsza niż 4 TiB (4096 GiB), można ją rozwinąć tylko do 4095 GiB. Jeśli spróbujesz rozwinąć się poza limit, wewnętrzny PVC wyświetli komunikat o błędzie o rozmiarze dysku lub ograniczeniach typu buforowania. Zatrzymaj maszynę wirtualną lub odłącz dysk i spróbuj ponownie wykonać operację".

Aby uniknąć błędów, nie próbuj rozszerzać bieżącej puli magazynów poza 4095 GiB, jeśli początkowo jest mniejszy niż 4 TiB (4096 GiB). Pule magazynów większe niż 4 TiB można rozszerzyć do maksymalnej dostępnej pojemności magazynu.

To ograniczenie ma zastosowanie tylko w przypadku używania Premium_LRSjednostek SKU dysków , , Standard_LRSStandardSSD_LRS, Premium_ZRSi StandardSSD_ZRS .

Tworzenie elastycznej sieci SAN kończy się niepowodzeniem

Jeśli próbujesz utworzyć elastyczną pulę magazynów SIECI SAN, może zostać wyświetlony komunikat Tworzenie elastycznej sieci SAN platformy Azure nie powiodło się: Maksymalna możliwa liczba elastycznych sieci SAN dla utworzonej już subskrypcji. Oznacza to, że osiągnięto limit liczby elastycznych zasobów sieci SAN, które można wdrożyć w regionie na subskrypcję. Limit można sprawdzić tutaj: Elastyczna skalowalność sieci SAN i cele wydajności. Rozważ usunięcie wszystkich istniejących elastycznych zasobów sieci SAN w ramach subskrypcji, które nie są już używane, lub spróbuj utworzyć pulę magazynów w innym regionie.

Nie znaleziono urządzeń zablokowanych

Jeśli zostanie wyświetlony ten komunikat, prawdopodobnie próbujesz utworzyć pulę magazynów dysków efemerycznych w klastrze, w którym jednostka SKU maszyny wirtualnej nie ma dysków NVMe.

Aby rozwiązać ten problem, utwórz pulę węzłów przy użyciu jednostki SKU maszyny wirtualnej z dyskami NVMe i spróbuj ponownie. Zobacz Maszyny wirtualne zoptymalizowane pod kątem magazynu.

Typ puli magazynów jest już włączony

Jeśli spróbujesz włączyć typ puli magazynów, który istnieje, zostanie wyświetlony następujący komunikat: Nieprawidłowa --enable-azure-container-storage wartość. Usługa Azure Container Storage jest już włączona dla typu <storage-pool-type> puli magazynów w klastrze. Możesz sprawdzić, czy istnieją istniejące pule magazynów utworzone, uruchamiając polecenie kubectl get sp -n acstor.

Wyłączanie typu puli magazynów

Podczas wyłączania typu puli magazynów za pośrednictwem usługi Azure Container Storage lub odinstalowywania go za pośrednictwem az aks update --disable-azure-container-storage <storage-pool-type> az aks update --disable-azure-container-storage allprogramu , jeśli istnieje istniejąca pula magazynów tego typu, zostanie wyświetlony następujący komunikat:

Wyłączenie usługi Azure Container Storage dla typu <storage-pool-type> puli magazynów wymusza usunięcie wszystkich pul magazynów tego samego typu i wpływa na aplikacje korzystające z tych pul magazynu. Wymuszone usunięcie pul magazynów może również prowadzić do wycieku zasobów magazynu, które są używane. Czy chcesz sprawdzić, czy którekolwiek z pul magazynów typu <storage-pool-type> są używane przed wyłączeniem usługi Azure Container Storage? (Y/n)

Jeśli wybierzesz wartość Y, zostanie uruchomiona automatyczna walidacja, aby upewnić się, że nie ma woluminów trwałych utworzonych z puli magazynów. Wybranie n pomija tę walidację i wyłącza typ puli magazynów, usuwając wszystkie istniejące pule magazynów i potencjalnie wpływające na aplikację.

Rozwiązywanie problemów z woluminem

Oczekiwanie na utworzenie zasobnika z powodu efemerycznego rozmiaru woluminu poza dostępną pojemnością

Wolumin efemeryczny jest przydzielany w jednym węźle. Podczas konfigurowania rozmiaru woluminów efemerycznych dla zasobników rozmiar powinien być mniejszy niż dostępna pojemność efemerycznego dysku jednego węzła. W przeciwnym razie tworzenie zasobnika jest w stanie oczekiwania.

Użyj następującego polecenia, aby sprawdzić, czy tworzenie zasobnika jest w stanie oczekiwania.

$ kubectl get pods
NAME     READY   STATUS    RESTARTS   AGE
fiopod   0/1     Pending   0          17s

W tym przykładzie zasobnik fiopod jest w Pending stanie.

Użyj następującego polecenia, aby sprawdzić, czy zasobnik ma zdarzenie ostrzegawcze dotyczące trwałego tworzeniavolumeclaim.

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

W tym przykładzie zasobnik wyświetla zdarzenie ostrzegawcze podczas tworzenia trwałego oświadczenia fiopod-ephemeralvolumewoluminu .

Użyj następującego polecenia, aby sprawdzić, czy nie można aprowizować trwałego oświadczenia woluminu z powodu niewystarczającej pojemności.

$ 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 }'")

W tym przykładzie Insufficient Storage przedstawiono przyczynę niepowodzenia aprowizacji woluminów.

Uruchom następujące polecenie, aby sprawdzić dostępną pojemność dysku efemerycznego pojedynczego węzła.

$ 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

W tym przykładzie dostępna pojemność dysku tymczasowego dla jednego węzła to 75031990272 bajty lub 69 GiB.

Dostosuj rozmiar magazynu woluminów mniejszy niż dostępna i ponownie wdróż zasobnik. Zobacz Wdrażanie zasobnika z ogólnym woluminem efemerycznym.

Nie można dołączyć woluminu z powodu magazynu metadanych w trybie offline

Usługa Azure Container Storage używa etcdrozproszonego, niezawodnego magazynu par klucz-wartość do przechowywania metadanych woluminów i zarządzania nimi w celu obsługi operacji orkiestracji woluminów. Aby zapewnić wysoką dostępność i odporność, etcd działa w trzech zasobnikach. Jeśli jest uruchomionych mniej niż dwa etcd wystąpienia, usługa Azure Container Storage zatrzymuje operacje orkiestracji woluminów, jednocześnie zezwalając na dostęp do danych do woluminów. Usługa Azure Container Storage automatycznie wykrywa, kiedy etcd wystąpienie jest w trybie offline i odzyskuje je. Jeśli jednak zauważysz błędy orkiestracji woluminów po ponownym uruchomieniu klastra usługi AKS, możliwe, że etcd wystąpienie nie może wykonać autorecover. Postępuj zgodnie z instrukcjami w tej sekcji, aby określić stan kondycji etcd wystąpień.

Uruchom następujące polecenie, aby uzyskać listę zasobników.

kubectl get pods

Dane wyjściowe mogą być podobne do poniższych.

NAME     READY   STATUS              RESTARTS   AGE 
fiopod   0/1     ContainerCreating   0          25m 

Opisz zasobnik:

kubectl describe pod fiopod

Zazwyczaj są wyświetlane komunikaty o błędach woluminu, jeśli magazyn metadanych jest w trybie offline. W tym przykładzie fiopod ma stan ContainerCreating , a ostrzeżenie FailedAttachVolume wskazuje, że tworzenie jest oczekujące z powodu błędu dołączania woluminu.

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

Możesz również uruchomić następujące polecenie, aby sprawdzić stan etcd wystąpień:

kubectl get pods -n acstor | grep "^etcd"

Powinny zostać wyświetlone dane wyjściowe podobne do następujących, ze wszystkimi wystąpieniami w stanie Uruchomiony:

etcd-azurecontainerstorage-bn89qvzvzv                            1/1     Running   0               4d19h
etcd-azurecontainerstorage-phf92lmqml                            1/1     Running   0               4d19h
etcd-azurecontainerstorage-xznvwcgq4p                            1/1     Running   0               4d19h

Jeśli jest uruchomionych mniej niż dwa wystąpienia, wolumin nie jest dołączany, ponieważ magazyn metadanych jest w trybie offline, a automatyczne odzyskiwanie nie powiodło się. Jeśli tak, utwórz bilet pomocy technicznej z pomocą techniczną platformy Azure.

Zobacz też