Passer au contenu

Comment résoudre les problèmes liés au module complémentaire CNI d’Amazon VPC pour Amazon EKS ?

Lecture de 9 minute(s)
0

Je souhaite utiliser le module complémentaire Interface réseau de conteneur (CNI) d’Amazon Virtual Private Cloud (Amazon VPC) sur mes clusters Amazon Elastic Kubernetes Service (Amazon EKS). Cependant, je reçois des erreurs.

Résolution

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l'interface.

Si le composant master n'est pas prêt parce que le module complémentaire CNI d’Amazon VPC n'a pas été initialisé, vous recevez un message d'erreur similaire à l'exemple suivant :

« container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized » (le réseau d'exécution du conteneur n'est pas prêt : NetworkReady=false motif : NetworkPluginNotReady message : le plug-in de réseau renvoie une erreur : plug-in cni non initialisé)

Pour vérifier ce problème, exécutez la commande suivante :

kubectl describe node node_name

Remarque : Remplacez node_name par le nom du nœud. Vous pouvez trouver le message d'erreur plug-in cni non initialisé dans la sortie.

Procédez comme suit pour résoudre ce problème.

Vérifier que vous avez installé le module complémentaire CNI Amazon VPC

Si les pods aws-node du cluster sont manquants, vous recevez un message d'erreur similaire à l'exemple suivant dans les journaux containerd :

« cni config load failed: no network config found in /etc/cni/net.d: cni plugin not initialized: failed to load cni config » (échec de configuration de cni : aucune configuration de réseau détectée dans /etc/cni/net.d : plug-in de cni non initialisé : échec de chargement de la configuration de cni)

Pour résoudre ce problème, installez le module complémentaire CNI d’Amazon VCP.

Vérifier les problèmes liés aux autorisations IAM

Pour utiliser le module complémentaire CNI d’Amazon VPC, utilisez la politique gérée par Gestion des identités et des accès AWS (AWS IAM) AmazonEKS_CNI_Policy. Ou, si vous utilisez une politique personnalisée, assurez-vous qu'elle inclut les autorisations suivantes :

 "ec2:AssignPrivateIpAddresses",
 "ec2:AttachNetworkInterface",
 "ec2:CreateNetworkInterface",
 "ec2:DeleteNetworkInterface",
 "ec2:DescribeInstances",
 "ec2:DescribeTags",
 "ec2:DescribeNetworkInterfaces",
 "ec2:DescribeInstanceTypes",
 "ec2:DescribeSubnets",
 "ec2:DetachNetworkInterface",
 "ec2:ModifyNetworkInterfaceAttribute",
 "ec2:UnassignPrivateIpAddresses"
 "ec2:CreateTags"

Pour identifier les autorisations IAM manquantes, vérifiez les journaux du démon L-IPAM (IPAMD) dans le répertoire hôte /var/log/aws-routed-eni/ipamd.log. Si le module complémentaire CNI d’Amazon VPC ne dispose pas de l'autorisation IAM requise, vous recevez un message d'erreur similaire à l'exemple suivant :

{"level":"error","ts":"2023-11-18T01:08:34.083Z","caller":"aws-k8s-agent/main.go:28","msg":"Initialization failure: ipamd init: failed to retrieve attached ENIs info: ({"level":"error","ts":"2023-11-18T01:08:34.083Z","caller":"aws-k8s-agent/main.go:28","msg":"Échec d’initialisation : init ipamd : échec d’extraction des informations sur les ENI associées :) UnauthorizedOperation: You are not authorized to perform this operation. User: arn:aws:sts::XXXXXXXXXXXXXXXXXXXX:assumed-role/rolename is not authorized to perform: ec2:DescribeNetworkInterfaces because no identity-based policy allows the ec2:DescribeNetworkInterfaces action\n\tstatus code: 403, request id: request id"} (Opération non autorisée : Vous n’êtes pas autorisé à effectuer cette opération. L’utilisateur : arn:aws:sts::XXXXXXXXXXXXXXXXXXXX:assumed-role/rolename n’est pas autorisé à effectuer : ec2:DescribeNetworkInterfaces car aucune politique basée sur l’identité n’autorise l’action ec2:DescribeNetworkInterfaces action\n\tcode d’état :

