Résoudre les problèmes liés au stockage dans Azure Container Storage

Article
12/19/2024

Azure Container Storage est un service cloud de gestion, de déploiement et d’orchestration de volumes conçu de manière native pour les conteneurs. Utilisez cet article pour résoudre les problèmes courants liés à Azure Container Storage et trouver des solutions aux problèmes.

Résoudre les problèmes d’installation

Impossible d’installer le Stockage de conteneurs Azure en raison d’une configuration manquante

Une fois l’exécution terminée az aks create, le message Impossible d’installer Azure Container Storage s’affiche. Le cluster AKS est créé. Exécutez az aks update avec --enable-azure-container-storage pour activer Azure Container Storage.

Ce message signifie qu’Azure Container Storage n’a pas été installé, mais que votre cluster AKS (Azure Kubernetes Service) a été créé correctement.

Pour installer Azure Container Storage sur le cluster et créer un pool de stockage, exécutez la commande suivante. Remplacez <cluster-name> et <resource-group> par vos propres valeurs. Remplacez <storage-pool-type> par azureDisk, ephemeraldisk ou elasticSan.

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

Impossible d’installer le Stockage de conteneurs Azure en raison de restrictions d’Azure Policy

L’installation d’Azure Container Storage peut échouer si des restrictions d’Azure Policy sont en place. Plus précisément, Azure Container Storage s’appuie sur des conteneurs privilégiés. Vous pouvez configurer Azure Policy pour bloquer les conteneurs privilégiés. Lorsqu'ils sont bloqués, l'installation d'Azure Container Storage peut expirer ou échouer, et vous pouvez voir des erreurs dans les journaux gatekeeper-controller telles que :

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

Pour résoudre le blocage, vous devez ajouter l’espace de noms acstor à la liste d’exclusion de votre stratégie Azure. Azure Policy est utilisé pour créer et appliquer des règles de gestion des ressources au sein d’Azure, y compris les clusters AKS. Dans certains cas, les stratégies peuvent bloquer la création de pods et de composants de Stockage de conteneurs Azure. Vous pouvez trouver plus de détails sur le fonctionnement d’Azure Policy pour Kubernetes en consultant Azure Policy pour Kubernetes.

Pour ajouter l’espace de noms acstor à la liste d’exclusion, procédez de la manière suivante :

Créer votre cluster Azure Kubernetes.
Activez Azure Policy pour AKS.
Créez une stratégie que vous soupçonnez de bloquer l’installation du Stockage de conteneurs Azure.
Essayez d’installer le Stockage de conteneurs Azure dans le cluster AKS.
Vérifiez les journaux du pod gatekeeper-controller pour confirmer toute violation de stratégie.
Ajoutez l’espace de noms acstor et l’espace de noms azure-extensions-usage-system à la liste d’exclusion de la politique.
Essayez une nouvelle fois d’installer le Stockage de conteneurs Azure dans le cluster AKS.

Impossible d'installer et d'activer Azure Container Storage dans des pools de nœuds avec des taches

Vous pouvez configurer des taches de nœuds sur les pools de nœuds pour empêcher la planification des pods sur ces pools de nœuds. L’installation et l’activation d’Azure Container Storage sur ces pools de nœuds peuvent être bloquées car les pods requis ne peuvent pas être créés dans ces pools de nœuds. Le comportement s'applique à la fois au pool de nœuds système lors de l'installation et aux pools de nœuds utilisateur lors de l'activation.

Vous pouvez vérifier les taches de nœuds avec l'exemple suivant :

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

Vous pouvez supprimer temporairement ces souillures pour les débloquer et les reconfigurer après les avoir installées et activées avec succès. Vous pouvez accéder aux pools de nœuds du cluster > Azure Portal AKS >, cliquer sur votre pool de nœuds, supprimer les souillures dans la section « Souillures et étiquettes ». Ou vous pouvez utiliser la commande suivante pour supprimer les souillures et confirmer la modification.

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

Réessayez l'installation ou l'activation après avoir supprimé avec succès les taches de nœud. Une fois l'opération terminée avec succès, vous pouvez reconfigurer les nœuds contaminés pour reprendre les contraintes de planification du pod.

Impossible de définir le type de pool de stockage sur NVMe

Si vous essayez d’installer Azure Container Storage avec un disque éphémère, en particulier avec NVMe local sur un cluster où la référence SKU de la machine virtuelle ne dispose pas de lecteurs NVMe, vous obtenez le message d’erreur suivant : Impossible de définir --storage-pool-option comme NVMe, car aucun des pools de nœuds ne peut prendre en charge le disque NVMe éphémère.

