Comment résoudre les problèmes liés au plug-in CNI Amazon VPC pour Amazon EKS ?

Résolution

Amazon EKS requiert une attribution appropriée d’adresses IP de pod pour que le plug-in Container Network Interface (CNI) Amazon Virtual Private Cloud (Amazon VPC) fonctionne correctement. Pour résoudre les problèmes liés au plug-in CNI VPC, vérifiez les configurations suivantes :

• Autorisations Gestion des identités et des accès AWS (AWS IAM), y compris une politique AmazonEKS_CNI_Policy associée aux rôles IAM du composant master. Ou encore, les autorisations IAM que vous fournissez via les rôles IAM du compte de service.
• Un point de terminaison du serveur API Amazon EKS accessible depuis le composant master.
• Un accès réseau aux points de terminaison d'API pour Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Registry (Amazon ECR) et Amazon Simple Storage Service (Amazon S3).
• Un nombre suffisant d'adresses IP disponibles dans vos sous-réseaux.
• Un kube-proxy qui s'exécute correctement pour que le pod aws-node passe à l'état Prêt.
• Version Kube-proxy et Version du CNI VPC alignées sur la version du cluster Amazon EKS.

Effectuez les étapes de dépannage suivantes pour résoudre les problèmes liés au plug-in CNI VPC.

Vérifier que le pod aws-node est à l’état En cours d'exécution

Le plug-in CNI VPC s'exécute en tant que pod DaemonSet appelé aws-node dans l'espace de noms kube-system. Un pod aws-node s'exécute sur chaque composant master de votre cluster.

1. Pour vérifier que le pod aws-node est exécuté sur chaque composant master, exécutez la commande suivante :

   kubectl get pods -n kube-system -l k8s-app=aws-node -o wide

   Remarque : remplacez k8s-app=aws-node par votre sélecteur d'étiquette.

2. Si la sortie de la commande indique que le nombre de REDÉMARRAGES est supérieur à 0, vérifiez l'état des conteneurs et des messages d'erreur. Exécutez la commande describe suivante :

   kubectl describe pod aws-node-pod-name -n kube-system

   Remarque : remplacez aws-node-pod-name par le nom du pod de nœud AWS.

3. Si le pod aws-node est bloqué dans un état ContainerCreating et la sortie describe affiche le message d'erreur suivant dans les événements :

   « Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused »

   Puis, effectuez les étapes de la section Pour quelles raisons mon pod Amazon EKS est-il bloqué à l’état ContainerCreating avec l’erreur « failed to create pod sandbox » ?

4. Pour afficher les journaux du pod aws-node, exécutez les commandes de journaux suivantes :

   kubectl logs daemonset/aws-node -n kube-system

   -ou-

   kubectl logs aws-node-pod-name -n kube-system

   Remarque : remplacez aws-node-pod-name par le nom de pod aws-node.

5. Consultez les journaux du plug-in CNI de VPC sur le composant master. Connectez-vous au composant master, puis accédez au répertoire /var/log/aws-routed-eni/. Recherchez les noms de fichiers plugin.log et ipamd.log, puis vérifiez les journaux de ces fichiers.

6. Vérifiez que les composants master peuvent atteindre le point de terminaison du serveur API de votre cluster Amazon EKS. Pour vous connecter à votre composant master, utilisez SSH ou AWS Systems Manager Session Manager, puis exécutez la commande suivante :

   curl -ivk https://eks-api-server-endpoint-url

   Remarque : remplacez eks-api-server-endpoint-url par l'URL de point de terminaison de votre serveur d'API Amazon EKS.

Vérifier la version du CNI VPC

Vérifiez que la version du plug-in CNI VPC est à jour et compatible avec la version du cluster Amazon EKS.

Pour vérifier la version actuelle du CNI VPC, exécutez la commande suivante :

kubectl describe daemonset aws-node -n kube-system | grep Image | cut -d "/" -f 2

Comparez votre version actuelle avec la dernière version disponible dans la page versions du plug-in CNI Amazon VPC sur le site Web de GitHub.

Si votre version est obsolète, mettez à jour le plug-in du CNI VPC vers la dernière version. Pour plus d'informations, consultez la section Mettre à jour le CNI Amazon VPC (module complémentaire Amazon EKS).

Vérifier la configuration et les exigences du réseau

Vérifiez que les configurations de sous-réseau et de groupe de sécurité de votre cluster Amazon EKS sont correctement configurées.

Vérifier les règles des groupes de sécurité

Les groupes de sécurité doivent autoriser la connectivité entre le plan de contrôle et le plan de données.

Si vous utilisez un groupe de sécurité personnalisé pour les composants master, vérifiez les ports. Les règles de groupe de nœuds minimales autorisent le port 10250 entrant depuis le groupe de sécurité du plan de contrôle et le port 443 sortant vers le groupe de sécurité du plan de contrôle. Pour plus d’informations, consultez la section Sécurité du réseau.

Si la fonction de groupe de sécurité du pod est active, vérifiez si les limites du groupe de sécurité ont été atteintes. Si vous atteignez les limites de votre groupe de sécurité par interface réseau Elastic, la configuration réseau de votre pod peut échouer. Pour plus d'informations, consultez la section Quotas Amazon VPC.

Pour plus d'informations sur les règles de groupe de sécurité requises, consultez la section Afficher les exigences des groupes de sécurité Amazon EKS pour les clusters.

Vérifier la configuration du sous-réseau

Pour répertorier les adresses IP disponibles dans chaque sous-réseau de l'identifiant Amazon VPC, exécutez la commande suivante :

