Pourquoi mes pods ne se connectent-ils pas à d'autres pods dans Amazon EKS ?

Brève description

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'AWS CLI.

Si vos pods ne peuvent pas se connecter à d'autres pods, les erreurs suivantes peuvent s'afficher, en fonction de votre application.

Si le groupe de sécurité d'un composant master n'autorise pas la communication entre les nœuds, vous recevez l'erreur suivante :

curl: (7) Failed to connect to XXX.XXX.XX.XXX port XX: Connection timed out

Si le DNS ne fonctionne pas, vous recevez le message d'erreur suivant :

curl nginx  
curl: (6) Could not resolve host: nginx

Si le DNS fonctionne mais qu'il existe un problème de connectivité au pod, vous recevez le message d'erreur suivant :

Error: RequestError: send request failed caused by: Post  dial tcp 1.2.3.4.5:443: i/o timeout

Si vous essayez de résoudre le problème DNS du pod qui n'est pas exposé par le biais d'un service, vous recevez le message d'erreur suivant :

kubectl exec -it busybox -- nslookup nginx
Server:   10.100.0.10
Address:  10.100.0.10:53
** server can't find nginx.default.svc.cluster.local: NXDOMAIN
*** Can't find nginx.svc.cluster.local: No answer
*** Can't find nginx.cluster.local: No answer
*** Can't find nginx.ap-southeast-2.compute.internal: No answer
*** Can't find nginx.default.svc.cluster.local: No answer
*** Can't find nginx.svc.cluster.local: No answer
*** Can't find nginx.cluster.local: No answer
*** Can't find nginx.ap-southeast-2.compute.internal: No answer

Pour résoudre ces erreurs, vérifiez que votre environnement est correctement configuré :

