Risoluzione dei problemi di Amazon EKS - Amazon EKS

Risoluzione dei problemi di Amazon EKS

Questo capitolo presenta alcuni errori comuni che si potrebbero verificare durante l'utilizzo di Amazon EKS, e il modo in cui gestirli.

Capacità insufficiente

Se ricevi il seguente errore mentre provi a creare un cluster Amazon EKS, significa che una delle zone di disponibilità indicate non dispone della capacità sufficiente per supportare un cluster.

Cannot create cluster 'example-cluster' because region-1d, the targeted Availability Zone, does not currently have sufficient capacity to support the cluster. Retry and choose from these Availability Zones: region-1a, region-1b, region-1c

Riprova a crearlo con le sottoreti del VPC del cluster ospitate nelle zone di disponibilità restituite da questo messaggio di errore.

Impossibile aggiungere i nodi al cluster

Ci sono diversi motivi comuni che impediscono l'aggiunta dei nodi di lavoro al cluster:

  • Il file aws-auth-cm.yaml non dispone del giusto ARN del ruolo IAM per i nodi. Verifica che nel file aws-auth-cm.yaml sia specificato l'ARN del ruolo IAM del nodo (e non l'ARN del profilo dell'istanza). Per ulteriori informazioni, consulta Avvio di nodi Amazon Linux autogestiti.

  • Il NomeCluster nel modello AWS CloudFormation del nodo di lavoro non corrisponde esattamente al nome del cluster a cui vanno aggiunti i nodi. Se inserisci un valore non corretto in questo campo, si verificherà una configurazione errata del file /var/lib/kubelet/kubeconfig del nodo, e i nodi non riusciranno ad aggiungersi al cluster.

  • Il nodo non è taggato come appartenente al cluster. Ai nodi deve essere applicato il tag seguente, dove cluster-name viene sostituito con il nome del cluster.

    Key (Chiave) Value (Valore)

    kubernetes.io/cluster/cluster-name

    owned

  • I nodi potrebbero non essere in grado di accedere al cluster utilizzando un indirizzo IP pubblico. Assicurarsi che ai nodi implementati nelle sottoreti pubbliche venga assegnato un indirizzo IP pubblico. In caso contrario, è possibile associare un indirizzo IP elastico a un nodo dopo l'avvio. Per ulteriori informazioni, consultare Associazione di un indirizzo IP elastico a un'istanza o a un'interfaccia di rete in esecuzione. Se la sottorete pubblica non è impostata per assegnare automaticamente gli indirizzi IP pubblici alle istanze implementate, è consigliabile abilitare l'impostazione. Per ulteriori informazioni, consulta Modifica dell'attributo di assegnazione degli indirizzi IPv4 pubblici della sottorete. Se il nodo viene implementato in una sottorete privata, la sottorete deve disporre di una route a un gateway NAT a cui è assegnato un indirizzo IP pubblico.

  • L'endpoint STS per la Regione AWS in cui implementi i nodi non è abilitato per il tuo account. Per abilitare la regione, consulta la sezione Attivazione e disattivazione di AWS STS in una Regione AWS.

  • Il nodo (worker) non dispone di una voce DNS privata, con conseguente registro kubelet riportante un errore node "" not found. Assicurarsi che il VPC in cui viene creato il nodo (worker) disponga di valori impostati per domain-name e domain-name-servers come Options in un DHCP options set. I valori di default sono domain-name:<region>.compute.internal e domain-name-servers:AmazonProvidedDNS. Per ulteriori informazioni, consultare Set opzioni DHCP nella Guida per l'utente di Amazon VPC.

Accesso negato o non autorizzato (kubectl)

Se ricevi uno dei seguenti errori durante l'esecuzione di comandi kubectl, kubectl non è configurato correttamente per Amazon EKS, oppure le credenziali dell'utente o del ruolo IAM in uso non sono mappate a un utente RBAC Kubernetes con autorizzazioni sufficienti nel cluster Amazon EKS.

  • could not get token: AccessDenied: Access denied

  • error: You must be logged in to the server (Unauthorized)

  • error: the server doesn't have a resource type "svc"

