View a markdown version of this page

Risoluzione dei problemi relativi all'uscita del piano di controllo - Amazon EKS
Rileva un webhook difettosoNessuna via di uscita verso gli endpoint richiestiI NACL bloccano il webhook o controllano il traffico aereoGruppi di sicurezza che impediscono l'accessoErrore di aggiornamento del set di opzioni DHCPProblemi di routing IPv6Provider OIDC non raggiungibile

Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi relativi all'uscita del piano di controllo

Quando si utilizza la modalità di uscita del piano CUSTOMER_ROUTED di controllo, sei responsabile della connettività di rete dal piano di controllo ENI. Questa pagina descrive i problemi più comuni e le relative soluzioni.

Rileva un webhook difettoso

Quando il piano di controllo non riesce a raggiungere un server webhook o un provider OIDC, il sintomo di solito si manifesta come un timeout del webhook. Per confermare, creare o modificare una risorsa che attiva il webhook e verificare l'errore:

kubectl apply -f my-resource.yaml

Un errore di connettività o DNS restituisce in genere un errore simile al seguente:

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

Puoi anche controllare gli eventi recenti per verificare la presenza di errori nei webhook nel cluster:

kubectl get events --all-namespaces --field-selector reason=FailedCreate

Nessuna via di uscita verso gli endpoint richiesti

Caratteristiche:

  • Timeout dei webhook di ammissione.

  • L'individuazione del provider OIDC non riesce.

  • La creazione o l'aggiornamento dei cluster si bloccano.

Causa:

Le sottoreti dell'interfaccia di rete del piano di controllo non hanno un percorso funzionante verso gli endpoint che il piano di controllo deve raggiungere. Nella maggior parte dei casi, nella tabella delle rotte delle sottoreti manca una route predefinita verso un dispositivo di uscita. In alternativa, quel dispositivo non è configurato correttamente. Il dispositivo di uscita è in genere un gateway NAT. Tuttavia, può essere un'istanza NAT, un firewall o un dispositivo proxy o un gateway di transito verso un VPC in uscita centralizzato.

