Risolvere i problemi di Azure Container Storage

Articolo
12/18/2024

Archiviazione di Azure Container è un servizio di gestione, distribuzione e orchestrazione basato sul cloud creato in modo nativo per i contenitori. Usare questo articolo per risolvere problemi comuni relativi ad Azure Container Storage e individuare soluzioni a problemi.

Risoluzione dei problemi di installazione

L'installazione di Archiviazione Azure Container non riesce a causa di una configurazione mancante

Dopo l'esecuzione az aks create, potrebbe essere visualizzato il messaggio Archiviazione Azure Container non è riuscito a eseguire l'installazione. Viene creato un cluster del servizio Azure Kubernetes. Eseguire az aks update insieme --enable-azure-container-storage a per abilitare Archiviazione azure Container.

Questo messaggio indica che l'archiviazione di Azure Container non è stata installata, ma il cluster del servizio Azure Kubernetes (servizio Azure Kubernetes) è stato creato correttamente.

Per installare Azure Container Storage nel cluster e creare un pool di archiviazione, eseguire il comando seguente. Sostituire <cluster-name> e <resource-group> con valori personalizzati. Sostituire <storage-pool-type> con azureDisk, ephemeraldisk o elasticSan.

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

L'installazione di Archiviazione Azure Container non riesce a causa di restrizioni Criteri di Azure

Archiviazione azure Container potrebbe non riuscire a eseguire l'installazione se sono presenti restrizioni Criteri di Azure. In particolare, Archiviazione Azure Container si basa su contenitori con privilegi. È possibile configurare Criteri di Azure per bloccare i contenitori con privilegi. Quando vengono bloccati, l'installazione di Archiviazione Azure Container potrebbe verificarsi un timeout o un errore e potrebbero verificarsi errori nei gatekeeper-controller log, ad esempio:

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

Per risolvere il blocco, è necessario aggiungere lo acstor spazio dei nomi all'elenco di esclusione del Criteri di Azure. Criteri di Azure viene usato per creare e applicare regole per la gestione delle risorse all'interno di Azure, inclusi i cluster del servizio Azure Kubernetes. In alcuni casi, i criteri potrebbero bloccare la creazione di pod e componenti di Archiviazione Azure Container. Per altre informazioni sull'uso di Criteri di Azure per Kubernetes, vedere Criteri di Azure per Kubernetes.

Per aggiungere lo acstor spazio dei nomi all'elenco di esclusione, seguire questa procedura:

Creare il cluster Azure Kubernetes.
Abilitare Criteri di Azure per il servizio Azure Kubernetes.
Creare un criterio che si sospetta stia bloccando l'installazione di Archiviazione azure Container.
Provare a installare Archiviazione azure Container nel cluster del servizio Azure Kubernetes.
Controllare i log per il pod gatekeeper-controller per verificare eventuali violazioni dei criteri.
Aggiungere lo spazio dei nomi e azure-extensions-usage-system lo acstor spazio dei nomi all'elenco di esclusione dei criteri.
Provare nuovamente a installare Archiviazione Azure Container nel cluster del servizio Azure Kubernetes.

Non è possibile installare e abilitare l'archiviazione di Azure Container nei pool di nodi con taints

È possibile configurare i nodi taints nei pool di nodi per limitare la pianificazione dei pod in questi pool di nodi. L'installazione e l'abilitazione di Archiviazione Azure Container in questi pool di nodi possono essere bloccate perché i pod necessari non possono essere creati in questi pool di nodi. Il comportamento si applica sia al pool di nodi di sistema durante l'installazione che ai pool di nodi utente durante l'abilitazione.

È possibile controllare i nodi con l'esempio seguente:

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

È possibile rimuovere temporaneamente questi taints per sbloccarli e configurarli di nuovo dopo l'installazione e l'abilitazione. È possibile passare ai pool di nodi del cluster del servizio > Azure Kubernetes del portale > di Azure, fare clic sul pool di nodi, rimuovere i taints nella sezione "Taints and labels". In alternativa, è possibile usare il comando seguente per rimuovere i contenitori e confermare la modifica.

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

Ripetere l'installazione o l'abilitazione dopo aver rimosso correttamente i nodi. Al termine, è possibile configurare i vincoli dei nodi per riprendere le restrizioni di pianificazione dei pod.

Non è possibile impostare il tipo di pool di archiviazione su NVMe

Se si tenta di installare Azure Container Storage con disco temporaneo, in particolare con NVMe locale in un cluster in cui lo SKU della macchina virtuale (VM) non dispone di unità NVMe, viene visualizzato il messaggio di errore seguente: Non è possibile impostare --storage-pool-option come NVMe perché nessuno dei pool di nodi può supportare il disco NVMe temporaneo.