Questo potrebbe essere dovuto al fatto che il cluster è stato creato con un set di credenziali AWS (da un utente o ruolo IAM), mentre kubectl utilizza un set di credenziali differente.

Quando viene creato un cluster Amazon EKS, l'entità IAM (utente o ruolo) che crea il cluster viene aggiunta alla tabella di autorizzazioni RBAC Kubernetes come amministratore (con autorizzazioni system:masters). Inizialmente, solo tale utente IAM può effettuare chiamate al server API Kubernetes utilizzando kubectl . Per ulteriori informazioni, consulta . Abilitazione dell'accesso a utenti e ruoli IAM al cluster. Se si utilizza la console per creare il cluster, è necessario assicurarsi che le stesse credenziali utente IAM siano presenti nella catena di credenziali AWS SDK quando si eseguono i comandi kubectl sul cluster.

Se si installa e si configura AWS CLI, è possibile configurare le credenziali IAM per l'utente. Per ulteriori informazioni, consulta Configurazione della AWS CLI nella Guida per l'utente di AWS Command Line Interface.

Se è stato scelto un ruolo per creare il cluster Amazon EKS, è necessario accertarsi che kubectl sia configurato in modo da assumere lo stesso ruolo. Utilizzare il comando seguente per aggiornare il file kubeconfig e utilizzare un ruolo IAM. Per ulteriori informazioni, consulta . Creazione di un kubeconfig per Amazon EKS.

aws eks update-kubeconfig \ --region region-code \ --name my-cluster \ --role-arn arn:aws:iam::aws_account_id:role/role_name

Per mappare un utente IAM a un utente Kubernetes RBAC, consultare Abilitazione dell'accesso a utenti e ruoli IAM al cluster.

aws-iam-authenticator non trovato

Se ricevi l'errore "aws-iam-authenticator": executable file not found in $PATH, significa che kubectl non è configurato per Amazon EKS. Per ulteriori informazioni, consulta . Installazione di aws-iam-authenticator.

Nota

Il aws-iam-authenticator non è necessario se è installata la versione 1.16.156 o successiva della AWS CLI.

hostname doesn't match

La versione Python del sistema deve essere 2.7.9 o successiva. In caso contrario, riceverai errori hostname doesn't match con chiamate AWS CLI a Amazon EKS. Per ulteriori informazioni, consultare Cosa sono gli errori "hostname doesn't match"? nelle domande frequenti di Python Requests.

getsockopt: no route to host

Docker viene eseguito nell’intervallo CIDR 172.17.0.0/16 nei cluster Amazon EKS. Consigliamo che le sottoreti VPC del cluster non si sovrappongano a questo intervallo. In caso contrario, si riceverà il seguente messaggio di errore:

Error: : error upgrading connection: error dialing backend: dial tcp 172.17.<nn>.<nn>:10250: getsockopt: no route to host

Errori del gruppo di nodi gestiti

Se viene visualizzato l'errore "Il tentativo di unione delle istanze al cluster kubernetes non è riuscito" nella AWS Management Console, assicurarsi che l'accesso all'endpoint privato del cluster sia abilitato o che siano stati configurati correttamente i blocchi CIDR per l'accesso agli endpoint pubblici. Per ulteriori informazioni, consulta . Controllo accessi all'endpoint del cluster Amazon EKS.

