Felsöka Azure Container Storage

Azure Container Storage är en molnbaserad volymhanterings-, distributions- och orkestreringstjänst som skapats internt för containrar. Använd den här artikeln om du vill felsöka vanliga problem med Azure Container Storage och hitta lösningar på problem.

Felsöka installationsproblem

Det går inte att installera Azure Container Storage på grund av att konfigurationen saknas

När du har kört az aks createkan du se meddelandet azure container storage misslyckades att installera. AKS-kluster skapas. Kör az aks update tillsammans med --enable-azure-container-storage för att aktivera Azure Container Storage.

Det här meddelandet innebär att Azure Container Storage inte har installerats, men aks-klustret har skapats korrekt.

Kör följande kommando för att installera Azure Container Storage i klustret och skapa en lagringspool. Ersätt <cluster-name> och <resource-group> med dina egna värden. Ersätt <storage-pool-type> med azureDisk, ephemeraldiskeller elasticSan.

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

Azure Container Storage kan inte installeras på grund av Azure Policy-begränsningar

Azure Container Storage kan misslyckas med att installera om Azure Policy-begränsningar finns på plats. Mer specifikt förlitar sig Azure Container Storage på privilegierade containrar, som kan blockeras av Azure Policy. När detta inträffar kan installationen av Azure Container Storage överskrida tidsgränsen eller misslyckas, och du kan se fel i loggarna gatekeeper-controller , till exempel:

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

För att lösa detta måste du lägga acstor till namnområdet i undantagslistan för din Azure Policy. Azure Policy används för att skapa och tillämpa regler för att hantera resurser i Azure, inklusive AKS-kluster. I vissa fall kan principer blockera skapandet av Azure Container Storage-poddar och -komponenter. Mer information om hur du arbetar med Azure Policy for Kubernetes finns i Azure Policy for Kubernetes.

Följ dessa steg för att lägga till acstor namnområdet i undantagslistan:

  1. Skapa ditt Azure Kubernetes-kluster.
  2. Aktivera Azure Policy för AKS.
  3. Skapa en princip som du misstänker blockerar installationen av Azure Container Storage.
  4. Försök att installera Azure Container Storage i AKS-klustret.
  5. Kontrollera loggarna för gatekeeper-controller-podden för att bekräfta eventuella principöverträdelser.
  6. acstor Lägg till namnområdet i undantagslistan för principen.
  7. Försök att installera Azure Container Storage i AKS-klustret igen.

Det går inte att ange lagringspooltypen till NVMe

Om du försöker installera Azure Container Storage med Ephemeral Disk, särskilt med lokal NVMe på ett kluster där den virtuella datorn (VM) SKU:n inte har NVMe-enheter, får du följande felmeddelande: Det går inte att ange alternativet --storage-pool-as NVMe eftersom ingen av nodpoolerna har stöd för tillfälliga NVMe-diskar.

Du kan åtgärda problemet genom att skapa en nodpool med en VM-SKU som har NVMe-enheter och försöka igen. Se Lagringsoptimerade virtuella datorer.

Felsöka problem med lagringspooler

Om du vill kontrollera status för dina lagringspooler kör du kubectl describe sp <storage-pool-name> -n acstor. Här följer några problem som du kan stöta på.

Fel vid försök att expandera en Azure Disks-lagringspool

Om din befintliga lagringspool är mindre än 4 TiB (4 096 GiB) kan du bara expandera den till 4 095 GiB. Om du försöker expandera utöver detta får den interna PVC ett felmeddelande som "Endast diskcachingType "Ingen" stöds för diskar med en storlek som är större än 4 095 GB eller ""Disk 'xxx' av storlek 4096 GB (<=4 096 GB) kan inte ändras till 16384 GB (>4 096 GB) medan den är ansluten till en virtuell dator som körs. Stoppa den virtuella datorn eller koppla från disken och försök igen."

Undvik fel genom att inte försöka expandera den aktuella lagringspoolen utöver 4 095 GiB om den ursprungligen är mindre än 4 TiB (4 096 GiB). Lagringspooler som är större än 4 TiB kan utökas upp till den maximala tillgängliga lagringskapaciteten.

Den här begränsningen gäller endast när du använder Premium_LRS, Standard_LRS, StandardSSD_LRS, Premium_ZRSoch StandardSSD_ZRS disk-SKU:er.

Det går inte att skapa elastiskt SAN