L'exemple de message d'erreur précédent indique que le module complémentaire nécessite l'autorisation ec2:DescribeNetworkInterfaces.

Si vous n'avez pas d'accès direct au composant master, vérifiez les pods aws-node sur le composant master. Pour identifier le pod aws-node sur le composant master, exécutez la commande suivante :

kubectl describe node node_name

Remarque : Remplacez node_name par le nom du nœud. Consultez la section Pods non résiliés de la sortie pour le nom de pod aws-node.

Puis, exécutez la commande suivante pour afficher les détails du pod aws-node :

kubectl describe pod pod-name -n kube-system

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

Dans la sortie, cochez Événement pour obtenir des informations sur les autorisations manquantes.

Exemple de sortie :

Type Reason Age From Message
---- ------ ---- ---- -------
Warning MissingIAMPermissions 105s (x2 over 105s) aws-node Unauthorized operation: failed to call ec2:DescribeNetworkInterfaces due to missing permissions. Please refer https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/iam-policy.md to attach relevant policy to IAM role in the event section you can able to see the error message also you can check the AWS cloud trail event for the particular instance by filtering the cloudtrail with username and provide the instanceID there.

Vous pouvez également utiliser AWS CloudTrail pour vérifier la présence d'événements spécifiques. Par exemple, vérifiez le nom d'utilisateur et l'ID d'instance de l'appel d'API DescribeNetworkInterfaces pour déterminer s'il a été exécuté.

Vérifier les problèmes de réseau

Le module complémentaire CNI d’Amazon VPC doit atteindre le point de terminaison du serveur API et le point de terminaison Amazon Elastic Compute Cloud (Amazon EC2) lorsqu'il s'exécute. Si l'une des connexions échoue, le module complémentaire ne peut pas s'initialiser et les nœuds passent à l'état NotReady.

Pour vérifier le message d'erreur spécifique, consultez les journaux IPAMD dans le répertoire hôte /var/log/aws-routed-eni/ipamd.log. Assurez-vous que les pods kube-proxy et coreDNS peuvent fonctionner sans erreur.

Vérifier les versions des composants additionnels

Il est recommandé de mettre à jour les composants principaux vers la dernière version. Si la version du module complémentaire ne correspond pas à la version de votre cluster Kubernetes, le module complémentaire ne peut pas être initialisé. Assurez-vous que la version du module complémentaire est compatible avec la version du cluster Kubernetes.

Résoudre les erreurs liées au module complémentaire CNI d’Amazon VPC

Pour identifier les erreurs du module complémentaire, utilisez SSH pour vous connecter au composant master auquel le module complémentaire ne peut pas attribuer l'adresse IP. Puis, consultez les journaux IPAMD dans le fichier /var/log/aws-routed-eni/ipamd.log pour détecter les messages d'erreur.

Impossible d'attribuer une erreur IP

L'erreur Impossible d'attribuer une erreur IP se produit lorsque le module complémentaire CNI d’Amazon VPC ne peut pas attribuer d'adresses IP aux pods qui sont planifiés pour les composants master. Pour identifier l'erreur, vous pouvez également consulter la page Historique des événements CloudTrail pour l'événement AssignPrivateIpAddresses.

Pour déterminer si aucune adresse IP n'est disponible au sous-réseau attribué, exécutez la commande describe-subnets de l'interface de ligne de commande AWS suivante :

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

Remarque : Remplacez VPCID par votre ID de VPC.

L'erreur Impossible d'attribuer une erreur IP peut également se produire lorsque vous définissez les valeurs des variables d'environnement WARM_ENI_TARGET, WARM_IP_TARGET ou MINIMUM_IP_TARGET à des valeurs trop faibles. Assurez-vous que la plage d'adresses CIDR de votre sous-réseau est suffisamment étendue et comporte un nombre d’allocations d'adresses IP suffisant pour votre cas d'utilisation. Pour plus d'informations, consultez la page WARM_ENI_TARGET, WARM_IP_TARGET and MINIMUM_IP_TARGET sur le site Web de GitHub.

