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 create
kan 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
, ephemeraldisk
eller 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:
- Skapa ditt Azure Kubernetes-kluster.
- Aktivera Azure Policy för AKS.
- Skapa en princip som du misstänker blockerar installationen av Azure Container Storage.
- Försök att installera Azure Container Storage i AKS-klustret.
- Kontrollera loggarna för gatekeeper-controller-podden för att bekräfta eventuella principöverträdelser.
acstor
Lägg till namnområdet ochazure-extensions-usage-system
namnområdet i undantagslistan för principen.- 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:
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
.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.Bekräfta att du vill använda Azure Container Storage för att hantera de lokala datadiskarna exklusivt innan du fortsätter.
Stoppa och ta bort daemonuppsättningar eller komponenter som hanterar lokala datadiskar.
Logga in på varje nod som har lokala datadiskar.
Ta bort befintliga filsystem från alla lokala datadiskar.
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
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_ZRS
och 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 all
få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.