• Vos groupes de sécurité sont conformes aux directives Amazon EKS.
• La liste de contrôle d'accès au réseau (ACL réseau) ne refuse pas la connexion.
• Votre sous-réseau dispose d'une route locale pour communiquer au sein de votre Amazon Virtual Private Cloud (Amazon VPC).
• Il y a suffisamment d'adresses IP disponibles dans le sous-réseau.
• Vos groupes de sécurité pour les pods permettent aux pods de communiquer entre eux.
• Le transfert IP est activé sur vos composants master.
• Vous répondez aux exigences réseau de Kubernetes (à l'exception de toute politique réseau intentionnelle).
• Vos pods utilisent correctement le DNS pour communiquer entre eux.
• Vos pods sont programmés et en cours d'exécution.
• Vous disposez de la version recommandée du plug-in Amazon VPC de l’interface de conteneur réseau (CNI) pour Kubernetes.

Résolution

Vos groupes de sécurité respectent les directives Amazon EKS

Pour restreindre le trafic que vous autorisez sur le groupe de sécurité de votre composant master, créez des règles d’admission. Créez ces règles pour tous les protocoles ou ports que vos composants master utilisent pour la communication entre nœuds.

Il est recommandé d'autoriser tout le trafic pour le groupe de sécurité de votre composant master. Il n'est pas nécessaire de modifier les règles du groupe de sécurité chaque fois qu'un nouveau pod avec un nouveau port est créé.

Pour plus d'informations, consultez la section Exigences et considérations relatives aux groupes de sécurité Amazon EKS.

L'ACL réseau ne refuse pas la connexion

1.    Vérifiez que le trafic entre votre cluster Amazon EKS et le CIDR VPC circule librement sur l'ACL de votre réseau.

2.    (Facultatif) Pour ajouter un niveau de sécurité supplémentaire à votre VPC, pensez à configurer des ACL réseau avec des règles similaires à celles de vos groupes de sécurité.

Votre sous-réseau dispose d'une route locale pour communiquer au sein de votre VPC

Vérifiez que vos sous-réseaux utilisent la route par défaut pour la communication au sein du VPC.

Il y a suffisamment d'adresses IP disponibles dans le sous-réseau

Vérifiez que les sous-réseaux que vous avez spécifiés disposent de suffisamment d'adresses IP disponibles pour les interfaces réseau élastiques multicomptes et vos espaces.

Pour plus d'informations, consultez la section Exigences et considérations relatives au VPC et au sous-réseau Amazon EKS.

Pour vérifier les adresses IP disponibles, exécutez la commande AWS CLI suivante :

$ aws ec2 describe-subnets --subnet-id YOUR-SUBNET-ID --query 'Subnets[0].AvailableIpAddressCount'

Vos groupes de sécurité pour les pods permettent aux pods de communiquer entre eux

Si vous utilisez des groupes de sécurité pour les pods ou un réseau CNI personnalisé, vous pouvez allouer n'importe quel groupe de sécurité aux pods. Dans ce scénario, vérifiez que les groupes de sécurité autorisent correctement la communication entre les pods.

Le transfert IP de vos composants master est activé

Si vous utilisez une AMI personnalisée, vous devez vous assurer que la variable noyau net.ipv4.ip \ _forward est activée. Pour vérifier ce paramètre sur un composant master, exécutez l'une des commandes suivantes :

# sysctl net.ipv4.ip_forward

# cat /proc/sys/net/ipv4/ip_forward

Si la sortie est 0, utilisez l'une des commandes suivantes pour activer la variable noyau net.ipv4.ip \ _forward.

# sysctl -w net.ipv4.ip_forward=1

# echo 1 > /proc/sys/net/ipv4/ip_forward

Pour les AMI Amazon EKS dans un environnement d'exécution containerd, consultez les lignes 184 à 188 du script install-worker.sh (sur GitHub) pour l'activation du paramètre. Containerd étant le moteur d'exécution par défaut dans les versions 1.24 et ultérieures d'Amazon EKS, cette étape est requise pour résoudre les problèmes de connectivité réseau entre pods.

Vous répondez aux exigences réseau de Kubernetes (à l'exception de toute politique de réseau intentionnelle)

Vérifiez que vous répondez aux exigences réseau de Kubernetes (sur le site Web de Kubernetes).

Par défaut, les pods ne sont pas isolés. Les pods acceptent le trafic provenant de n'importe quelle source. Les pods sont isolés grâce à une politique de réseau qui les sélectionne.

Remarque : pour les configurations de politique de réseau, voir la section Installation du module complémentaire Calico Network Policy Engine.

Vos pods utilisent correctement le DNS pour communiquer entre eux

Vous devez d'abord exposer vos pods via un service. Sinon, vos pods ne peuvent pas obtenir de noms DNS et ne sont accessibles que par leurs adresses IP spécifiques.

L'exemple de sortie suivant montre une tentative de résolution du nom DNS du service nginx. Dans ce cas, le ClusterIP 10.100.94.70 est renvoyé :

$ kubectl run nginx --image=nginx --replicas=5 -n web
deployment.apps/nginx created

$ kubectl expose deployment nginx --port=80 -n web
service/nginx exposed

$ kubectl get svc -n web
NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
nginx   ClusterIP   10.100.94.70   <none>        80/TCP    2s

# kubectl exec -ti busybox -n web -- nslookup nginx
Server:    10.100.0.10
Address 1: 10.100.0.10 ip-10-100-0-10.ap-southeast-2.compute.internal
Name:      nginx
Address 1: 10.100.94.70 ip-10-100-94-70.ap-southeast-2.compute.internal

Si vos pods ne parviennent toujours pas à résoudre les problèmes DNS, consultez la section Comment résoudre les problèmes de DNS avec Amazon EKS ?

Remarque : pour plus d'informations, consultez les sections Pods, Service et Headless Services sur le site Web de Kubernetes.

Vos pods sont programmés et en cours d'exécution

Vérifiez que vos pods sont programmés et qu'ils sont en cours d'exécution.

Pour résoudre le problème de l'état de votre pod, consultez la section Comment résoudre les problèmes liés à l'état du pod dans Amazon EKS ?

Vous disposez de la version recommandée du plug-in Amazon VPC CNI pour Kubernetes

Si vous ne disposez pas de la version recommandée du plug-in Amazon VPC CNI pour Kubernetes, effectuez alors une mise à niveau vers la dernière version.

Si vous disposez de la version recommandée mais que vous rencontrez des problèmes avec celle-ci, consultez la section Comment résoudre les problèmes liés aux plug-ins Kubelet ou CNI pour Amazon EKS ?