Pourquoi mes pods ne se connectent-ils pas à d'autres pods dans Amazon EKS ?
Mes pods ne se connectent pas à d'autres pods dans Amazon Elastic Kubernetes Service (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 ?

Contenus pertinents
- demandé il y a 4 moislg...
- demandé il y a un moislg...
- demandé il y a 3 moislg...
- demandé il y a 2 moislg...
- demandé il y a 5 moislg...
- AWS OFFICIELA mis à jour il y a un an
- Comment choisir des sous-réseaux IP spécifiques à utiliser pour les pods de mon cluster Amazon EKS ?AWS OFFICIELA mis à jour il y a 4 mois
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 6 mois