View a markdown version of this page

Résolution des problèmes de sortie du plan de commande - Amazon EKS
Détecter un webhook défaillantAucune route de sortie vers les points de terminaison requisLes NACL bloquent le trafic du webhook ou du plan de contrôleGroupes de sécurité empêchant l'accèsÉchec de l'actualisation du jeu d'options DHCPProblèmes de routage IPv6Le fournisseur OIDC est inaccessible

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 sur 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

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"

  2. 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"

  3. 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"

  2. Assurez-vous que les règles suivantes existent :

    Direction Protocole Plage de ports Destination/Source Action

    Sortant

    TCP

    443

    0,0.0. 0/0 (ou webbook CIDR)

    Allow

    Sortant

    TCP

    10250

    Bloc d’adresse du VPC

    Allow

    Entrant

    TCP

    1024—65535

    0,0.0. 0/0

    Autoriser (trafic aller-retour éphémère)
    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 execkubectl 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"

  2. Vérifiez que les règles de trafic sortant autorisent :

    Protocole Port Destination

    TCP

    443

    0,0.0. 0/0 (points de terminaison Webhook, fournisseurs OIDC)

    TCP

    10250

    Groupe de sécurité de nœuds ou VPC CIDR (API kubelet)

  3. 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

  2. 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.

  3. 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.

  4. 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"

  2. 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']"

  3. 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

  4. 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 exempleoidc.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

  2. Vérifiez que le groupe de sécurité du cluster autorise le TCP 443 sortant à 0.0.0.0/0 (voirGroupes de sécurité empêchant l'accès).

📝 Modifiez cette page sur GitHub