Soluzione::

  1. Identifica le sottoreti utilizzate dal cluster per le interfacce di rete del piano di controllo:

    aws eks describe-cluster --name my-cluster \
    --query "cluster.resourcesVpcConfig.subnetIds"

  2. Per ogni sottorete, controllate la tabella di routing associata:

    aws ec2 describe-route-tables \
    --filters "Name=association.subnet-id,Values=subnet-ExampleID1"

  3. Verifica che esista un percorso per 0.0.0.0/0 (o un percorso che copra l'endpoint) che punta al tuo dispositivo di uscita. Se manca, aggiungi il percorso. L'esempio seguente aggiunge una route di gateway NAT; sostituite la vostra destinazione di uscita (ad esempio, un gateway di transito o un'interfaccia di rete):

    aws ec2 create-route \
    --route-table-id rtb-ExampleID \
    --destination-cidr-block 0.0.0.0/0 \
    --nat-gateway-id nat-ExampleID

I NACL bloccano il webhook o controllano il traffico aereo

Caratteristiche:

  • Timeout delle chiamate al webhook di ammissione (errore:). failed calling webhook

  • Errori intermittenti durante la creazione o la modifica di risorse Kubernetes che utilizzano webhook mutanti o di convalida.

Causa:

Gli ACL di rete sul piano di controllo, le sottoreti ENI bloccano il traffico in uscita verso gli endpoint webhook o bloccano il traffico effimero di ritorno alle porte in entrata.

Soluzione::

  1. Identifica i NACL associati alle sottoreti del tuo piano di controllo:

    aws ec2 describe-network-acls \
    --filters "Name=association.subnet-id,Values=subnet-ExampleID1"

  2. Assicuratevi che esistano le seguenti regole:

    Direzione Protocollo Intervallo porte Destination/Source Azione

    In uscita

    TCP

    443

    0.0.0. 0/0 (o webhook CIDR)

    Consenso

    In uscita

    TCP

    10250

    CIDR VPC

    Consenso

    In entrata

    TCP

    1024—65535

    0,0,0. 0/0

    Consenti (traffico temporaneo di ritorno)
    Nota

    I NACL sono apolidi. È necessario consentire esplicitamente il traffico di ritorno sulle porte temporanee (1024—65535) nelle regole in entrata.

    Queste regole riguardano due percorsi diversi. La regola della porta 443 riguarda il traffico in uscita verso gli endpoint webhook e OIDC, che lascia il VPC attraverso il dispositivo in uscita. La regola della porta 10250 è per l'API kubelet, che rimane all'interno del tuo VPC tra il piano di controllo e i nodi. Un dispositivo di uscita mancante non influisce sulla porta 10250, ma un ACL di rete restrittivo può bloccarlo.

Gruppi di sicurezza che impediscono l'accesso

Caratteristiche:

  • Le chiamate Webhook hanno esito negativo.

  • Il piano di controllo non può raggiungere l'API kubelet sui nodi (porta 10250).

  • kubectl exec, o kubectl logs fallire. kubectl port-forward

Causa:

Il gruppo di sicurezza collegato al piano di controllo ENiS (il gruppo di sicurezza del cluster) non consente il traffico in uscita sulle porte richieste.

Soluzione::

  1. Identifica il gruppo di sicurezza del cluster:

    aws eks describe-cluster --name my-cluster \
    --query "cluster.resourcesVpcConfig.clusterSecurityGroupId"

  2. Verifica che le regole in uscita consentano:

    Protocollo Porta Destinazione

    TCP

    443

    0.0.0. 0/0 (endpoint webhook, provider OIDC)

    TCP

    10250

    Gruppo di sicurezza del nodo o VPC CIDR (API kubelet)

  3. Se le regole in uscita sono restrittive, aggiungi regole per il traffico richiesto:

    aws ec2 authorize-security-group-egress \
    --group-id sg-ExampleClusterSG \
    --protocol tcp \
    --port 443 \
    --cidr 0.0.0.0/0
    Nota

    Se hai requisiti di uscita rigorosi e conosci gli intervalli IP del tuo webhook e degli endpoint OIDC, puoi applicare la regola della porta 443 a quei CIDR specifici anziché a. 0.0.0.0/0 La regola della porta 10250 (API kubelet) è VPC-internal: applicala al gruppo di sicurezza del nodo o al CIDR VPC anziché a Internet.

Errore di aggiornamento del set di opzioni DHCP

Caratteristiche:

  • La risoluzione DNS non riesce dal piano di controllo.

  • Le operazioni del cluster che richiedono ricerche DNS (rilevamento OIDC, risoluzione webhook) hanno esito negativo.

  • Il problema si verifica dopo la modifica delle opzioni DHCP del VPC o dopo un aggiornamento del piano di controllo.

Causa:

Il set di opzioni DHCP VPC è stato modificato. In alternativa, non include AmazonProvidedDNS nei suoi server di nomi di dominio. Potrebbe anche mancare un altro resolver in grado di risolvere i nomi necessari al piano di controllo. Il piano di controllo rileva automaticamente le modifiche al set di opzioni DHCP e applica le nuove impostazioni DNS, in genere entro un'ora. Il piano di controllo può eseguire questa operazione solo quando il ruolo IAM del cluster concede le autorizzazioni di lettura richieste di Amazon EC2.

Soluzione::

  1. Verifica l'impostazione delle opzioni DHCP per il tuo 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. Verifica che domain-name-servers includa AmazonProvidedDNS (il resolver Amazon-provided DNS, che è la base del tuo VPC IPv4 CIDR più due) o un altro resolver in grado di risolvere i nomi necessari al piano di controllo.

  3. Conferma le concessioni ec2:DescribeVpcs del ruolo IAM del cluster e. ec2:DescribeDhcpOptions Senza queste autorizzazioni, il piano di controllo non può leggere le opzioni DHCP aggiornate e non può aggiornare le impostazioni DNS. Per ulteriori informazioni, consulta il ruolo IAM del cluster Amazon EKS.

  4. Dopo una modifica delle opzioni DHCP, attendi fino a un'ora affinché il piano di controllo rilevi e applichi automaticamente le nuove impostazioni. Non è richiesto alcun aggiornamento del cluster o la sostituzione dell'istanza. Se la risoluzione DNS continua a fallire dopo un'ora e le autorizzazioni di cui sopra sono disponibili, contatta l'assistenza AWS .

Problemi di routing IPv6

Caratteristiche:

  • I cluster IPv6 non possono raggiungere endpoint OIDC o webhook esterni.

  • La registrazione dei nodi funziona su IPv4 ma i servizi IPv6 falliscono.

Causa:

Nella tabella di routing delle sottoreti manca una ::/0 route verso un gateway Internet solo in uscita oppure la sicurezza non consente il traffico IPv6. groups/NACLs

Soluzione::

  1. Verifica che esista un gateway Internet solo in uscita e che sia collegato al VPC:

    aws ec2 describe-egress-only-internet-gateways \
    --filters "Name=attachment.vpc-id,Values=vpc-ExampleID"

  2. Verificate che la tabella dei percorsi per le sottoreti del piano di controllo abbia un percorso: ::/0

    aws ec2 describe-route-tables \
    --filters "Name=association.subnet-id,Values=subnet-ExampleID1" \
    --query "RouteTables[0].Routes[?DestinationIpv6CidrBlock=='::/0']"

  3. Se manca, aggiungi il percorso:

    aws ec2 create-route \
    --route-table-id rtb-ExampleID \
    --destination-ipv6-cidr-block ::/0 \
    --egress-only-internet-gateway-id eigw-ExampleID

  4. Assicurati che i NAC e i gruppi di sicurezza consentano l'IPv6 in uscita sulla porta 443 e le porte effimere in entrata.

Provider OIDC non raggiungibile

Caratteristiche:

  • IAM roles for service accounts(IRSA) fallisce: i pod non possono assumere ruoli.

  • Gli eventi del cluster mostrano errori di rilevamento OIDC.

Causa:

Il piano di controllo non può raggiungere l'endpoint del provider OIDC (ad esempiooidc.eks.region-code.amazonaws.com) perché l'uscita è bloccata.

Soluzione::

  1. Verificate che il percorso di uscita e la tabella delle rotte consentano il traffico HTTPS in uscita. Per la procedura di risoluzione dei problemi in caso di mancata o errata configurazione del percorso di uscita, consulta. Nessuna via di uscita verso gli endpoint richiesti

  2. Verificate che il gruppo di sicurezza del cluster consenta il protocollo TCP 443 in uscita di (vedere). 0.0.0.0/0 Gruppi di sicurezza che impediscono l'accesso

📝 Modifica questa pagina su GitHub