**Aidez à améliorer cette page**
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub ** lien ** Modifier cette page qui se trouve dans le volet droit de chaque page.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résolution des problèmes de sortie du plan de commande
Lorsque vous utilisez le mode de sortie du plan de `CUSTOMER_ROUTED` contrôle, vous êtes responsable de la connectivité réseau à partir des ENI du plan de contrôle. Cette page présente les problèmes courants et leurs solutions.
## Détecter un webhook défaillant
Lorsque le plan de contrôle ne parvient pas à atteindre un serveur webhook ou un fournisseur OIDC, le symptôme apparaît généralement sous la forme d'un délai d'expiration du webhook. Pour confirmer, créer ou modifier une ressource qui déclenche le webhook et vérifier l'erreur :
```
kubectl apply -f my-resource.yaml
```
Une panne de connectivité ou de DNS renvoie généralement une erreur similaire à ce qui suit :
```
Error from server (InternalError): error when creating "my-resource.yaml": Internal error occurred:
failed calling webhook "my-webhook.example.com": failed to call webhook:
Post "https://my-webhook.example.com/validate?timeout=10s": context deadline exceeded
```
Vous pouvez également vérifier les événements récents pour détecter les erreurs de webhook dans le cluster :
```
kubectl get events --all-namespaces --field-selector reason=FailedCreate
```
+ Si l'erreur est due à un timeout (`context deadline exceeded`) ou à un refus de connexion, le plan de contrôle ne peut pas atteindre le point de terminaison du webhook. Consultez [Aucune route de sortie vers les points de terminaison requis](#egress-troubleshoot-natgw), [Les NACL bloquent le trafic du webhook ou du plan de contrôle](#egress-troubleshoot-nacl) et [Groupes de sécurité empêchant l'accès](#egress-troubleshoot-sg).
+ Si l'erreur mentionne une défaillance du DNS ou aucune défaillance d'hôte de ce type, le plan de contrôle ne peut pas résoudre le point de terminaison. Consultez [Échec de l'actualisation du jeu d'options DHCP](#egress-troubleshoot-dhcp).
## Aucune route de sortie vers les points de terminaison requis
**Symptômes :**
+ Date limite d'admission pour les webhooks.
+ La découverte du fournisseur OIDC échoue.
+ La création ou la mise à jour de clusters s'arrête.
**Cause** :
Les sous-réseaux de l'interface réseau du plan de contrôle ne disposent pas d'un itinéraire fonctionnel vers les points de terminaison que le plan de contrôle doit atteindre. Le plus souvent, il manque une route par défaut vers un périphérique de sortie dans la table de routage du sous-réseau. Sinon, cet appareil est mal configuré. Le périphérique de sortie est généralement une passerelle NAT. Toutefois, il peut s'agir d'une instance NAT, d'un pare-feu ou d'un dispositif proxy, ou d'une passerelle de transit vers un VPC de sortie centralisé.
**Solution :**
1. Identifiez les sous-réseaux que votre cluster utilise pour les interfaces réseau du plan de contrôle :
```
aws eks describe-cluster --name my-cluster \
--query "cluster.resourcesVpcConfig.subnetIds"
```
1. Pour chaque sous-réseau, vérifiez la table de routage associée :
```
aws ec2 describe-route-tables \
--filters "Name=association.subnet-id,Values=subnet-ExampleID1"
```
1. Vérifiez qu'il existe un itinéraire `0.0.0.0/0` (ou un itinéraire qui couvre le point de terminaison) pointant vers votre dispositif de sortie. S'il est absent, ajoutez l'itinéraire. L'exemple suivant ajoute une route de passerelle NAT ; remplacez-la par votre propre cible de sortie (par exemple, une passerelle de transit ou une interface réseau) :
```
aws ec2 create-route \
--route-table-id rtb-ExampleID \
--destination-cidr-block 0.0.0.0/0 \
--nat-gateway-id nat-ExampleID
```
## Les NACL bloquent le trafic du webhook ou du plan de contrôle
**Symptômes :**
+ Le webhook d'admission arrive à expiration (erreur :`failed calling webhook`).
+ Défaillances intermittentes lors de la création ou de la modification de ressources Kubernetes qui utilisent des webhooks mutants ou validants.
**Cause** :
Les ACL réseau sur le plan de contrôle (les sous-réseaux ENI) bloquent le trafic sortant vers les points de terminaison du webhook ou bloquent le trafic entrant éphémère entre les ports de retour.
**Solution :**
1. Identifiez les NACL associées aux sous-réseaux de votre plan de contrôle :
```
aws ec2 describe-network-acls \
--filters "Name=association.subnet-id,Values=subnet-ExampleID1"
```
1. Assurez-vous que les règles suivantes existent :
[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/control-plane-egress-troubleshooting.html)
**Note**
Les NACL sont apatrides. Vous devez autoriser explicitement le trafic de retour sur les ports éphémères (1024 à 65535) dans les règles de trafic entrant.
Ces règles couvrent deux voies différentes. La règle du port 443 concerne le trafic sortant vers les points de terminaison Webhook et OIDC, qui quitte le VPC via votre périphérique de sortie. La règle du port 10250 concerne l'API kubelet, qui reste dans votre VPC entre le plan de contrôle et vos nœuds. Un périphérique de sortie manquant n'affecte pas le port 10250, mais une ACL réseau restrictive peut le bloquer.
## Groupes de sécurité empêchant l'accès
**Symptômes :**
+ Les appels Webhook échouent.
+ Le plan de contrôle ne peut pas atteindre l'API kubelet sur les nœuds (port 10250).
+ `kubectl exec``kubectl logs`, ou `kubectl port-forward` échouer.
**Cause** :
Le groupe de sécurité attaché aux ENI du plan de contrôle (le *groupe de sécurité du cluster*) n'autorise pas le trafic sortant sur les ports requis.
**Solution :**
1. Identifiez le groupe de sécurité du cluster :
```
aws eks describe-cluster --name my-cluster \
--query "cluster.resourcesVpcConfig.clusterSecurityGroupId"
```
1. Vérifiez que les règles de trafic sortant autorisent :
[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/eks/latest/userguide/control-plane-egress-troubleshooting.html)
1. Si les règles de sortie sont restrictives, ajoutez des règles pour le trafic requis :
```
aws ec2 authorize-security-group-egress \
--group-id sg-ExampleClusterSG \
--protocol tcp \
--port 443 \
--cidr 0.0.0.0/0
```
**Note**
Si vous avez des exigences de sortie strictes et que vous connaissez les plages d'adresses IP de votre webhook et de vos points de terminaison OIDC, vous pouvez étendre la règle du port 443 à ces CIDR spécifiques au lieu de. `0.0.0.0/0` La règle du port 10250 (API kubelet) est la suivante VPC-internal : étendez-la au groupe de sécurité de votre nœud ou au CIDR VPC plutôt qu'à Internet.
## Échec de l'actualisation du jeu d'options DHCP
**Symptômes :**
+ La résolution DNS échoue depuis le plan de contrôle.
+ Les opérations de cluster qui nécessitent des recherches DNS (découverte OIDC, résolution de webhook) échouent.
+ Le problème apparaît après la modification des options DHCP du VPC ou après une mise à jour du plan de contrôle.
**Cause** :
Le jeu d'options DHCP VPC a été modifié. Sinon, il n'inclut pas `AmazonProvidedDNS` dans ses serveurs de noms de domaine. Il peut également manquer un autre résolveur capable de résoudre les noms dont le plan de contrôle a besoin. Le plan de contrôle détecte automatiquement les modifications apportées aux ensembles d'options DHCP et applique les nouveaux paramètres DNS, généralement dans un délai d'une heure. Le plan de contrôle ne peut le faire que lorsque le rôle IAM du cluster accorde les autorisations de lecture Amazon EC2 requises.
**Solution :**
1. Vérifiez l'option DHCP définie pour votre VPC :
```
aws ec2 describe-vpcs --vpc-ids vpc-ExampleID \
--query "Vpcs[0].DhcpOptionsId" \
--region region-code
```
```
aws ec2 describe-dhcp-options --dhcp-options-ids dopt-ExampleID --region region-code
```
1. Vérifiez que cela `domain-name-servers` inclut `AmazonProvidedDNS` (le résolveur Amazon-provided DNS, qui est la base de votre CIDR IPv4 VPC plus deux) ou un autre résolveur capable de résoudre les noms dont le plan de contrôle a besoin.
1. Vérifiez que le rôle IAM du cluster est accordé `ec2:DescribeVpcs` et. `ec2:DescribeDhcpOptions` Sans ces autorisations, le plan de contrôle ne peut pas lire les options DHCP mises à jour et ne peut pas actualiser ses paramètres DNS. Pour plus d'informations, consultez le [rôle IAM du cluster Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/cluster-iam-role.html).
1. Après une modification des options DHCP, attendez jusqu'à une heure pour que le plan de contrôle détecte et applique automatiquement les nouveaux paramètres. Aucune mise à jour du cluster ni aucun remplacement d'instance n'est requis. Si la résolution DNS échoue toujours au bout d'une heure et que les autorisations ci-dessus sont en place, contactez le AWS Support.
## Problèmes de routage IPv6
**Symptômes :**
+ Les clusters IPv6 ne peuvent pas atteindre les points de terminaison OIDC ou Webhook externes.
+ L'enregistrement des nœuds fonctionne sur IPv4 mais les services IPv6 échouent.
**Cause** :
Il manque une route vers une passerelle Internet de sortie uniquement dans la table de `::/0` routage du sous-réseau, ou les mesures de sécurité groups/NACLs n'autorisent pas le trafic IPv6.
**Solution :**
1. Vérifiez qu'une passerelle Internet de sortie uniquement existe et qu'elle est attachée au VPC :
```
aws ec2 describe-egress-only-internet-gateways \
--filters "Name=attachment.vpc-id,Values=vpc-ExampleID"
```
1. Vérifiez que la table de routage pour les sous-réseaux du plan de contrôle comporte un `::/0` itinéraire :
```
aws ec2 describe-route-tables \
--filters "Name=association.subnet-id,Values=subnet-ExampleID1" \
--query "RouteTables[0].Routes[?DestinationIpv6CidrBlock=='::/0']"
```
1. S'il manque, ajoutez l'itinéraire :
```
aws ec2 create-route \
--route-table-id rtb-ExampleID \
--destination-ipv6-cidr-block ::/0 \
--egress-only-internet-gateway-id eigw-ExampleID
```
1. Assurez-vous que les NACL et les groupes de sécurité autorisent le trafic sortant IPv6 sur le port 443 et les ports éphémères entrants.
## Le fournisseur OIDC est inaccessible
**Symptômes :**
+ `IAM roles for service accounts`(IRSA) échoue : les pods ne peuvent pas assumer de rôles.
+ Les événements du cluster indiquent des erreurs de découverte OIDC.
**Cause** :
Le plan de contrôle ne peut pas atteindre le point de terminaison du fournisseur OIDC (par exemple`oidc.eks.region-code.amazonaws.com`) car la sortie est bloquée.
**Solution :**
1. Vérifiez que le chemin de sortie et la table de routage autorisent le trafic HTTPS sortant. Pour les étapes de résolution des problèmes lorsque l'itinéraire de sortie est absent ou mal configuré, voir. [Aucune route de sortie vers les points de terminaison requis](#egress-troubleshoot-natgw)
1. Vérifiez que le groupe de sécurité du cluster autorise le TCP 443 sortant à `0.0.0.0/0` (voir[Groupes de sécurité empêchant l'accès](#egress-troubleshoot-sg)).
📝 [Modifiez cette page sur GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23control-plane-egress-troubleshooting%5D&type=code)