Per correggere il problema, creare un pool di nodi con uno SKU di macchina virtuale con unità NVMe e riprovare. Vedere macchine virtuali ottimizzate per l’archiviazione.

Risolvere i problemi del pool di archiviazione

Per controllare lo stato dei pool di archiviazione, eseguire kubectl describe sp <storage-pool-name> -n acstor. Ecco alcuni problemi che potrebbero verificarsi.

Il pool di archiviazione temporaneo non richiede la capacità quando i dischi temporanei vengono usati da altri daemonset

L'abilitazione di un pool di archiviazione temporaneo in un pool di nodi con dischi NVMe temporanei o SSD temporanei potrebbe non richiedere capacità da questi dischi se altri daemonset li usano.

Eseguire i passaggi seguenti per abilitare l'archiviazione di Azure Container per gestire esclusivamente questi dischi locali:

Eseguire il comando seguente per visualizzare la capacità richiesta dal pool di archiviazione temporaneo:
```
$ kubectl get sp -A
NAMESPACE   NAME                 CAPACITY   AVAILABLE   USED   RESERVED   READY   AGE
acstor      ephemeraldisk-nvme   0          0           0      0          False   82s
```
Questo esempio mostra zero capacità richiesta dal ephemeraldisk-nvme pool di archiviazione.

Eseguire il comando seguente per confermare lo stato non reclamato di questi dispositivi a blocchi locali e controllare il file system esistente nei dischi:

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

Questo esempio mostra che i dispositivi a blocchi sono Unclaimed in stato ed è presente un file system esistente sul disco.

Verificare di voler usare Archiviazione Azure Container per gestire i dischi dati locali esclusivamente prima di procedere.
Arrestare e rimuovere i daemonset o i componenti che gestiscono i dischi dati locali.
Accedere a ogni nodo con dischi dati locali.
Rimuovere i file system esistenti da tutti i dischi dati locali.

Riavviare ndm daemonset per individuare i dischi dati locali inutilizzati.

$ 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

Attendere alcuni secondi e verificare se il pool di archiviazione temporaneo richiede la capacità dai dischi dati locali.

$ 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

Questo esempio mostra che ephemeraldisk-nvme il pool di archiviazione richiede correttamente la capacità dai dischi NVMe locali nei nodi.

Errore durante il tentativo di espandere un pool di archiviazione dei dischi di Azure

Se il pool di archiviazione esistente è inferiore a 4 TiB (4.096 GiB), è possibile espanderlo solo fino a 4.095 GiB. Se si tenta di espandere oltre il limite, il PVC interno visualizza un messaggio di errore relativo alle dimensioni del disco o alle limitazioni del tipo di memorizzazione nella cache. Arrestare la macchina virtuale o scollegare il disco e ripetere l'operazione."

Per evitare errori, non tentare di espandere il pool di archiviazione corrente oltre 4.095 GiB se inizialmente è inferiore a 4 TiB (4.096 GiB). I pool di archiviazione di dimensioni superiori a 4 TiB possono essere espansi fino alla capacità di archiviazione massima disponibile.

Questa limitazione si applica solo quando si usano SKU disco Premium_LRS, Standard_LRS, StandardSSD_LRS, Premium_ZRS e StandardSSD_ZRS.

Creazione SAN di Elastic non riuscita

Se si sta tentando di creare un pool di archiviazione SAN di Elastic, è possibile che venga visualizzato il messaggio Creazione SAN di Elastic in Azure non riuscita: è già stato creato il numero massimo possibile di SAN di Elastic per la sottoscrizione. Ciò significa che si raggiunge il limite per il numero di risorse SAN elastico che possono essere distribuite in un'area per ogni sottoscrizione. È possibile controllare il limite qui: Obiettivi di scalabilità e prestazioni di SAN di Elastic. Provare a eliminare le risorse SAN di Elastic esistenti nella sottoscrizione che non vengono più usate o provare a creare il pool di archiviazione in un’area diversa.

Non sono stati trovati dispositivi a blocchi

Se viene visualizzato questo messaggio, è probabile che si stia provando a creare un pool di archiviazione del disco temporaneo in un cluster in cui lo SKU della macchina virtuale non dispone di unità NVMe.

Per correggere il problema, creare un pool di nodi con uno SKU di macchina virtuale con unità NVMe e riprovare. Vedere macchine virtuali ottimizzate per l’archiviazione.

Tipo di pool di archiviazione già abilitato

Se si tenta di abilitare un tipo di pool di archiviazione esistente, viene visualizzato il messaggio seguente: Valore non valido --enable-azure-container-storage . Archiviazione azure Container è già abilitata per il tipo di pool di <storage-pool-type> archiviazione nel cluster. È possibile verificare se sono presenti pool di archiviazione esistenti creati eseguendo kubectl get sp -n acstor.

