Dela via


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 (Azure Kubernetes Service) 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. Du kan konfigurera Azure Policy för att blockera privilegierade containrar. När de blockeras kan installationen av Azure Container Storage överskrida tidsgränsen eller misslyckas, och du kan se fel i loggarna gatekeeper-controller , till exempel:

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

För att lösa blockeringen 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 och azure-extensions-usage-system 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 installera och aktivera Azure Container Storage i nodpooler med taints

Du kan konfigurera nodtaints i nodpoolerna för att hindra poddar från att schemaläggas i dessa nodpooler. Installation och aktivering av Azure Container Storage i dessa nodpooler kan blockeras eftersom de nödvändiga poddarna inte kan skapas i dessa nodpooler. Beteendet gäller både systemnodpoolen vid installation och användarnodpoolerna när du aktiverar.

Du kan kontrollera nodtainterna med följande exempel:

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

Du kan ta bort dessa taints tillfälligt för att avblockera och konfigurera dem igen när du har installerat och aktiverat dem. Du kan gå till Azure Portal > AKS-klusternodpooler > , klicka på nodpoolen och ta bort tainterna i avsnittet Taints och etiketter. Du kan också använda följande kommando för att ta bort taints och bekräfta ändringen.

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

Försök att installera eller aktivera igen när du har tagit bort nodtaints. När den har slutförts kan du konfigurera nodtaints tillbaka för att återuppta poddschemaläggningsbegränsningarna.

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

Tillfälliga lagringspooler gör inte anspråk på kapaciteten när de tillfälliga diskarna används av andra daemonuppsättningar

Om du aktiverar en tillfällig lagringspool i en nodpool med temp SSD eller lokala NVMe-diskar kanske du inte gör anspråk på kapacitet från dessa diskar om andra daemonuppsättningar använder dem.

Kör följande steg för att göra det möjligt för Azure Container Storage att hantera dessa lokala diskar exklusivt:

  1. Kör följande kommando för att se den begärda kapaciteten av den tillfälliga lagringspoolen:

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

    I det här exemplet visas noll kapacitet som begärs av lagringspoolen ephemeraldisk-nvme .

  2. Kör följande kommando för att bekräfta tillståndet för dessa lokala blockenheter och kontrollera det befintliga filsystemet på diskarna:

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

    Det här exemplet visar att blockenheterna är Unclaimed status och att det finns ett befintligt filsystem på disken.

  3. Bekräfta att du vill använda Azure Container Storage för att hantera de lokala datadiskarna exklusivt innan du fortsätter.

  4. Stoppa och ta bort daemonuppsättningar eller komponenter som hanterar lokala datadiskar.

  5. Logga in på varje nod som har lokala datadiskar.

  6. Ta bort befintliga filsystem från alla lokala datadiskar.

  7. Starta om daemonuppsättningen ndm för att identifiera oanvända lokala datadiskar.

    $ 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. Vänta några sekunder och kontrollera om den tillfälliga lagringspoolen gör anspråk på kapaciteten från lokala datadiskar.

    $ 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
    

    I det här exemplet visas ephemeraldisk-nvme hur lagringspoolen gör anspråk på kapaciteten från lokala NVMe-diskar på noderna.

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 över gränsen visar den interna PVC:en ett felmeddelande om begränsningar för diskstorlek eller cachelagringstyp. 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 når 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 finns får du 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 det påverkar de program som använder dessa lagringspooler. 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.

Felsöka volymproblem

Podd väntar på att skapas på grund av tillfällig volymstorlek utö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 mindre än 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. När det körs mindre än två etcd instanser 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 återskapas 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 kan se 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 körs kopplas inte volymen eftersom metadatalagret är offline och automatisk återställning misslyckades. I så fall kan du skicka ett supportärende till Azure Support.

Se även