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 se connectent pas à 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 recevrez le message d'erreur suivante :

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

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

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

Si le DNS fonctionne malgré un problème de connectivité au pod, vous recevrez 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 corriger le DNS du pod qui n'est pas exposé par le biais d'un service, vous recevrez le message d'erreur suivante :

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, assurez-vous 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 réseau (ACL réseau) ne rejette 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 assez 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 NetworkPolicy 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 doté d’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 rejette pas la connexion

1.Vérifiez que le trafic entre votre cluster Amazon EKS et le CIDR VPC circule librement sur votre ACL 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 vos sous-réseaux spécifiés ont suffisamment d'adresses IP disponibles pour les interfaces réseau Elastic entre comptes et vos pods.

Pour plus d'informations, consultez la section Exigences et considérations relatives aux VPC et aux 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 la mise en réseau personnalisé CNI, vous pouvez allouer tout 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 de 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étrage. 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 NetworkPolicy 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 toute source. Les pods sont isolés par le biais d’une NetworkPolicy qui les sélectionne.

**Remarque :**Pour les configurations NetworkPolicy, voir la section Installation de l’ajout moteur Calico Network Policy.

Vos pods utilisent correctement le DNS pour communiquer entre eux

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

L'exemple de résultat 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, utilisez la dernière version.

Si malgré la version recommandée les problèmes persistent, consultez la section Comment résoudre les problèmes liés aux plug-ins Kubelet ou CNI pour Amazon EKS ?