Comment créer et résoudre les problèmes de provisionnement de volumes tenant compte de la topologie qui utilise un pilote EBS CSI dans Amazon EKS ?

Brève description

Pour configurer et dépanner une topologie d'infrastructure cloud dans Amazon EKS qui utilise des composants Amazon EBS, procédez comme suit :

1. Vérifiez que le module complémentaire EBS CSI est correctement configuré.
2. Configurez la classe de stockage avec une implémentation tenant compte de la topologie.
3. Créez un pod et une charge de travail, puis testez un scénario prenant en compte la topologie.
4. Résolvez les erreurs du contrôleur EBS CSI.

Résolution

Remarque : Si vous recevez des erreurs lors de l'exécution des commandes de l'interface de la ligne de commande AWS (AWS CLI), assurez-vous que vous utilisez la version la plus récente de l'interface de ligne de commande AWS.

Vérifiez que le module complémentaire EBS CSI est correctement configuré

Remarque : Il est recommandé d'utiliser le provisionneur EBS CSI ebs.csi.aws.com pour le provisionnement des volumes EBS. Utilisez également le provisionneur CSI EBS pour implémenter des volumes sensibles à la topologie au lieu du provisionneur Kubernetes intégré à l'arborescence kubernetes.io/aws-ebs.

Pour vérifier que le module complémentaire EBS CSI est correctement configuré, procédez comme suit :

1. Vérifiez si le pilote CSI est installé. S'il n'est pas installé, consultez le pilote CSI Amazon EBS pour l'installer.

2. Vérifiez que le rôle AWS Identity and Access Management (IAM) sur le compte de service dispose des autorisations d'action minimales sur le volume EBS.

Remarque : Vous devez annoter le compte de service avec les rôles IAM pour les comptes de service (IRSA). Si vous n'annotez pas le compte de service avec IRSA, le pilote CSI Amazon EBS assume le rôle IAM sur le composant master par défaut. Si le pilote CSI utilise par défaut le rôle IAM sur le composant master, configurez les autorisations de rôle IAM requises dans la console de gestion AWS.

Configuration de la classe de stockage avec une implémentation tenant compte de la topologie

1. Exécutez la commande suivante pour déployer la classe de stockage. Modifiez le manifeste selon vos besoins de déploiement spécifiques.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/storageclass.yaml

Exemple de manifeste :

Remarque : Remplacez les attributs du manifeste par des attributs spécifiques à votre cas d'utilisation.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "true"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - us-east-2c

Remarque : Pour une implémentation prenant en compte la topologie, assurez-vous de configurer l'option AllowedTopologies. La suppression de cette option permet de déduire la zone de disponibilité correcte et de créer par le contrôleur CSI Amazon EBS un volume dans lequel le pod est planifié.

2. Utilisez l'une des options suivantes pour créer une réclamation PV :

(Option 1) Créez un pv-claim qui demande un volume avec le type de profil spécifié dans le manifeste de classe de stockage déployé :

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/claim.yaml

(Option 2) Créez un pv-claim qui utilise un volume EBS disponible spécifié dans le manifeste du volume persistant. Assurez-vous de modifier l'option StorageClassName : en une chaîne vide**, « », ** et modifiez le bloc NodeAffinity selon vos besoins.

kubectl apply -f https://github.com/kubernetes-sigs/aws-ebs-csi-driver/tree/master/examples/kubernetes/static-provisioning/manifests

Remarque : Pour l'option 1 ou l'option 2, si les nœuds ne sont pas disponibles dans la zone de disponibilité du volume, le déploiement échoue. Cela est dû au fait que le planificateur ne peut pas s'adapter dynamiquement à la restriction topologique.

Créez un pod et une charge de travail et testez un scénario prenant en compte la topologie

Création d'un pod

1. Créez un pod de test qui utilise la version précédente de pv-claim :

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-ebs-csi-driver/master/examples/kubernetes/storageclass/manifests/pod.yaml

Remarque : Lorsque vous utilisez topology.ebs.csi.aws.com/zone dans ** AllowedTopologies** au sein d'une classe de stockage ou d'un volume persistant, le pod est placé dans la zone de disponibilité spécifiée dans les manifestes de configuration. Si aucun nœud n'est disponible dans cette zone de disponibilité, le pod reste bloqué dans l'état En attente.

2. Exécutez les commandes pod obtenir et décrire suivantes pour vérifier l'état du déploiement :

kubectl get pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

Remarque : Remplacez EXAMPLE \ _POD \ _NAME par le nom de votre pod.

Création d'une charge de travail

1. Exécutez la commande suivante pour créer une charge de travail StatefulSet qui utilise la version précédente de pv-claim :