Pour vérifier les valeurs des variables d'environnement, exécutez la commande suivante pour afficher les détails de votre pod :

kubectl describe pod pod-name -n kube-system

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

Vous pouvez mettre à jour les variables d'environnement dans le DaemonSet aws-node :

env:
  - name: WARM_ENI_TARGET
    value: "1"
  - name: WARM_IP_TARGET
    value: "5"
  - name: MINIMUM_IP_TARGET
    value: "25"

Vous pouvez également exécuter la commande suivante pour mettre à jour les variables d'environnement :

kubectl set env ds aws-node -n kube-system WARM_ENI_TARGET=1 WARM_IP_TARGET=5 MINIMUM_IP_TARGET=25

Si vous utilisez le mode de délégation de préfixes et que vous n'utilisez pas de plage de sous-réseaux de pods dédiée, la fragmentation du sous-réseau peut entraîner l'échec du module complémentaire. Le module complémentaire doit attribuer une plage de préfixes continue /28 pour IPv4 et /80 pour IPv6 à l'interface réseau. Pour plus d'informations sur la délégation de préfixes, consultez la page ENABLE_PREFIX_DELEGATION sur le site Web de GitHub.

Vous ne pouvez pas vérifier directement la fragmentation du sous-réseau. À la place, vérifiez si vous avez encore plus de 16 adresses IP disponibles dans la plage CIDR de votre sous-réseau. Si vous disposez d’un nombre suffisant d'adresses IP et que vous recevez encore fréquemment le message d'erreur Impossible d'attribuer une erreur IP, le problème est généralement lié à la fragmentation du sous-réseau. Pour résoudre ce problème, il est recommandé d'utiliser un réseau personnalisé avec délégation de préfixes afin d'établir des sous-réseaux dédiés pour les pods. Pour plus d'informations, consultez la page AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG sur le site Web de GitHub.

Erreur****Échec d’obtention de la configuration de ENI du pod

Si vous utilisez AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG pour activer la mise en réseau personnalisée mais que vous ne créez pas de ressource ENIConfig, vous recevez un message d'erreur similaire à l'exemple suivant :

« {"level":"error","ts":"","caller":"ipamd/ipamd.go:798","msg":"Failed to get pod ENI config"} » ({"level":"error","ts":"","caller":"ipamd/ipamd.go:798","msg":"Échec d’obtention de la configuration de l’ENI du pod"})

Pour vérifier si la ressource ENIConfig existe dans le cluster, exécutez la commande suivante :

kubectl get eniconfig -o yaml

Si la ressource personnalisée ENIconfig n'existe pas, créez-en une. Pour plus d'informations sur la mise en réseau personnalisée, consultez la page AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG sur le site Web de GitHub.

Erreur Échec de l’analyse

Si vous n'écrivez pas le fichier YAML au format correct, vous risquez de recevoir un message d'erreur similaire à l'exemple suivant :

« Failed to watch *v1alpha1.ENIConfig: failed to list *v1alpha1.ENIConfig:json: cannot unmarshal string into Go struct field ENIConfigSpec.items.spec.securityGroups of type []string » (Échec de l’analyse de *v1alpha1.ENIConfig : échec d’énumération de *v1alpha1.ENIConfig:json : impossible de décoder la chaîne dans le champ Struct Go ENIConfigSpec.items.spec.securityGroups de type []string)

Ce problème se produit généralement en cas d’incompatibilité entre les données JSON et la définition du type de données Go. L'exemple de message d'erreur précédent indique qu'il existe un problème avec le champ securityGroups.

Pour résoudre ce problème, exécutez la commande suivante pour vérifier vos données JSON :

kubectl describe ENIConfig

Dans la sortie de la commande, vérifiez la syntaxe en fonction du problème identifié dans le message d'erreur. Par exemple, assurez-vous que le champ securityGroups de votre fichier JSON est un tableau de chaînes et non une chaîne unique.

Exemple de sortie :

cat >$az_1.yaml <<EOF
apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
  name: us-west-2a
spec:
  securityGroups:
    - sg-0123456789abcdef0
  subnet: subnet-0123456789abcdef0
EOF
AWS OFFICIELA mis à jour il y a un an