Pour corriger ce problème, créez un pool de nœuds avec une référence SKU de machine virtuelle qui possède des lecteurs NVMe et réessayez. Consultez Machines virtuelles à stockage optimisé.

Résoudre les problèmes de pool de stockage

Pour vérifier l’état de vos pools de stockage, exécutez kubectl describe sp <storage-pool-name> -n acstor. Voici quelques problèmes que vous pourriez rencontrer.

Le pool de stockage éphémère ne revendique pas la capacité lorsque les disques éphémères sont utilisés par d'autres ensembles de démons

L'activation d'un pool de stockage éphémère sur un pool de nœuds avec des disques SSD temporaires ou NVMe locaux peut ne pas réclamer de capacité à partir de ces disques si d'autres ensembles de démons les utilisent.

Exécutez les étapes suivantes pour permettre à Azure Container Storage de gérer exclusivement ces disques locaux :

Exécutez la commande suivante pour voir la capacité revendiquée par pool de stockage éphémère :
```
$ kubectl get sp -A
NAMESPACE   NAME                 CAPACITY   AVAILABLE   USED   RESERVED   READY   AGE
acstor      ephemeraldisk-nvme   0          0           0      0          False   82s
```
Cet exemple montre une capacité nulle revendiquée par le pool de stockage ephemeraldisk-nvme.

Exécutez la commande suivante pour confirmer l’état non réclamé de ces périphériques de bloc locaux et vérifier le système de fichiers existant sur les disques :

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

Cet exemple montre que les périphériques de bloc sont en état Unclaimed et qu'il existe un système de fichiers sur le disque.

Confirmez que vous souhaitez utiliser Azure Container Storage pour gérer exclusivement les disques de données locaux avant de continuer.
Arrêtez et supprimez les daemonsets ou les composants qui gèrent les disques de données locaux.
Connectez-vous à chaque nœud disposant de disques de données locaux.
Supprimez les systèmes de fichiers existants de tous les disques de données locaux.

Redémarrez ndm daemonset pour découvrir les disques de données locaux inutilisés.

$ 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

Attendez quelques secondes et vérifiez si le pool de stockage éphémère revendique la capacité des disques de données locaux.

$ 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

Cet exemple montre que le pool de stockage ephemeraldisk-nvme revendique avec succès la capacité des disques NVMe locaux sur les nœuds.

Erreur lors de la tentative d’extension d’un pool de stockage Disques Azure

Si votre pool de stockage existant est inférieur à 4 Tio (4096 Gio), vous ne pouvez l’étendre qu’à 4095 Gio. Si vous essayez d'étendre au-delà de la limite, le PVC interne affiche un message d'erreur concernant les limitations de taille du disque ou de type de mise en cache. Arrêtez votre VM ou détachez le disque et réessayez l'opération.

Pour éviter les erreurs, n'essayez pas d'étendre votre pool de stockage actuel au-delà de 4 095 Gio s'il est initialement inférieur à 4 Tio (4 096 Gio). Les pools de stockage de taille supérieure à 4 Tio peuvent être étendus jusqu’à la capacité de stockage maximale disponible.

Cette limitation s’applique uniquement lors de l’utilisation des références SKU de disque Premium_LRS, Standard_LRS, StandardSSD_LRS, Premium_ZRS et StandardSSD_ZRS.

Échec de la création de Elastic SAN

Si vous essayez de créer un pool de stockage Elastic SAN, vous pourriez voir le message « Échec de la création de Azure Elastic SAN : nombre maximal possible de Elastic SAN pour l’abonnement déjà créé » s’afficher. Cela signifie que vous atteignez la limite du nombre de ressources Elastic SAN pouvant être déployées dans une région par abonnement. Vous pouvez vérifier la limite ici : objectifs de scalabilité et de performances de Elastic SAN. Envisagez de supprimer de l’abonnement les ressources Elastic SAN existantes qui ne sont plus utilisées, ou essayez de créer le pool de stockage dans une autre région.

Aucun appareil de bloc trouvé

Si vous voyez ce message, vous essayez probablement de créer un pool de stockage de disque éphémère sur un cluster où la référence SKU de machine virtuelle ne dispose pas de lecteurs NVMe.

Pour corriger ce problème, créez un pool de nœuds avec une référence SKU de machine virtuelle qui possède des lecteurs NVMe et réessayez. Consultez Machines virtuelles à stockage optimisé.

Type de pool de stockage déjà activé

Si vous essayez d’activer un type de pool de stockage existant, vous obtenez le message suivant : Valeur Non valide --enable-azure-container-storage. Azure Container Storage est déjà activé pour le type de pool de stockage <storage-pool-type> dans le cluster. Vous pouvez vérifier si vous disposez de pools de stockage existants créés en exécutant kubectl get sp -n acstor.