Om du försöker skapa en elastisk SAN-lagringspool kan du se meddelandet azure elastic SAN creation failed( Azure Elastic SAN creation failed: Maximum possible number of Elastic SAN for the Subscription created already( Azure Elastic SAN creation failed: Maximum possible number of Elastic SAN for the Subscription created already. Det innebär att du har nått gränsen för antalet elastiska SAN-resurser som kan distribueras i en region per prenumeration. Du kan kontrollera gränsen här: Elastic SAN-skalbarhet och prestandamål. Överväg att ta bort befintliga elastiska SAN-resurser i prenumerationen som inte längre används, eller prova att skapa lagringspoolen i en annan region.

Inga blockenheter hittades

Om du ser det här meddelandet försöker du förmodligen skapa en tillfällig disklagringspool i ett kluster där den virtuella datorns SKU inte har NVMe-enheter.

Du kan åtgärda problemet genom att skapa en nodpool med en VM-SKU som har NVMe-enheter och försöka igen. Se Lagringsoptimerade virtuella datorer.

Lagringspooltypen är redan aktiverad

Om du försöker aktivera en lagringspooltyp som redan är aktiverad visas följande meddelande: Ogiltigt --enable-azure-container-storage värde. Azure Container Storage är redan aktiverat för lagringspooltypen <storage-pool-type> i klustret. Du kan kontrollera om du har några befintliga lagringspooler som skapats genom att köra kubectl get sp -n acstor.

Inaktivera en typ av lagringspool

När du inaktiverar en typ av lagringspool via az aks update --disable-azure-container-storage <storage-pool-type> eller avinstallerar Azure Container Storage via az aks update --disable-azure-container-storage allfår du följande meddelande om det finns en befintlig lagringspool av den typen:

Om du inaktiverar Azure Container Storage för lagringspooltypen <storage-pool-type> tas alla lagringspooler av samma typ bort med kraft och de program som använder dessa lagringspooler påverkas. En kraftfull borttagning av lagringspooler kan också leda till läckage av lagringsresurser som förbrukas. Vill du kontrollera om någon av lagringspoolerna av typen <storage-pool-type> används innan du inaktiverar Azure Container Storage? (Y/n)

Om du väljer Y körs en automatisk validering för att säkerställa att inga beständiga volymer har skapats från lagringspoolen. Om du väljer n kringgås den här valideringen och lagringspooltypen inaktiveras, eventuella befintliga lagringspooler tas bort och programmet kan påverkas.

Det går inte att ta bort resursgruppen som innehåller AKS-kluster

Om du har skapat en elastisk SAN-lagringspool kanske du inte kan ta bort resursgruppen där AKS-klustret finns.

Lös problemet genom att logga in på Azure Portal och välja Resursgrupper. Leta upp den resursgrupp som AKS skapade (resursgruppens namn börjar med MC_). Välj SAN-resursobjektet i resursgruppen. Ta bort alla volymer och volymgrupper manuellt. Försök sedan att ta bort resursgruppen som innehåller AKS-klustret igen.

Felsöka volymproblem

Podd väntar på att skapas på grund av en tillfällig volymstorlek över tillgänglig kapacitet

En tillfällig volym allokeras på en enda nod. När du konfigurerar storleken på tillfälliga volymer för dina poddar bör storleken vara mindre än den tillgängliga kapaciteten för en enskild nods tillfälliga disk. Annars är poddskapandet i väntande status.

Använd följande kommando för att kontrollera om podden har väntande status.

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

I det här exemplet är podden fiopod i Pending status.

Använd följande kommando för att kontrollera om podden har varningshändelsen för att skapa persistentvolumeclaim.

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

I det här exemplet visar podden varningshändelsen för att skapa beständiga volymanspråk fiopod-ephemeralvolume.

Använd följande kommando för att kontrollera om det beständiga volymanspråket inte kan etableras på grund av otillräcklig kapacitet.

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

I det här exemplet Insufficient Storage visas som orsaken till volymetableringsfel.

Kör följande kommando för att kontrollera den tillgängliga kapaciteten för en enskild nods tillfälliga disk.

$ 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

I det här exemplet är 75031990272 den tillgängliga kapaciteten för temporär disk för en enskild nod byte eller 69 GiB.

Justera volymens lagringsstorlek under den tillgängliga kapaciteten och distribuera om podden. Se Distribuera en podd med en allmän tillfällig volym.

Det går inte att ansluta volymen på grund av att metadatalagret är offline

Azure Container Storage använder etcd, ett distribuerat, tillförlitligt nyckelvärdeslager, för att lagra och hantera metadata för volymer för att stödja volymorkestreringsåtgärder. För hög tillgänglighet och återhämtning etcd körs i tre poddar. Om det finns mindre än två etcd instanser som körs stoppar Azure Container Storage volymorkestreringsåtgärder samtidigt som dataåtkomst till volymerna tillåts. Azure Container Storage identifierar automatiskt när en etcd instans är offline och återställer den. Men om du märker volymorkestreringsfel när du har startat om ett AKS-kluster är det möjligt att en etcd instans inte kunde återställas automatiskt. Följ anvisningarna i det här avsnittet för att fastställa hälsostatusen för etcd instanserna.

Kör följande kommando för att hämta en lista över poddar.

kubectl get pods

Du ser utdata som liknar följande.

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

Beskriv podden:

kubectl describe pod fiopod

Vanligtvis visas meddelanden om volymfel om metadatalagret är offline. I det här exemplet är fiopod i ContainerCreating-status och varningen FailedAttachVolume anger att skapandet väntar på grund av fel vid volymanslutning.

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

Du kan också köra följande kommando för att kontrollera status etcd för instanser:

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

Du bör se utdata som liknar följande, med alla instanser i tillståndet Körs:

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

Om färre än två instanser visas i körningstillståndet kan du dra slutsatsen att volymen inte kan kopplas på grund av att metadatalagret är offline och att den automatiserade återställningen inte lyckades. I så fall skickar du ett supportärende till Azure Support.

Se även