Résoudre les problèmes liés au stockage dans Azure Container Storage
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éé. Veuillez exécuter az aks update avec --enable-azure-container-storage pour activer Container Storage.
Ce message signifie qu’Azure Container Storage n’a pas été installé, mais que votre cluster AKS a été créé comme il convient.
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, le Stockage de conteneurs Azure s’appuie sur des conteneurs privilégiés, qui peuvent être bloqués par Azure Policy. Lorsque cela se produit, l’installation du Stockage de conteneurs Azure peut être interrompue ou échouer, et vous pouvez rencontrer des erreurs dans les journaux gatekeeper-controller, comme par exemple :
{"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 ce problème, vous devrez ajouter l’espace de noms acstor à la liste d’exclusion de votre Azure Policy. 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.
- Ajouter l’espace de noms
acstorà la liste d’exclusion de la stratégie. - Essayez une nouvelle fois d’installer le Stockage de conteneurs Azure dans le cluster AKS.
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.
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 cela, le PVC interne obtient un message d’erreur tel que « Seul le CachingType de disque « None » est pris en charge pour le disque dont la taille est supérieure à 4095 Go » ou « Le disque « xxx » de taille 4096 Go (<=4096 Go) ne peut pas être redimensionné à 16384 Go (>4096 Go) alors qu’il est attaché à une machine virtuelle en cours d’exécution. Arrêtez votre machine virtuelle ou détachez le disque, puis réessayez l’opération. »
Pour éviter les erreurs, n’essayez pas d’étendre votre pool de stockage actuel au-delà de 4095 Gio s’il est initialement inférieur à 4 Tio (4096 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. L’affichage de ce message signifie que vous avez atteint la limite du nombre de ressources Elastic SAN qui peuvent ê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 déjà activé, 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 <storage-pool-type> de pool de stockage supprime de manière forcée 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.
Impossible de supprimer le groupe de ressources contenant un cluster AKS
Si vous avez créé un pool de stockage Elastic SAN, il se peut que vous ne puissiez pas supprimer le groupe de ressources dans lequel se trouve votre cluster AKS.
Pour résoudre ce problème, connectez-vous au portail Azure, puis sélectionnez Groupes de ressources. Recherchez le groupe de ressources créé par AKS (le nom du groupe de ressources commence par MC_). Sélectionnez l’objet de ressource SAN dans ce groupe de ressources. Supprimez manuellement tous les volumes et groupes de volumes. Réessayez ensuite de supprimer le groupe de ressources qui inclut votre cluster AKS.
Résoudre les problèmes de volume
Création en attente de pod 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 existe moins de deux instances de etcd en cours d’exécution, le Stockage de conteneurs Azure interrompt les opérations d’orchestration des volumes tout en autorisant les volumes à accéder aux données. Le Stockage de conteneurs Azure détecte automatiquement lorsqu’une instance de etcd est hors connexion et la récupère. Toutefois, si vous remarquez des erreurs d’orchestration des volumes après le redémarrage d’un cluster AKS, il est possible qu’une instance de etcd n’ait pas pu 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 voyez une sortie 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, des messages d’échec du volume s’affichent si le magasin de métadonnées est hors connexion. 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 affichées dans l’état en cours d’exécution, vous pouvez conclure que le volume n’est pas en mesure de s’attacher parce que le magasin de métadonnées est hors connexion et que la récupération automatisée n’a pas réussi. Si c’est le cas, déposez un ticket de support auprès du support Azure.