Disabilitazione di un tipo di pool di archiviazione

Quando si disabilita un tipo di pool di archiviazione tramite az aks update --disable-azure-container-storage <storage-pool-type> o quando si disinstalla Azure Container Storage tramite az aks update --disable-azure-container-storage all, se è presente un pool di archiviazione esistente di tale tipo, viene visualizzato il messaggio seguente:

La disabilitazione di Archiviazione Azure Container per il tipo di pool di <storage-pool-type> archiviazione elimina forzatamente tutti i pool di archiviazione dello stesso tipo e influisce sulle applicazioni che usano questi pool di archiviazione. L’eliminazione forzata di pool di archiviazione può anche causare perdite di risorse di archiviazione usate. Si vuole verificare se uno dei pool di archiviazione di tipo <storage-pool-type> viene usato prima di disabilitare Azure Container Storage? (Y/N)

Se si seleziona Y, viene eseguita una convalida automatica per assicurarsi che non siano presenti volumi permanenti creati dal pool di archiviazione. Se si seleziona N, viene ignorata questa convalida e viene disabilitato il tipo di pool di archiviazione, eliminando eventuali pool di archiviazione esistenti e potenzialmente influenzando l’applicazione.

Risolvere i problemi relativi al volume

Creazione di pod in sospeso a causa di dimensioni temporanee del volume oltre la capacità disponibile

Un volume temporaneo viene allocato in un singolo nodo. Quando si configurano le dimensioni dei volumi temporanei per i pod, le dimensioni devono essere inferiori alla capacità disponibile del disco temporaneo di un singolo nodo. In caso contrario, la creazione del pod è in sospeso.

Usare il comando seguente per verificare se la creazione del pod è in sospeso.

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

In questo esempio, il pod fiopod è in stato Pending.

Usare il comando seguente per verificare se il pod ha l’evento di avviso per la creazione di 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 questo esempio, il pod mostra l’evento di avviso per la creazione di un’attestazione di volume permanente fiopod-ephemeralvolume.

Usare il comando seguente per verificare se l’attestazione del volume persistente non riesce a eseguire il provisioning a causa di capacità insufficiente.

$ 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 questo esempio, Insufficient Storage viene visualizzato come motivo dell’errore di provisioning del volume.

Eseguire il comando seguente per verificare la capacità disponibile del disco temporaneo di un singolo nodo.

$ 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 questo esempio, la capacità disponibile del disco temporaneo per un singolo nodo è 75031990272 byte o 69 GiB.

Modificare le dimensioni di archiviazione del volume inferiori alla capacità disponibile e ridistribuire il pod. Vedere Distribuire un pod con un volume temporaneo generico.

Il volume non riesce a connettersi a causa dell'archivio di metadati offline

Archiviazione contenitori di Azure usa etcd, un archivio chiave-valore affidabile distribuito, per archiviare e gestire i metadati dei volumi per supportare le operazioni di orchestrazione del volume. Per la disponibilità elevata e la resilienza, etcd viene eseguito in tre pod. Quando sono in esecuzione meno di due etcd istanze, Archiviazione Azure Container interrompe le operazioni di orchestrazione del volume, consentendo comunque l'accesso ai dati ai volumi. Archiviazione di Container Azure rileva automaticamente quando un'istanza di etcd è offline e la recupera. Tuttavia, se si notano errori di orchestrazione del volume dopo il riavvio di un cluster del servizio Azure Kubernetes, è possibile che un'istanza etcd non sia riuscita a eseguire il salvataggio automatico. Seguire le istruzioni riportate in questa sezione per determinare lo stato di integrità delle istanze di etcd.

Eseguire il comando seguente per ottenere un elenco di pod.

kubectl get pods

L'output potrebbe essere simile al seguente.

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

Descrivere il pod:

kubectl describe pod fiopod

In genere, vengono visualizzati messaggi di errore del volume se l'archivio metadati è offline. In questo esempio fiopod si trova nello stato ContainerCreating e l’avviso FailedAttachVolume indica che la creazione è in sospeso a causa di un errore di collegamento del 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

È anche possibile eseguire il comando seguente per controllare lo stato delle istanze etcd:

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

L'output dovrebbe essere simile al seguente, con tutte le istanze nello stato In esecuzione:

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

Se sono in esecuzione meno di due istanze, il volume non viene collegato perché l'archivio metadati è offline e il ripristino automatico non è riuscito. In tal caso, inviare un ticket di supporto con il supporto tecnico di Azure.

Vedi anche

Domande frequenti su Azure Container Storage

Condividi tramite