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 des erreurs s'affichent lors de l'exécution d'AWS Command Line Interface (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, vous pouvez recevoir les erreurs suivantes (en fonction de votre application).
Si le groupe de sécurité d'un nœud de travail n'autorise pas la communication entre nœuds :
curl: (7) Failed to connect to XXX.XXX.XX.XXX port XX: Connection timed out
Si le DNS ne fonctionne pas :
Error: RequestError: send request failed caused by: Post dial tcp: i/o timeout
Si le DNS fonctionne, mais qu'il y a toujours un problème de connectivité de pod :
Error: RequestError: send request failed caused by: Post dial tcp 1.2.3.4.5:443: i/o timeout
Si le pod n'a pas été exposé par le biais d'un service et que vous essayez de résoudre le DNS du pod :
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 si votre environnement est configuré correctement en confirmant ce qui suit :
- Vous respectez les exigences de mise en réseau pour Kubernetes (à l'exception de toute stratégie NetworkPolicyintentionnelle)
- Vos pods utilisent correctement DNS pour communiquer entre eux
- Vos groupes de sécurité respectent les directives Amazon EKS
- Vos groupes de sécurité pour les pods permettent aux pods de communiquer entre eux
- La liste de contrôle d'accès (ACL) réseau ne rejette pas la connexion
- Votre sous-réseau dispose d'un chemin local pour communiquer au sein de votre Virtual Private Cloud (Amazon VPC)
- Il y a suffisamment d'adresses IP disponibles dans le sous-réseau
- Vos pods sont planifiés et sont à l'état RUNNING
- Vous disposez de la version recommandée du plugin Amazon VPC de l'interface de conteneur réseau (CNI) pour Kubernetes
Solution
Vous respectez les exigences de mise en réseau pour Kubernetes (à l'exception de toute stratégie NetworkPolicy intentionnelle)
Vérifiez que vous répondez aux exigences mise en réseau de Kubernetes (à partir du site Web 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 en ayant une stratégie NetworkPolicy qui les sélectionne.
Remarque : pour les configurations NetworkPolicy consultez Installation de Calico sur Amazon EKS.
Vos pods utilisent correctement DNS pour communiquer entre eux
Vous devez d'abord exposer vos pods via un service. Dans le cas contraire, vos pods n'obtiendront pas de noms DNS et ne pourront être accessibles que par leurs adresses IP spécifiques.
Par exemple :
$ 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
Le résultat montre que le ClusterIP10.100.94.70 a été renvoyée lors de la résolution du nom DNS pour le service nginx.
Si vos pods ne parviennent toujours pas à résoudre le DNS, consultez la section Comment résoudre les problèmes DNS avec Amazon EKS ?
Remarque : Pour en savoir plus, consultez les sections Pods, Service et Services sans tête sur le site Web de Kubernetes.
Vos groupes de sécurité respectent les directives Amazon EKS
Créez des règles entrantes pour limiter le trafic autorisé sur le groupe de sécurité de votre nœud de travail. Créez les règles entrantes pour n'importe quel protocole ou tous les ports utilisés par vos nœuds de travail pour la communication entre nœuds.
Il est recommandé d'activer tout le trafic pour le groupe de sécurité de votre nœud de travail. Vous n'avez pas besoin de modifier les règles des groupes de sécurité chaque fois qu'un nouveau pod avec un nouveau port est créé.
Pour en savoir plus, consultez la section Considérations relatives aux groupes de sécurité Amazon EKS.
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ée CNI, 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 espaces.
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 une couche de sécurité supplémentaire à votre VPC, envisagez de configurer des listes ACL réseau avec des règles similaires à 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 ont 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 Adressage IP VPC.
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 pods sont planifiés et sont à l'état RUNNING
Vérifiez que vos pods sont planifiés et sont à l'état RUNNING (EN COURS D'EXÉCUTION).
Pour dépanner l'état de votre pod, consultez How can I troubleshoot pod status in Amazon EKS? (Comment puis-je résoudre le problème de l'état du pod dans Amazon EKS ?)
Vous disposez de la version recommandée du plugin CNI Amazon VPC pour Kubernetes
Si vous n'exécutez pas la version recommandée du plugin Amazon VPC CNI pour Kubernetes, envisagez de passer à la dernière version.
Si vous disposez de la version recommandée, mais que vous rencontrez des problèmes, consultez la section Comment résoudre les problèmes de plugin kubelet ou CNI pour Amazon EKS ?

Contenus pertinents
- demandé il y a un moislg...
- demandé il y a 5 jourslg...
- demandé il y a un moislg...
- demandé il y a 2 moislg...
- demandé il y a 3 moislg...
- 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 2 mois
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a 4 mois
- AWS OFFICIELA mis à jour il y a un an