aws ec2 describe-subnets —filters "Name=vpc-id,Values= VPCID" | jq '.Subnets[] | .SubnetId + "=" + "\(.AvailableIpAddressCount)"'

Vérifiez que les règles de liste de contrôle d'accès au réseau (ACL réseau) du composant master de votre sous-réseau autorisent la communication avec le serveur API Amazon EKS. Pour plus d'informations sur la procédure de configuration des ACL réseau, consultez la section Contrôler le trafic de sous-réseau à l'aide de listes de contrôle d'accès au réseau.

Vérifiez que les sous-réseaux du plan de contrôle ont un nombre suffisant d'adresses IP disponibles. Chaque sous-réseau du plan de contrôle doit disposer d'au moins six adresses IP qu'Amazon EKS peut utiliser. Toutefois, AWS recommande que chaque sous-réseau dispose d’au moins 16 adresses IP. La métrique AvailableIpAddressCount doit être supérieure à 0 pour le sous-réseau sur lequel les pods sont lancés. Pour plus d'informations, consultez la section Exigences et considérations relatives aux sous-réseaux.

Vérifier que le pod kube-proxy est à l’état En cours d'exécution

Le pod kube-proxy doit être en cours d'exécution pour une connectivité réseau appropriée.

Pour vérifier que le kube-proxy est en cours d'exécution, exécutez la commande suivante :

kubectl get pods -n kube-system -l k8s-app=kube-proxy

Vérifiez que tous les pods kube-proxy sont à l’état En cours d'exécution. Si le kube-proxy n'est pas en cours d'exécution, vérifiez la présence d'erreurs dans les journaux du pod :

kubectl logs -n kube-system POD-NAME

Remarque : remplacez POD-NAME par le nom du pod kube-proxy.

Vérifier la valeur de WARM_PREFIX_TARGET

Si la délégation de préfixe est activée, vérifiez la présence du message d’erreur suivant dans le fichier journal :

« Error: Setting WARM_PREFIX_TARGET = 0 is not supported while WARM_IP_TARGET/MINIMUM_IP_TARGET is not set. Please configure either one of the WARM_{PREFIX/IP}_TARGET or MINIMUM_IP_TARGET env variable »

Pour résoudre cette erreur, WARM_PREFIX_TARGET doit être défini sur une valeur supérieure ou égale à 1. Si la délégation de préfixes est activée et que WARM_PREFIX_TARGET est défini sur 0, mettez la valeur à jour à 1 minimum :

kubectl set env daemonset aws-node -n kube-system WARM_PREFIX_TARGET=1

Vérifier l'espace réservé dans le sous-réseau

Lorsque la délégation de préfixe est activée, vérifiez que vos sous-réseaux disposent d'un nombre suffisant de blocs d'adresses CIDR /28 IP. Les 16 adresses IP doivent être contiguës. Si la délégation de préfixe est activée, vérifiez la présence du message d’erreur suivant dans le fichier journal :

« InsufficientCidrBlocks:

Pour résoudre l'erreur, créez un nouveau sous-réseau, puis lancez les pods à partir de ce dernier. Utilisez une réservation de sous-réseau CIDR Amazon EC2 pour réserver de l'espace au sein d'un sous-réseau auquel un préfixe est attribué. Pour plus d'informations, reportez-vous à la section Réservations de sous-réseau CIDR.

Vérifier la configuration réseau personnalisée

Pour déterminer si la mise en réseau personnalisée est active pour votre cluster Amazon EKS, exécutez la commande suivante :

kubectl describe pod -n kube-system $(kubectl get pods -n kube-system -l k8s-app=aws-node -o jsonpath='{.items[0].metadata.name}')

Si cette variable est définie sur True, la mise en réseau personnalisée est active.

Si la mise en réseau personnalisée est active, les CRD ENIConfig doivent être correctement configurés pour répondre aux exigences réseau du cluster. Exécutez la commande suivante pour récupérer une liste et inspecter tous les CRD ENIConfig :

kubectl get ENIConfig -A -o yaml

Pour décrire un ENIConfig spécifique, exécutez la commande suivante :

kubectl describe ENIConfig eni-config-name

Remarque : remplacez Eni-config-name par le nom ENIConfig.

Vérifiez que chaque ENIConfig utilise la configuration de sous-réseau et de groupe de sécurité appropriée pour chaque zone de disponibilité.

Vérifiez que le sous-réseau spécifié dans l'ENIConfig correspond à la zone de disponibilité de vos composants master.

Pour plus d'informations sur la mise en réseau personnalisée, consultez la section Déployer des pods dans des sous-réseaux alternatifs dotés d'un réseau personnalisé.

Configurer la résolution des conflits pour éviter les restaurations

Lorsque vous utilisez AWS Cloud Development Kit (AWS CDK), AWS CloudFormation ou eksctl avec des modules complémentaires gérés, définissez une méthode de résolution de conflits pour éviter les restaurations.

Les méthodes correctes sont NONE, OVERWRITE ou PRESERVE.

• Si aucune méthode n'est définie, la valeur par défaut est NONE. Lorsque le système détecte des conflits, la mise à jour de la pile CloudFormation est annulée et aucune modification n'est apportée.
• Pour définir la configuration par défaut des modules complémentaires, utilisez la méthode de remplacement. Vous devez utiliser OVERWRITE lorsque vous passez d'un module complémentaire autogéré à un module complémentaire géré par Amazon EKS.
• Utilisez la méthode PRESERVE lorsque vous utilisez des configurations personnalisées, telles que WARM_IP_TARGET ou un réseau personnalisé.

Pour plus d'informations sur la définition des méthodes de résolution de conflits, consultez, la section Mettre à jour un module complémentaire Amazon EKS.