Delen via


Problemen met Azure Container Storage oplossen

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 --enable-azure-container-storage opdracht az aks update 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, ephemeraldiskof 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 er een time-out optreden voor de installatie van Azure Container Storage 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:

  1. Maak uw Azure Kubernetes-cluster.
  2. Schakel Azure Policy in voor AKS.
  3. Maak een beleid waarvan u vermoedt dat de installatie van Azure Container Storage wordt geblokkeerd.
  4. Probeer Azure Container Storage te installeren in het AKS-cluster.
  5. Controleer de logboeken voor de gatekeeper-controller-pod om eventuele beleidsschendingen te bevestigen.
  6. Voeg de acstor naamruimte en azure-extensions-usage-system naamruimte toe aan de uitsluitingslijst van het beleid.
  7. 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 knooppuntgroepen configureren om te voorkomen dat pods worden gepland op deze knooppuntgroepen. 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 de installatie of inschakeling opnieuw uit te voeren nadat u knooppunttaints hebt verwijderd. Nadat dit is voltooid, kunt u knooppunttaints weer configureren om 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.

Als u wilt herstellen, maakt u een knooppuntgroep met een VM-SKU met NVMe-stations en probeert u het opnieuw. Zie voor opslag geoptimaliseerde VM's.

Problemen met opslaggroep 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.

Kortstondige opslaggroep claimt de capaciteit niet wanneer de kortstondige 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:

  1. 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   82s
    

    In dit voorbeeld ziet u nul capaciteit die wordt geclaimd door ephemeraldisk-nvme opslaggroep.

  2. Voer de volgende opdracht uit om de status van deze lokale blokapparaten te bevestigen en het bestaande bestandssysteem op de schijven te controleren:

    $ 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 Unclaimed en dat er een bestaand bestandssysteem op de schijf is.

  3. Bevestig dat u Azure Container Storage wilt gebruiken om de lokale gegevensschijven uitsluitend te beheren voordat u doorgaat.

  4. Stop en verwijder de daemonsets of onderdelen die lokale gegevensschijven beheren.

  5. Meld u aan bij elk knooppunt met lokale gegevensschijven.

  6. Verwijder bestaande bestandssystemen van alle lokale gegevensschijven.

  7. 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 out
    
  8. Wacht 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    4d16h
    

    In dit voorbeeld ziet u dat ephemeraldisk-nvme de opslaggroep 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 wanneer u SKU's voor schijven gebruiktPremium_LRS, Standard_LRSen StandardSSD_LRSPremium_ZRSStandardSSD_ZRS schijf-SKU's gebruikt.

Elastisch SAN maken 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 bestaande elastische SAN-resources te verwijderen voor het abonnement dat niet meer wordt gebruikt 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.

Als u wilt herstellen, maakt u een knooppuntgroep met een VM-SKU met NVMe-stations 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 gemaakt door deze uit te voeren kubectl get sp -n acstor.

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 afdwingen van opslaggroepen kan ook leiden tot het lekken van opslagbronnen die worden verbruikt. 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 vanwege tijdelijke volumegrootte buiten de beschikbare capaciteit

Een kortstondig volume wordt toegewezen op één knooppunt. 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. Anders heeft het maken van de pod de status In behandeling.

Gebruik de volgende opdracht om te controleren of de status van het maken van uw pod in behandeling is.

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

In dit voorbeeld heeft Pending de pod fiopod de status.

Gebruik de volgende opdracht om te controleren of de pod de waarschuwingsgebeurtenis heeft voor het maken van persistentvolumeclaims.

$ 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 waarschuwings gebeurtenis bij het maken van een permanente volumeclaim fiopod-ephemeralvolume.

Gebruik de volgende opdracht om te controleren of de permanente volumeclaim niet kan worden ingericht 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 Insufficient Storage wordt dit weergegeven als de reden voor een fout bij het inrichten 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 75031990272 de beschikbare capaciteit van tijdelijke schijf voor één knooppunt 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 etcdvan , een gedistribueerd, betrouwbaar sleutel-waardearchief, voor het opslaan en beheren van metagegevens van volumes ter ondersteuning van volumeindelingsbewerkingen. Voor hoge beschikbaarheid en tolerantie worden etcd in drie pods uitgevoerd. 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 deze sectie om de status van de etcd exemplaren te bepalen.

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

Normaal gesproken ziet u foutberichten over volumefouten als het metagegevensarchief offline is. In dit voorbeeld bevindt fiopod zich in de status ContainerCreating en geeft de waarschuwing FailedAttachVolume 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 worden uitgevoerd, wordt het volume niet gekoppeld omdat het metagegevensarchief offline is en automatisch herstel is mislukt. Als dat het zo is, dient u een ondersteuningsticket in bij Azure-ondersteuning.

Zie ook