Pourquoi mes pods ne se connectent-ils pas à d'autres pods dans 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 ?

---