kubectl apply -f https://gist.githubusercontent.com/AbeOwlu/b8641d2f58810789986ab775f00c7780/raw/9144ae5385dfd98d4739e99983346fbdd28eaa2d/statefulset.yaml

2. Exécutez la commande obtenir et décrire suivante pour vérifier l'état de la charge de travail StatefulSet :

kubectl get statefulset,pod,pvc,pv

kubectl describe pod <EXAMPLE_POD_NAME>

Remarque : Le contrôleur StatefulSet crée des claims PV pour répondre à la demande de volume des pods pour les volumes dans les régions AWS us-east-2b et us-east-2c. En cas de résiliation, il n'est pas garanti que StatefulSets nettoie les volumes persistants, ce qui pourrait empêcher le reprovisionnement des volumes pour les pods StatefulSet reprogrammés vers une autre zone de disponibilité.

Tester un scénario tenant compte de la topologie

(Facultatif) Pour tester la manière dont le remplacement des nœuds dans une autre zone de disponibilité est géré, simulez le remaniement des nœuds en réduisant le nombre de nœuds dans la zone de disponibilité spécifiée. Ensuite, augmentez la taille de nouveaux nœuds dans une autre zone de disponibilité. Lorsque vous avez terminé, consultez la section Créer un pod et Créer une charge de travail.

Exemple de sortie sur un problème de déploiement simulé :

from: default-scheduler : message: 0/4 nodes are available: 1 node(s) had volume node affinity conflict, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate.

Pour corriger le pod bloqué, redimensionnez un nœud dans la zone de disponibilité spécifiée afin de résoudre l'erreur de conflit d'affinité entre nœuds de volume.

Remarque : Lors de la mise à l'échelle d'un nouveau nœud dans la zone de disponibilité prévue, le déploiement peut échouer en raison de l'échec de l'exécution du réconciliateur. Pour connaître les étapes de résolution des problèmes, consultez la section suivante, Résoudre les erreurs du contrôleur EBS CSI.

Résoudre les erreurs du contrôleur EBS CSI

Exemple d'erreur CSI EBS lors de laquelle le taux de désabonnement des pods et le recyclage des nœuds ont été simulés :

from: default-scheduler : message: 0/5 nodes are available: 1 node(s) didn't find available persistent volumes to bind, 1 node(s) didn't match Pod's node affinity/selector, 3 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate

1. Pour identifier le problème, décrivez le module et consultez les entrées du journal des erreurs relatives à l'événement. Dans l'exemple d'erreur précédent, le message indique que quatre nœuds sur cinq ne peuvent pas être planifiés en raison de leur altération et de leur topologie ou de leur configuration d'affinité. De plus, le dernier nœud s'exécutant dans la zone de disponibilité appropriée n'a pas trouvé de volume persistant disponible à lier.

2. Pour isoler ce problème, vérifiez l'état de la liaison pv-claim :

kubectl describe persistentvolumeclaim <PVC_NAME>

Remarque : Les statuts de pv-claim sont en attente, liés, non valides ou introuvables. Dans l'exemple suivant, le pv-claim attend que le pilote crée un volume. Pendant qu'il attend, le pv-claim ne se lie pas à un nœud cible.

`from: ebs.csi.aws.com_ebs-csi-controller- : message:  failed to get target node: node "ip-10-0-60-85.ec2.internal" not found`  
`waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator`

3. Consultez les journaux du conteneur csi-provisioner dans le pod ebs-csi-controller :

kubectl logs ebs-csi-controller-<RANDOM_HASH> -c csi-provisioner -n kube-system

La sortie suivante est un exemple d'événement d'erreur :

Retrying syncing claim "claim-id", failure 343 error syncing claim "claim-id": failed to get target node: node "ip-10-0-60-85.ec2.internal" not found

Remarque : Si des événements d'erreur similaires au message précédent se produisent, le réconciliateur pv-claim n'a pas trouvé l'annotation du nœud cible sélectionné. Supprimez cette annotation afin que le pv-claim puisse être correctement synchronisé.

4. Pour supprimer l’annotation du nœud cible sélectionné, exécutez la commande suivante. Assurez-vous de copier et d'enregistrer la sortie dans le manifeste pv-claim pour supprimer l'annotation du nœud sélectionné.

kubectl edit  persistentvolumeclaims ebs-claim | grep -v "volume.kubernetes.io/selected-node:"

Si les étapes de dépannage suivantes ne résolvent pas votre problème, rassemblez les journaux de la charge de travail isolée du conteneur et contactez AWS Support. Vous pouvez également rechercher des problèmes connexes sur le référentiel GitHub.