Se il gruppo di nodi gestiti rileva un problema di integrità hardware, Amazon EKS restituisce un messaggio di errore che consente di diagnosticare il problema. Questi controlli dell’integrità non rilevano problemi software perché si basano su controlli dell’integrità di Amazon EC2. Di seguito sono riportati i messaggi di errore e le relative descrizioni associate.

  • Accesso negato: Amazon EKS o uno o più nodi gestiti non sono in grado di eseguire l'autenticazione o l'autorizzazione con il server API del cluster Kubernetes. Per ulteriori informazioni sulla risoluzione di questo errore, consultare Risoluzione di errori AccessDenied per gruppi di nodi gestiti.

  • Id Ami non trovato: Impossibile trovare l'ID AMI associato al modello di avvio. Assicurati che l'AMI esista e sia condivisa con l'account.

  • Gruppo Auto Scaling non trovato: Impossibile trovare il gruppo Auto Scaling associato al gruppo di nodi gestiti. É possibile ricreare un gruppo Auto Scaling con le stesse impostazioni per procedere con il ripristino.

  • Cluster Irraggiungibile: Amazon EKS o uno o più nodi gestiti non sono in grado di comunicare con il server API del cluster Kubernetes. Ciò può verificarsi in caso di interruzioni di rete o se i server API stanno eseguendo il timeout delle richieste di elaborazione.

  • Ec2SecurityGroupNotFound: Impossibile trovare il gruppo di sicurezza per il cluster. È necessario ricreare il cluster.

  • Ec2SecurityGroupDeletionFailure: Impossibile eliminare il gruppo di sicurezza dell'accesso remoto per il gruppo di nodi gestiti. Rimuovi eventuali dipendenze dal gruppo di sicurezza.

  • Modello di avvio Ec2 non trovato: Impossibile trovare il modello di avvio Amazon EC2 per il gruppo di nodi gestiti. È necessario ricreare il gruppo di nodi per proceder con il ripristino.

  • Versione modello di avvio EC2 non corrispondente: La versione del modello di avvio Amazon EC2 per il gruppo di nodi gestiti non corrisponde alla versione creata da Amazon EKS. É possibile regredire alla versione creata da Amazon EKS per il ripristino.

  • Profilo istanza iam non trovato: Impossibile trovare il profilo dell'istanza IAM per il gruppo di nodi gestiti. Potresti ricreare un profilo dell'istanza con le stesse impostazioni per il ripristino.

  • Ruolo iam nodo non trovato: Impossibile trovare il ruolo IAM per il gruppo di nodi gestiti. Potresti ricreare un ruolo IAM con le stesse impostazioni per il ripristino.

  • Errori avvio istanza Asg: Il gruppo Auto Scaling sta riscontrando errori nel tentativo di avviare le istanze.

  • Creazione nodo non riuscita: Le istanze avviate non sono in grado di registrarsi con il cluster Amazon EKS. Le cause comuni di questo fallimento sono le autorizzazioni insufficienti del ruolo IAM del nodo o la mancanza di accesso a Internet in uscita per i nodi. Per funzionare correttamente, i nodi devono essere in grado di accedere a Internet utilizzando un indirizzo IP pubblico. Per ulteriori informazioni, consulta . Assegnazione degli indirizzi IP VPC. I nodi di lavoro devono inoltre avere porte aperte a Internet. Per ulteriori informazioni, consulta . Considerazioni relative al gruppo di sicurezza Amazon EKS.

  • Limite istanze superato: L'account AWS non è in grado di avviare altre istanze del tipo di istanza specificato. É possibile richiedere un aumento del limite di istanze Amazon EC2 per il ripristino.

  • InsufficientFreeAddresses: Una o più sottoreti associate al gruppo di nodi gestiti non dispone di indirizzi IP disponibili sufficienti per i nuovi nodi.

  • Errore interno: Questi errori sono in genere causati da un problema lato server Amazon EKS.

La causa più comune di errori AccessDenied durante l'esecuzione di operazioni su gruppi di nodi gestiti è la mancanza di eks:node-manager ClusterRole o ClusterRoleBinding. Amazon EKS imposta queste risorse nel cluster come parte dell'onboarding con i gruppi di nodi gestiti e queste sono necessarie per la gestione dei gruppi di nodi.

Il ClusterRole può cambiare nel tempo, ma dovrebbe essere simile all'esempio seguente:

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: eks:node-manager rules: - apiGroups: - '' resources: - pods verbs: - get - list - watch - delete - apiGroups: - '' resources: - nodes verbs: - get - list - watch - patch - apiGroups: - '' resources: - pods/eviction verbs: - create

Il ClusterRoleBinding può cambiare nel tempo, ma dovrebbe essere simile all'esempio seguente:

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: eks:node-manager roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eks:node-manager subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: eks:node-manager

Verifica che il eks:node-manager ClusterRole esista.

