Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure Container Storage is een cloudgebaseerde volumebeheer-, implementatie- en indelingsservice die systeemeigen is gebouwd voor containers. Gebruik dit artikel om veelvoorkomende problemen met Azure Container Storage op te lossen en oplossingen voor problemen te vinden.
Installatieproblemen oplossen
Azure Container Storage kan niet worden geïnstalleerd vanwege een ontbrekende configuratie
Nadat de installatie is uitgevoerdaz aks create, ziet u mogelijk het bericht dat Azure Container Storage niet kan worden geïnstalleerd. Er wordt een AKS-cluster gemaakt. Voer de az aks update opdracht --enable-azure-container-storage uit om Azure Container Storage in te schakelen.
Dit bericht betekent dat Azure Container Storage niet is geïnstalleerd, maar dat uw AKS-cluster (Azure Kubernetes Service) juist is gemaakt.
Voer de volgende opdracht uit om Azure Container Storage in het cluster te installeren en een opslaggroep te maken. Vervang <cluster-name> en <resource-group> door uw eigen waarden. Vervangen <storage-pool-type> door azureDisk, ephemeraldisk, of elasticSan.
az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>
Azure Container Storage kan niet worden geïnstalleerd vanwege Azure Policy-beperkingen
Azure Container Storage kan niet worden geïnstalleerd als Azure Policy-beperkingen zijn ingesteld. Azure Container Storage is met name afhankelijk van bevoegde containers. U kunt Azure Policy configureren om bevoegde containers te blokkeren. Wanneer ze worden geblokkeerd, kan de installatie van Azure Container Storage mogelijk een time-out veroorzaken of mislukken, en ziet u mogelijk fouten in de gatekeeper-controller logboeken, zoals:
$ 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"}
Als u de blokkering wilt oplossen, moet u de acstor naamruimte toevoegen aan de uitsluitingslijst van uw Azure Policy. Azure Policy wordt gebruikt voor het maken en afdwingen van regels voor het beheren van resources in Azure, inclusief AKS-clusters. In sommige gevallen kunnen beleidsregels het maken van Azure Container Storage-pods en -onderdelen blokkeren. U vindt meer informatie over het werken met Azure Policy voor Kubernetes door Azure Policy voor Kubernetes te raadplegen.
Voer de volgende stappen uit om de acstor naamruimte toe te voegen aan de uitsluitingslijst:
- Maak uw Azure Kubernetes-cluster.
- Schakel Azure Policy in voor AKS.
- Maak een beleid waarvan u vermoedt dat de installatie van Azure Container Storage wordt geblokkeerd.
- Probeer Azure Container Storage te installeren in het AKS-cluster.
- Controleer de logboeken voor de gatekeeper-controller-pod om eventuele beleidsschendingen te bevestigen.
- Voeg de
acstornaamruimte enazure-extensions-usage-systemnaamruimte toe aan de uitsluitingslijst van het beleid. - Probeer Azure Container Storage opnieuw in het AKS-cluster te installeren.
Kan Azure Container Storage niet installeren en inschakelen in knooppuntgroepen met taints
U kunt knooppunttaints in de knooppoolen configureren om te beperken dat pods worden gepland op deze knooppoolen. Het installeren en inschakelen van Azure Container Storage op deze knooppuntgroepen kan worden geblokkeerd omdat de vereiste pods niet kunnen worden gemaakt in deze knooppuntgroepen. Het gedrag is van toepassing op zowel de systeemknooppuntgroep bij de installatie als de gebruikersknooppuntgroepen bij het inschakelen.
U kunt de tainten van het knooppunt controleren met het volgende voorbeeld:
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": [
"sku=gpu:NoSchedule"
]
}
]
U kunt deze taints tijdelijk verwijderen om de blokkering op te heffen en deze weer te configureren nadat u de installatie hebt voltooid en ingeschakeld. U kunt naar Azure Portal > AKS-clusterknooppuntgroepen > gaan, op uw knooppuntgroep klikken, de tainten verwijderen in de sectie Taints en labels. U kunt ook de volgende opdracht gebruiken om taints te verwijderen en de wijziging te bevestigen.
$ 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
}
]
Probeer opnieuw de installatie of activering uit te voeren nadat u knooppunttaints hebt verwijderd. Nadat dit succesvol is voltooid, kunt u de taints op de knooppunt opnieuw configureren om de beperkingen van de podplanning te hervatten.
Kan het type opslaggroep niet instellen op NVMe
Als u Azure Container Storage probeert te installeren met kortstondige schijf, met name met lokale NVMe op een cluster waar de VIRTUELE machine (VM) SKU geen NVMe-stations heeft, krijgt u het volgende foutbericht: Kan --storage-pool-option niet instellen als NVMe omdat geen van de knooppuntgroepen tijdelijke NVMe-schijf kan ondersteunen.
Om te remediëren maakt u een knooppuntgroep met een VM SKU met NVMe-schijven en probeert u het opnieuw. Zie voor opslag geoptimaliseerde VM's.
Problemen met opslagpool oplossen
Als u de status van uw opslaggroepen wilt controleren, voert u de opdracht uit kubectl describe sp <storage-pool-name> -n acstor. Hier volgen enkele problemen die u kunt tegenkomen.
Tijdelijke opslaggroep claimt de capaciteit niet wanneer de tijdelijke schijven worden gebruikt door andere daemonsets.
Het inschakelen van een tijdelijke opslaggroep op een knooppuntgroep met tijdelijke SSD- of lokale NVMe-schijven claimt mogelijk geen capaciteit van deze schijven als andere daemonsets deze gebruiken.
Voer de volgende stappen uit om Azure Container Storage in te schakelen om deze lokale schijven uitsluitend te beheren:
Voer de volgende opdracht uit om de geclaimde capaciteit per tijdelijke opslaggroep weer te geven:
$ kubectl get sp -A NAMESPACE NAME CAPACITY AVAILABLE USED RESERVED READY AGE acstor ephemeraldisk-nvme 0 0 0 0 False 82sIn dit voorbeeld ziet u een opslagpool die nul capaciteit claimt.
Voer het volgende commando uit om de onverzochte status van deze lokale blokapparaten te bevestigen en controleer het bestaande bestandssysteem op de schijven:
$ 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 …In dit voorbeeld ziet u dat de blokapparaten de status hebben
Unclaimeden dat er een bestaand bestandssysteem op de schijf is.Bevestig dat u Azure Container Storage wilt gebruiken om de lokale gegevensschijven uitsluitend te beheren voordat u doorgaat.
Stop en verwijder de daemonsets of onderdelen die lokale gegevensschijven beheren.
Meld u aan bij elk knooppunt met lokale gegevensschijven.
Verwijder bestaande bestandssystemen van alle lokale gegevensschijven.
Start ndm-daemonset opnieuw om ongebruikte lokale gegevensschijven te detecteren.
$ 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 outWacht een paar seconden en controleer of de tijdelijke opslaggroep de capaciteit claimt van lokale gegevensschijven.
$ 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 4d16hIn dit voorbeeld toont
ephemeraldisk-nvmedat de opslagpool met succes de capaciteit claimt van lokale NVMe-schijven op de knooppunten.
Fout bij het uitbreiden van een Azure Disks-opslaggroep
Als uw bestaande opslaggroep kleiner is dan 4 TiB (4.096 GiB), kunt u deze alleen uitbreiden tot 4.095 GiB. Als u probeert uit te breiden buiten de limiet, geeft het interne PVC een foutbericht weer over schijfgrootte of beperkingen van het cachetype. Stop de VM of ontkoppel de schijf en voer de bewerking opnieuw uit.
Om fouten te voorkomen, probeert u uw huidige opslaggroep niet uit te breiden tot meer dan 4.095 GiB als deze in eerste instantie kleiner is dan 4 TiB (4.096 GiB). Opslaggroepen die groter zijn dan 4 TiB kunnen worden uitgebreid tot de maximale beschikbare opslagcapaciteit.
Deze beperking is alleen van toepassing bij het gebruik van Premium_LRS, Standard_LRS, StandardSSD_LRS, Premium_ZRS en StandardSSD_ZRS schijf-SKU's.
Het maken van een elastisch SAN is mislukt
Als u een elastische SAN-opslaggroep probeert te maken, ziet u mogelijk het bericht dat het maken van elastische SAN in Azure is mislukt: Maximaal mogelijk aantal elastische SAN's voor het abonnement dat al is gemaakt. Dit betekent dat u de limiet bereikt voor het aantal elastische SAN-resources dat per abonnement kan worden geïmplementeerd in een regio. U kunt hier de limiet controleren: Schaalbaarheids- en prestatiedoelen voor elastisch SAN. Overweeg om ongebruikte Elastic SAN-resources in het abonnement te verwijderen, of probeer de opslaggroep in een andere regio te maken.
Er zijn geen blokapparaten gevonden
Als u dit bericht ziet, probeert u waarschijnlijk een tijdelijke schijfopslaggroep te maken op een cluster waarop de VM-SKU geen NVMe-stations heeft.
Om dit te verhelpen, maakt u een knooppuntgroep met een VM-SKU met NVMe-schijven en probeert u het opnieuw. Zie voor opslag geoptimaliseerde VM's.
Type opslaggroep is al ingeschakeld
Als u probeert een opslaggroeptype in te schakelen dat bestaat, krijgt u het volgende bericht: Ongeldige --enable-azure-container-storage waarde. Azure Container Storage is al ingeschakeld voor het type <storage-pool-type> opslaggroep in het cluster. U kunt controleren of er bestaande opslaggroepen zijn door de kubectl get sp -n acstor-opdracht uit te voeren.
Een type opslaggroep uitschakelen
Wanneer u een type opslaggroep uitschakelt via az aks update --disable-azure-container-storage <storage-pool-type> Of Azure Container Storage verwijdert via az aks update --disable-azure-container-storage all, als er een bestaande opslaggroep van dat type is, krijgt u het volgende bericht:
Als u Azure Container Storage uitschakelt voor het type <storage-pool-type> opslaggroep, worden alle opslaggroepen van hetzelfde type geforceerd verwijderd en is dit van invloed op de toepassingen die deze opslaggroepen gebruiken. Het geforceerd verwijderen van opslagpools kan ook leiden tot het onbedoeld verlies van opslagmiddelen die momenteel in gebruik zijn. Wilt u controleren of een van de opslaggroepen van het type <storage-pool-type> wordt gebruikt voordat u Azure Container Storage uitschakelt? (Y/n)
Als u Y selecteert, wordt een automatische validatie uitgevoerd om ervoor te zorgen dat er geen permanente volumes zijn gemaakt vanuit de opslaggroep. Als u n selecteert, wordt deze validatie overgeslagen en wordt het type opslaggroep uitgeschakeld, waarbij bestaande opslaggroepen worden verwijdert en mogelijk van invloed is op uw toepassing.
Volumeproblemen oplossen
Pod in behandeling omdat het vluchtige volume groter is dan de beschikbare capaciteit
Op één knooppunt wordt een ephemerisch volume toegewezen. Wanneer u de grootte van tijdelijke volumes voor uw pods configureert, moet de grootte kleiner zijn dan de beschikbare capaciteit van de tijdelijke schijf van één knooppunt. Het aanmaken van de pod staat dan op status In behandeling.
Gebruik de volgende opdracht om te controleren of het maken van uw pod in afwachting is.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
fiopod 0/1 Pending 0 17s
In dit voorbeeld is de pod fiopod in Pending status.
Gebruik de volgende opdracht om te controleren of de pod de waarschuwingsmelding heeft bij het aanmaken van een 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..
In dit voorbeeld toont de pod de waarschuwingsgebeurtenis bij het maken van een persistentievolumeclaim fiopod-ephemeralvolume.
Gebruik de volgende opdracht om te controleren of de permanente volumeclaim niet kan worden geleverd vanwege onvoldoende capaciteit.
$ 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 dit voorbeeld wordt Insufficient Storage weergegeven als de reden voor een fout bij het provisioneren van volumes.
Voer de volgende opdracht uit om de beschikbare capaciteit van de tijdelijke schijf van één knooppunt te controleren.
$ 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 dit voorbeeld is de beschikbare capaciteit van de tijdelijke schijf voor één knooppunt 75031990272 bytes of 69 GiB.
Pas de grootte van de volumeopslag aan die kleiner is dan de beschikbare capaciteit en implementeer uw pod opnieuw. Zie Een pod implementeren met een algemeen kortstondig volume.
Volume kan niet worden gekoppeld vanwege het offline opslaan van metagegevens
Azure Container Storage maakt gebruik van etcd, een gedistribueerd, betrouwbaar sleutel-waardedatastore, voor het opslaan en beheren van metagegevens van volumes ter ondersteuning van volume-orkestratieoperaties. Voor hoge beschikbaarheid en veerkracht draait etcd in drie pods. Wanneer er minder dan twee etcd exemplaren worden uitgevoerd, stopt Azure Container Storage volumeindelingsbewerkingen terwijl er nog steeds gegevenstoegang tot de volumes is toegestaan. Azure Container Storage detecteert automatisch wanneer een etcd exemplaar offline is en herstelt deze. Als u echter volumeindelingsfouten ziet na het opnieuw opstarten van een AKS-cluster, is het mogelijk dat een etcd exemplaar niet automatisch kan worden hersteld. Volg de instructies in dit deel om de gezondheidstoestand van de etcd exemplaren vast te stellen.
Voer de volgende opdracht uit om een lijst met pods op te halen.
kubectl get pods
Mogelijk ziet u uitvoer die er ongeveer als volgt uitziet.
NAME READY STATUS RESTARTS AGE
fiopod 0/1 ContainerCreating 0 25m
Beschrijf de pod:
kubectl describe pod fiopod
Meestal ziet u volumefoutmeldingen als het metagegevensarchief offline is. In dit voorbeeld bevindt fiopod zich in de status ContainerCreating, en de waarschuwing FailedAttachVolume geeft aan dat het maken in behandeling is vanwege een fout bij het koppelen van het volume.
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
U kunt ook de volgende opdracht uitvoeren om de status van etcd exemplaren te controleren:
kubectl get pods -n acstor | grep "^etcd"
De uitvoer moet er ongeveer als volgt uitzien, met alle exemplaren met de status Actief:
etcd-azurecontainerstorage-bn89qvzvzv 1/1 Running 0 4d19h
etcd-azurecontainerstorage-phf92lmqml 1/1 Running 0 4d19h
etcd-azurecontainerstorage-xznvwcgq4p 1/1 Running 0 4d19h
Als er minder dan twee exemplaren actief zijn, wordt het volume niet gekoppeld omdat de metadataopslag offline is en automatisch herstel is mislukt. Als dat het zo is, dient u een ondersteuningsticket in bij Azure-ondersteuning.