Désactivation d’un type de pool de stockage

Lors de la désactivation d’un type de pool de stockage via az aks update --disable-azure-container-storage <storage-pool-type> ou de la désinstallation d’Azure Container Storage via az aks update --disable-azure-container-storage all, s’il existe un pool de stockage existant de ce type, le message suivant s’affiche :

La désactivation d’Azure Container Storage pour le type de pool de stockage <storage-pool-type> supprime de force tous les pools de stockage du même type et affecte les applications utilisant ces pools de stockage. La suppression forcée des pools de stockage peut également entraîner une fuite des ressources de stockage qui sont consommées. Souhaitez-vous vérifier si l’un des pools de stockage de type <storage-pool-type> est utilisé avant de désactiver Azure Container Storage ? (O/N)

Si vous sélectionnez Y, une validation automatique s’exécute pour vous assurer qu’il n’existe aucun volume persistant créé à partir du pool de stockage. La sélection de n contourne cette validation et désactive le type de pool de stockage, en supprimant les pools de stockage existants et en affectant potentiellement votre application.

Résoudre les problèmes de volume

Pod en attente de création en raison d'une taille de volume éphémère supérieure à la capacité disponible

Un volume éphémère est alloué sur un nœud unique. Lorsque vous configurez la taille des volumes éphémères pour vos pods, celle-ci doit être inférieure à la capacité disponible du disque éphémère d'un seul nœud. Sinon, la création du pod est en attente.

Utilisez la commande suivante pour vérifier si la création de votre pod est en attente d’état.

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

Dans cet exemple, le pod fiopod est dans l’état Pending.

Utilisez la commande suivante pour vérifier si le pod a l’événement d’avertissement pour la création de 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..

Dans cet exemple, le pod montre l'événement d'avertissement lors de la création du volume persistant revendication fiopod-ephemeralvolume.

Utilisez la commande suivante pour vérifier si la revendication de volume persistant ne parvient pas à provisionner en raison d’une capacité insuffisante.

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

Dans cet exemple, Insufficient Storage il s’agit de la raison de l’échec de l’approvisionnement en volume.

Exécutez la commande suivante pour vérifier la capacité disponible du disque éphémère d'un seul nœud.

$ 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

Dans cet exemple, la capacité disponible du disque temporaire pour un nœud unique est de 75031990272 octets ou 69 Gio.

Ajustez la taille de stockage du volume en dessous de la capacité disponible et redéployez votre pod. Consultez Déployer un pod avec un volume éphémère générique.

Le volume ne parvient pas à s’attacher en raison d’un magasin de métadonnées hors connexion

Le Stockage de conteneurs Azure utilise etcd, un magasin de paires clé-valeur distribué et fiable, pour stocker et gérer les métadonnées des volumes afin de prendre en charge les opérations d’orchestration des volumes. Pour la haute disponibilité et la résilience, etcd s’exécute dans trois pods. Lorsqu’il y a moins de deux instances etcd en cours d’exécution, Azure Container Storage arrête les opérations d’orchestration des volumes tout en autorisant l’accès aux données aux volumes. Le Stockage de conteneurs Azure détecte automatiquement lorsqu’une instance de etcd est hors connexion et la récupère. Cependant, si vous remarquez des erreurs d’orchestration de volume après le redémarrage d’un cluster AKS, il est possible qu’une instance etcd n’ait pas réussi à récupérer automatiquement. Suivez les instructions de cette section pour déterminer l’état d’intégrité des instances de etcd.

Exécutez la commande suivante pour obtenir la liste des pods.

kubectl get pods

Vous pouvez voir un résultat similaire à ce qui suit.

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

Décrire le pod :

kubectl describe pod fiopod

En règle générale, vous voyez des messages d’échec de volume si le magasin de métadonnées est hors ligne. Dans cet exemple, fiopod est dans l’état ContainerCreating et l’avertissement FailedAttachVolume indique que la création est en attente en raison d’un échec d’attachement de 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

Vous pouvez également exécuter la commande suivante pour vérifier l’état des instances de etcd :

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

Vous devez voir une sortie similaire à ce qui suit, avec toutes les instances dans l’état en cours d’exécution :

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

Si moins de deux instances sont en cours d'exécution, le volume ne se connecte pas car le magasin de métadonnées est hors ligne et la récupération automatique a échoué. Si tel est le cas, déposez un ticket d'assistance auprès du Support Azure.

Voir aussi

FAQ relative à Azure Container Storage

Partager via