kubectl describe clusterrole eks:node-manager

Se presente, confrontare l'output con il precedente esempio ClusterRole.

Verifica che il eks:node-manager ClusterRoleBinding esista.

kubectl describe clusterrolebinding eks:node-manager

Se presente, confrontare l'output con il precedente esempio ClusterRoleBinding.

Se viene identificato un oggetto mancante o corrotto ClusterRole o ClusterRoleBinding come causa di un errore AcessDenied durante la richiesta di operazioni di gruppo di nodi gestiti, è possibile ripristinarle. Salva nel computer i seguenti contenuti in un file denominato eks-node-manager-role.yaml.

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: eks:node-manager rules: - apiGroups: - '' resources: - pods verbs: - get - list - watch - delete - apiGroups: - '' resources: - nodes verbs: - get - list - watch - patch - apiGroups: - '' resources: - pods/eviction verbs: - create --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: eks:node-manager roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eks:node-manager subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: eks:node-manager

Applica il file.

kubectl apply -f eks-node-manager-role.yaml

Riprovare l'operazione per il gruppo di nodi per verificare se il problema è stato risolto.

Strumento di raccolta di log CNI

Il plug-in CNI di Amazon VPC per Kubernetes ha il proprio script di risoluzione dei problemi che è disponibile sui nodi a /opt/cni/bin/aws-cni-support.sh. È possibile utilizzare lo script per raccogliere i registri diagnostici per i casi di supporto e per la risoluzione dei problemi generali.

Utilizza il comando seguente per eseguire lo script sul nodo:

sudo bash /opt/cni/bin/aws-cni-support.sh
Nota

Se lo script non è presente in quella posizione, significa che l'esecuzione del container CNI non è andata a buon fine. È possibile scaricare manualmente lo script ed eseguirlo con il seguente comando:

curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh sudo bash eks-log-collector.sh

Lo script raccoglie le seguenti informazioni di diagnostica: La versione CNI implementata può essere precedente alla versione dello script.

This is version 0.6.1. New versions can be found at https://github.com/awslabs/amazon-eks-ami Trying to collect common operating system logs... Trying to collect kernel logs... Trying to collect mount points and volume information... Trying to collect SELinux status... Trying to collect iptables information... Trying to collect installed packages... Trying to collect active system services... Trying to collect Docker daemon information... Trying to collect kubelet information... Trying to collect L-IPAMD information... Trying to collect sysctls information... Trying to collect networking information... Trying to collect CNI configuration information... Trying to collect running Docker containers and gather container data... Trying to collect Docker daemon logs... Trying to archive gathered information... Done... your bundled logs are located in /var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

Le informazioni di diagnostica vengono raccolte e archiviate in:

/var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

Rete tempo di esecuzione container non pronta

È possibile che venga visualizzato un errore Container runtime network not ready ed errori di autorizzazione analoghi al seguente:

4191 kubelet.go:2130] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized 4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized 4191 kubelet_node_status.go:106] Unable to register node "ip-10-40-175-122.ec2.internal" with API server: Unauthorized 4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized

Gli errori sono probabilmente correlati alla mappa di configurazione dell'Autenticatore IAM AWS (aws-auth) che non viene applicata al cluster. La mappa di configurazione fornisce le autorizzazioni RBAC system:bootstrappers e system:nodes Kubernetes per i nodi da registrare al cluster. Per applicare la mappa di configurazione al cluster, consultare Applicare la ConfigMap aws-auth al cluster.

L'autenticatore non riconosce un ARN del ruolo se include un percorso diverso da /, ad esempio nell'esempio seguente:

arn:aws:iam::111122223333:role/development/apps/prod-iam-role-NodeInstanceRole-621LVEXAMPLE

Quando si specifica un ARN del ruolo nella mappa di configurazione che include un percorso diverso da /, è necessario eliminare il percorso. L'ARN menzionato in precedenza verrebbe specificato come segue:

arn:aws:iam::111122223333:role/prod-iam-role-NodeInstanceRole-621LVEXAMPLE

Timeout handshake TLS

Quando un nodo non è in grado di stabilire una connessione all'endpoint del server API pubblico, è possibile che venga visualizzato un errore analogo al seguente.

server.go:233] failed to run Kubelet: could not init cloud provider "aws": error finding instance i-1111f2222f333e44c: "error listing AWS instances: \"RequestError: send request failed\\ncaused by: Post net/http: TLS handshake timeout\""

Il processo kubelet riprenderà continuamente e testerà l'endpoint del server API. L'errore può verificarsi anche temporaneamente durante qualsiasi procedura che esegue un aggiornamento in sequenza del cluster nel piano di controllo, ad esempio una modifica della configurazione o un aggiornamento della versione.

Per risolvere il problema, controllare la tabella di routing e i gruppi di sicurezza per assicurarsi che il traffico proveniente dai nodi possa raggiungere l'endpoint pubblico.

InvalidClientTokenId

Se utilizzi i ruoli IAM per gli account di servizio per un pod o un daemonset implementato in un cluster in una Regione AWS cinese e non hai impostato la variabile di ambiente AWS_DEFAULT_REGION nelle specifiche, il pod o il daemonset potrebbe ricevere il seguente errore:

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid

Per risolvere il problema, è necessario aggiungere la variabile di ambiente AWS_DEFAULT_REGION alla specifica del pod o DaemonSet, come mostrato nella specifica del pod di esempio seguente.

apiVersion: v1 kind: Pod metadata: name: envar-demo labels: purpose: demonstrate-envars spec: containers: - name: envar-demo-container image: gcr.io/google-samples/node-hello:1.0 env: - name: AWS_DEFAULT_REGION value: "region-code"

Scadenza del certificato webhook di ammissione VPC

Se il certificato utilizzato per firmare il webhook di ammissione VPC scade, lo stato per le nuove implementazioni dei pod di Windows rimane a ContainerCreating.

Per risolvere il problema se si dispone del supporto Windows legacy sul piano dati, vedere Rinnovo del certificato webhook di ammissione VPC. Se la versione del cluster e della piattaforma è successiva a una versione elencata nei Prerequisiti del supporto Windows, ti consigliamo di rimuovere il supporto Windows legacy dal piano dati e abilitarlo per il tuo piano di controllo. Una volta fatto, non devi gestire il certificato webhook. Per ulteriori informazioni, consulta . Supporto Windows.

I gruppi di nodi devono corrispondere alla versione di Kubernetes prima di poter aggiornare il piano di controllo

Prima di aggiornare il piano di controllo a una nuova versione di Kubernetes, assicurarsi che la versione secondaria dei nodi gestiti e Fargate nel cluster sia la stessa della versione corrente del piano di controllo. L’API update-cluster-version EKS rifiuta le richieste fino a quando non si aggiornano tutti i nodi gestiti EKS alla versione corrente del cluster. EKS fornisce API per aggiornare i nodi gestiti. Per informazioni sull'aggiornamento delle versioni di Kubernetes del gruppo di nodi gestiti, vedere Aggiornamento di un gruppo di nodi gestiti. Per aggiornare la versione di un nodo Fargate, eliminare il pod rappresentato dal nodo e implementare nuovamente il pod dopo aver aggiornato il piano di controllo. Per ulteriori informazioni, consulta . Aggiornamento di un cluster.

Quando si lanciano molti nodi, vengono visualizzati messaggi di errore Too Many Requests

Se lanci contemporaneamente molti nodi, può essere visualizzato un messaggio di errore che recita Waiter ClusterActive failed: Too Many Requests. Ciò può verificarsi perché il piano di controllo è sovraccarico di chiamate describeCluster. Il sovraccarico si traduce in limitazioni, nei nodi che non eseguono lo script bootstrap e che non riescono ad aggiungersi al cluster.

Assicurati di impostare i valori per gli argomenti --apiserver-endpoint, --b64-cluster-ca e --dns-cluster-ip. Quando includi questi argomenti, non è necessario che lo script bootstrap crei una chiamata describeCluster per impedire che il piano di controllo si sovraccarichi. Per ulteriori informazioni, consulta . Specifica di un'AMI.