Risoluzione dei problemi di Amazon EKS - Amazon EKS

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 di Amazon EKS

Questo capitolo presenta alcuni errori comuni che si potrebbero verificare durante l'uso di Amazon EKS e il modo in cui gestirli. Se devi risolvere problemi in aree specifiche di Amazon EKS, consulta gli argomenti separati Risoluzione dei problemi di IAM, Risoluzione dei problemi in Amazon EKS Connector e Risoluzione dei problemi di ADOT utilizzando i componenti aggiuntivi EKS.

Per altre informazioni sulla risoluzione dei problemi, consulta i Contenuti del Knowledge Center su Amazon Elastic Kubernetes Service su AWS re:Post.

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.

Ci sono zone di disponibilità dove non è possibile allocare un cluster. Confronta le zone di disponibilità in cui si trovano le tue sottoreti con l'elenco delle zone di disponibilità nella sezione Considerazioni e requisiti relativi alle sottoreti.

Impossibile aggiungere i nodi al cluster

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

  • Se i nodi sono gestiti, Amazon EKS aggiunge voci ad aws-auth ConfigMap quando crei il gruppo di nodi. Se la voce è stata rimossa o modificata, è necessario aggiungerla nuovamente. Per ulteriori informazioni, digita eksctl create iamidentitymapping --help nel terminale. Puoi verificare la versione corrente delle voci aws-auth ConfigMap sostituendo my-cluster nel seguente comando con il nome del tuo cluster e quindi eseguendo il comando modificato: eksctl get iamidentitymapping --cluster my-cluster. L'ARN del ruolo specificato non può includere un percorso diverso da /. Ad esempio, se il nome del ruolo è development/apps/my-role, è necessario modificarlo in my-role quando si specifica l'ARN per tale ruolo. Assicurati di specificare l'ARN del ruolo IAM del nodo (non l'ARN del profilo dell'istanza).

    Se i nodi sono autogestiti e non hai creato voci di accesso per l'ARN del ruolo IAM del nodo, esegui gli stessi comandi elencati per i nodi gestiti. Se hai creato una voce di accesso per l'ARN del tuo ruolo IAM del nodo, è possibile che non sia configurata correttamente nella suddetta voce di accesso. Assicurati che l'ARN del ruolo IAM del nodo (e non l'ARN del profilo dell'istanza) sia specificato come ARN principale nella tua voce aws-auth ConfigMap o voce di accesso. Per ulteriori informazioni sulle voci di accesso, consulta la sezione Consentire ai ruoli o agli utenti IAM di accedere agli oggetti Kubernetes sul cluster Amazon EKS.

  • Il AWS CloudFormation modello ClusterNamenel tuo nodo non corrisponde esattamente al nome del cluster a cui desideri che i tuoi nodi si uniscano. 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 verranno aggiunti al cluster.

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

    Chiave Valore

    kubernetes.io/cluster/my-cluster

    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, consulta Associazione di un indirizzo IP elastico a un'istanza o a un'interfaccia di rete in esecuzione. Se nella sottorete pubblica non è impostata l'assegnazione degli indirizzi IP pubblici alle istanze implementate, è consigliabile abilitare l'impostazione. Per ulteriori informazioni, consulta Modifica dell'attributo di assegnazione degli indirizzi IPv4 pubblici per la sottorete. Se il nodo viene implementato in una sottorete privata, la sottorete deve disporre di un instradamento verso un gateway NAT a cui è assegnato un indirizzo IP pubblico.

  • L' AWS STS endpoint su Regione AWS cui stai distribuendo i nodi non è abilitato per il tuo account. Per abilitare la regione, vedi Attivazione e AWS STS disattivazione in un. Regione AWS

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

  • Se i nodi del gruppo di nodi gestiti non si connettono al cluster entro 15 minuti, verrà emesso un problema di integrità pari a «NodeCreationFailure» e lo stato della console verrà impostato su. Create failed Per le Windows AMI con tempi di avvio lenti, questo problema può essere risolto utilizzando l'avvio rapido.

Per identificare e risolvere i problemi più comuni che impediscono ai nodi worker di unirsi a un cluster, puoi utilizzare il runbook AWSSupport-TroubleshootEKSWorkerNode. Per ulteriori informazioni, consulta AWSSupport-TroubleshootEKSWorkerNode in Documentazione di riferimento del runbook di AWS Systems Manager Automation.

Accesso negato o non autorizzato (kubectl)

Se ricevi uno dei seguenti errori durante l'esecuzione di comandi kubectl, allora kubectl non è configurato correttamente per Amazon EKS, oppure le credenziali del principale IAM (ruolo o utente) in uso non sono mappate a un nome utente Kubernetes con autorizzazioni sufficienti per gli oggetti Kubernetes nel tuo 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 a uno dei seguenti fattori:

Se installi e configuri AWS CLI, puoi configurare le credenziali IAM che utilizzi. Per ulteriori informazioni, consulta Configurazione della AWS CLI nella Guida per l'utente di AWS Command Line Interface . Puoi anche configurare kubectl affinché utilizzi un ruolo IAM, se assumi un ruolo IAM per accedere agli oggetti Kubernetes sul tuo cluster. Per ulteriori informazioni, consulta Creazione o aggiornamento di un file kubeconfig per un cluster Amazon EKS.

hostname doesn't match

La versione Python del sistema deve essere 2.7.9 o successiva. In caso contrario, riceverai hostname doesn't match errori nelle AWS CLI chiamate ad Amazon EKS. Per ulteriori informazioni, consulta What are "hostname doesn't match" errors? 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, riceverai il seguente messaggio di errore:

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

Instances failed to join the Kubernetes cluster

Se ricevi l'errore Instances failed to join the Kubernetes cluster in AWS Management Console, assicurati che l'accesso privato agli endpoint del cluster sia abilitato o di aver configurato correttamente i blocchi CIDR per l'accesso pubblico agli endpoint. Per ulteriori informazioni, consulta Controllo accessi all'endpoint del cluster Amazon EKS.

Codici di errore dei gruppi di nodi gestiti

Se il gruppo di nodi gestiti rileva un problema di integrità hardware, Amazon EKS restituisce un codice 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. Nel seguente elenco vengono descritti i codici di errore.

AccessDenied

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 un problema comune, consulta Risoluzione di una causa comune di errori AccessDenied per i gruppi di nodi gestiti. Le AMI Windows private possono causare anche questo codice di errore insieme al messaggio di errore Not authorized for images. Per ulteriori informazioni, consulta Not authorized for images.

AmiIdNotFound

Non è stato possibile trovare l'ID AMI associato al modello di avvio. Assicurati che l'AMI esista e sia condivisa con l'account.

AutoScalingGroupNotFound

Non è stato possibile trovare il gruppo con dimensionamento automatico associato al gruppo di nodi gestiti. Potresti ricreare un gruppo con dimensionamento automatico con le stesse impostazioni per procedere con il ripristino.

ClusterUnreachable

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.

Ec2 SecurityGroupNotFound

Non è stato possibile trovare il gruppo di sicurezza per il cluster. È necessario ricreare il cluster.

Ec2 SecurityGroupDeletionFailure

Non è stato possibile eliminare il gruppo di sicurezza dell'accesso remoto per il gruppo di nodi gestiti. Rimuovi eventuali dipendenze dal gruppo di sicurezza.

Ec2 LaunchTemplateNotFound

Non è stato possibile trovare il modello di avvio Amazon EC2 per il gruppo di nodi gestiti. È necessario ricreare il gruppo di nodi per procedere con il ripristino.

Ec2 LaunchTemplateVersionMismatch

La versione del modello di avvio Amazon EC2 per il gruppo di nodi gestiti non corrisponde alla versione creata da Amazon EKS. Puoi regredire alla versione creata da Amazon EKS per il ripristino.

IamInstanceProfileNotFound

Non è stato possibile 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.

IamNodeRoleNotFound

Non è stato possibile trovare il ruolo IAM per il gruppo di nodi gestiti. Potresti ricreare un ruolo IAM con le stesse impostazioni per il ripristino.

AsgInstanceLaunchFailures

Il gruppo con dimensionamento automatico sta riscontrando errori nel tentativo di avviare le istanze.

NodeCreationFailure

Le istanze avviate non sono in grado di registrarsi con il cluster Amazon EKS. Le cause comuni di questo errore sono le autorizzazioni insufficienti del ruolo IAM del nodo o la mancanza di accesso a Internet in uscita per i nodi. I nodi devono soddisfare uno dei requisiti seguenti:

InstanceLimitExceeded

Il tuo AWS account non è in grado di avviare altre istanze del tipo di istanza specificato. Potresti 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.

InternalFailure

Questi errori sono in genere causati da un problema lato server Amazon EKS.

La causa più comune degli 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

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

Not authorized for images

Una potenziale causa di un messaggio di errore Not authorized for images è l'uso di un'AMI Windows di Amazon EKS privata per avviare gruppi di nodi gestiti da Windows. Dopo aver rilasciato nuove Windows AMI, AWS rende private le AMI più vecchie di 4 mesi, il che le rende non più accessibili. Se il tuo gruppo di nodi gestiti utilizza un'WindowsAMI privata, valuta la possibilità di aggiornare il gruppo di nodi Windows gestiti. Sebbene non possiamo garantire di poter fornire l'accesso alle AMI che sono state rese private, puoi richiedere l'accesso inviando un ticket a Support AWS . Per ulteriori informazioni, consulta Patch, aggiornamenti di sicurezza e ID AMI nella Guida per l'utente di Amazon EC2 per le istanze Windows.

Il nodo è in stato NotReady

Se il nodo entra in uno NotReady stato, è probabile che ciò indichi che il nodo non è integro e non è possibile pianificarne uno nuovoPods. Ciò può verificarsi per vari motivi, ad esempio se il nodo non dispone di risorse sufficienti per la CPU, la memoria o lo spazio disponibile su disco.

Per le Windows AMI ottimizzate per Amazon EKS, non è prevista alcuna prenotazione per le risorse di calcolo specificate di default nella kubelet configurazione. Per evitare problemi di risorse, puoi riservare risorse di calcolo per i processi di sistema fornendo loro valori kubelet di configurazione per e/o. kube-reservedsystem-reserved Questa operazione viene eseguita utilizzando il parametro della -KubeletExtraArgs riga di comando nello script bootstrap. Per ulteriori informazioni, consulta Reserve Compute Resources for System Daemons nella Kubernetes documentazione e i parametri di configurazione dello script Bootstrap in questa guida per l'utente.

Strumento di raccolta di log CNI

Il Amazon VPC CNI plugin for Kubernetes ha il proprio script di risoluzione dei problemi che è disponibile sui nodi in /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. Puoi scaricare manualmente lo script ed eseguirlo con il comando seguente:

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 runtime container non pronta

Potresti visualizzare 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

Questo può verificarsi per uno dei seguenti motivi:

  1. Non disponi di aws-auth ConfigMap sul tuo cluster oppure non include voci per il ruolo IAM con cui hai configurato i tuoi nodi.

    Questa voce ConfigMap è necessaria se i nodi soddisfano uno dei seguenti criteri:

    Per risolvere il problema, verifica le voci esistenti in ConfigMap sostituendo my-cluster nel seguente comando con il nome del tuo cluster e quindi eseguendo il comando modificato: eksctl get iamidentitymapping --cluster my-cluster. Se ricevi un messaggio di errore dal comando, è possibile che il cluster non disponga di aws-auth ConfigMap. Il comando seguente aggiunge una voce a ConfigMap. Inoltre, se ConfigMap non esiste, viene creata dal comando. Sostituisci 111122223333 con l' Account AWS ID per il ruolo IAM e myAmazoneks NodeRole con il nome del ruolo del tuo nodo.

    eksctl create iamidentitymapping --cluster my-cluster \ --arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole --group system:bootstrappers,system:nodes \ --username system:node:{{EC2PrivateDNSName}}

    L'ARN del ruolo specificato non può includere un percorso diverso da /. Ad esempio, se il nome del tuo ruolo è development/apps/my-role, dovresti cambiarlo in my-role quando specifichi l'ARN del ruolo. Assicurati di specificare l'ARN del ruolo IAM del nodo (non l'ARN del profilo dell'istanza).

  2. I nodi autogestiti si trovano in un cluster con una versione della piattaforma che corrisponde a quella minima elencata nei prerequisiti dell'argomento Consentire ai ruoli o agli utenti IAM di accedere agli oggetti Kubernetes sul cluster Amazon EKS, tuttavia una voce non è elencata in aws-auth ConfigMap (vedi l'elemento precedente) per il ruolo IAM del nodo oppure non esiste una voce di accesso per il ruolo. Per risolvere il problema, verifica le tue voci di accesso esistenti sostituendo my-cluster nel seguente comando con il nome del tuo cluster e quindi eseguendo il comando modificato: aws eks list-access-entries --cluster-name my-cluster. Il comando seguente aggiunge una voce di accesso per il ruolo IAM del nodo. Sostituisci 111122223333 con l' Account AWS ID per il ruolo IAM e NodeRolemyAmazoneks con il nome del ruolo del tuo nodo. Se hai un nodo Windows, sostituisci EC2_Linux con EC2_Windows. Assicurati di specificare l'ARN del ruolo IAM del nodo (non l'ARN del profilo dell'istanza).

    aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole --type EC2_Linux

Timeout dell'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, controlla la tabella di routing e i gruppi di sicurezza per assicurarti che il traffico proveniente dai nodi possa raggiungere l'endpoint pubblico.

InvalidClientTokenId

Se utilizzi i ruoli IAM per gli account di servizio di un cluster in Cina Pod o li hai DaemonSet distribuiti in un cluster in Cina Regione AWS e non hai impostato la variabile di AWS_DEFAULT_REGION ambiente nelle specifiche, il sistema operativo potrebbe ricevere il seguente errore: Pod DaemonSet

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 di 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 del VPC

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

Per risolvere il problema se disponi del supporto Windows legacy sul piano dati, consulta Rinnovo del certificato webhook di ammissione VPC. Se le versioni del cluster e della piattaforma sono successive a una versione elencata in 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 Abilitazione del supporto di Windows per il cluster Amazon EKS.

Prima di poter aggiornare il piano di controllo i gruppi di nodi devono corrispondere alla versione di Kubernetes

Prima di aggiornare il piano di controllo a una nuova versione di Kubernetes, assicurati 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 di Amazon EKS rifiuta le richieste fino a quando non si aggiornano tutti i nodi gestiti Amazon EKS alla versione corrente del cluster. Amazon EKS fornisce API per aggiornare i nodi gestiti. Per informazioni sull'aggiornamento delle versioni di Kubernetes del gruppo di nodi gestiti, consulta la sezione Aggiornamento di un gruppo di nodi gestiti. Per aggiornare la versione di un nodo Fargate, elimina il pod rappresentato dal nodo e implementa nuovamente il pod dopo aver aggiornato il piano di controllo. Per ulteriori informazioni, consulta Aggiornamento della versione di Kubernetes del cluster Amazon EKS.

All'avvio di molti nodi, si verificano errori Too Many Requests

Se si avviano più nodi contemporaneamente, si potrebbe visualizzare il messaggio di errore Too Many Requests nei registri di esecuzione dei dati utente di Amazon EC2. Ciò può verificarsi perché il piano di controllo è sovraccarico di chiamate describeCluster. Il sovraccarico si traduce in limitazione (della larghezza di banda della rete), nodi che non eseguono lo script bootstrap e nodo che non vengono aggiunti al cluster.

Assicurarti che gli argomenti --apiserver-endpoint, --b64-cluster-ca e --dns-cluster-ip vengano trasferiti allo script di bootstrap del nodo. Quando includi questi argomenti, non è necessario che lo script bootstrap crei una chiamata describeCluster. Ciò contribuisce a impedire che il piano di controllo si sovraccarichi. Per ulteriori informazioni, consulta Fornire i dati utente per passare argomenti al file bootstrap.sh incluso nell'AMI Linux/Bottlerocket ottimizzata per Amazon EKS.

Risposta agli errori HTTP 401 Autorizzazione negata per le richieste del server API Kubernetes

Questi errori vengono visualizzati se il token dell'account di servizio di un Pod è scaduto in un cluster.

Il server API Kubernetes del cluster Amazon EKS rifiuta le richieste con token più vecchi di 90 giorni. Nelle versioni di Kubernetes precedenti, i token non avevano una scadenza. Di conseguenza, i client che si basano su questi token devono aggiornarli entro un'ora. Per impedire al server API Kubernetes di rifiutare la richiesta a causa di un token non valido, la versione dell'SDK client Kubernetes utilizzata dal carico di lavoro deve essere uguale o successiva alle versioni riportate di seguito:

  • Go versione 0.15.7 e successive

  • Python versione 12.0.0 e successive

  • Java versione 9.0.0 e successive

  • JavaScript versione 0.10.3 e successive

  • Ramo master di Ruby

  • Haskell versione 0.3.0.0

  • C# versione 7.0.5 e successive

Puoi identificare tutti i Pods esistenti nel cluster che utilizzano token obsoleti. Per ulteriori informazioni, consulta Account del servizio Kubernetes.

La versione della piattaforma Amazon EKS è più avanti di due versioni rispetto all'attuale versione della piattaforma

Questo può accadere quando Amazon EKS non è in grado di aggiornare automaticamente la versione della piattaforma del i cluster. Sebbene ci siano molte cause, di seguito riportiamo quelle più comuni. Se uno di questi problemi si applica al tuo cluster, potrebbe ancora funzionare, ma la sua versione della piattaforma non verrà aggiornata da Amazon EKS.

Problema

Il ruolo IAM del cluster è stato eliminato: questo ruolo è stato specificato al momento della creazione del cluster. Puoi visualizzare quale ruolo è stato specificato con il seguente comando. Sostituisci my-cluster con il nome del tuo cluster.

aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2

Di seguito viene riportato un output di esempio:

eksClusterRole
Soluzione

Crea un nuovo ruolo IAM del cluster con lo stesso nome.

Problema

Una sottorete specificata durante la creazione del cluster è stata eliminata: le sottoreti da utilizzare con il cluster sono state specificate durante la creazione del cluster. Puoi visualizzare le sottoreti specificate con il seguente comando. Sostituisci my-cluster con il nome del tuo cluster.

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

Di seguito viene riportato un output di esempio:

[
"subnet-EXAMPLE1",
"subnet-EXAMPLE2"
]
Soluzione

Verifica se gli ID di sottorete esistono nel tuo account.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text) aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" --query "Subnets[*].SubnetId"

Di seguito viene riportato un output di esempio:

[
"subnet-EXAMPLE3",
"subnet-EXAMPLE4"
]

Nel caso in cui gli ID di sottorete restituiti nell'output non corrispondano agli ID di sottorete specificati al momento della creazione del cluster, se desideri che Amazon EKS aggiorni il cluster, devi modificare le sottoreti utilizzate dal cluster. Questo perché se hai specificato più di due sottoreti al momento della creazione del cluster, Amazon EKS seleziona in modo casuale le sottoreti specificate in cui creare nuove interfacce di rete elastiche. Queste interfacce di rete consentono al piano di controllo di comunicare con i nodi. Amazon EKS non aggiornerà il cluster se la sottorete selezionata non esiste. Non hai alcun controllo su quale delle sottoreti specificate al momento della creazione del cluster Amazon EKS sceglie per creare una nuova interfaccia di rete.

Quando avvii un aggiornamento della versione di Kubernetes per il cluster, l'aggiornamento può non riuscire per lo stesso motivo.

Problema

Un gruppo di sicurezza specificato durante la creazione del cluster è stato eliminato: se durante la creazione del cluster hai specificato dei gruppi di sicurezza, puoi visualizzarne gli ID con il seguente comando. Sostituisci my-cluster con il nome del tuo cluster.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.securityGroupIds

Di seguito viene riportato un output di esempio:

[
    "sg-EXAMPLE1"
]

Se viene restituito [], allora non sono stati specificati gruppi di sicurezza al momento della creazione del cluster e il problema non è dato dalla mancanza di un gruppo di sicurezza. Se vengono restituiti i gruppi di sicurezza, conferma che i gruppi di sicurezza sono presenti nel tuo account.

Soluzione

Verifica se questi gruppi di sicurezza esistono nel tuo account.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text) aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$vpc_id" --query "SecurityGroups[*].GroupId"

Di seguito viene riportato un output di esempio:

[
"sg-EXAMPLE2"
]

Se desideri che Amazon EKS aggiorni il cluster, nel caso in cui gli ID dei gruppi di sicurezza restituiti nell'output non corrispondano agli ID dei gruppi di sicurezza specificati al momento della creazione del cluster, devi modificare i gruppi di sicurezza utilizzati dal cluster. Amazon EKS non aggiornerà un cluster se gli ID dei gruppi di sicurezza specificati al momento della creazione del cluster non esistono.

Quando avvii un aggiornamento della versione di Kubernetes per il cluster, l'aggiornamento può non riuscire per lo stesso motivo.

Altri motivi per cui Amazon EKS non aggiorna la versione della piattaforma del tuo cluster
  • Non hai almeno sei (anche se ne consigliamo 16) indirizzi IP disponibili in ciascuna delle sottoreti specificate al momento della creazione del cluster. Se non disponi di un numero sufficiente di indirizzi IP disponibili nella sottorete, dovrai liberare gli indirizzi IP nella sottorete oppure modificare le sottoreti utilizzate dal cluster in modo da utilizzare le sottoreti con un numero sufficiente di indirizzi IP disponibili.

  • Hai abilitato la crittografia dei segreti quando hai creato il cluster e la AWS KMS chiave specificata è stata eliminata. Se desideri che Amazon EKS aggiorni il cluster, devi crearne uno nuovo

Domande frequenti sullo stato del cluster e codici di errore con percorsi di risoluzione

Amazon EKS rileva problemi con i cluster EKS e l'infrastruttura del cluster e li archivia in integrità del cluster. Grazie alle informazioni sull'integrità del cluster è possibile rilevare, risolvere e affrontare più rapidamente eventuali problemi. Ciò consente di creare ambienti applicativi più sicuri e up-to-date. Inoltre, è possibile che tu non possa effettuare l'aggiornamento a versioni più recenti di Kubernetes o che Amazon EKS non sia in grado di installare aggiornamenti di sicurezza su un cluster degradato a causa di problemi relativi all'infrastruttura necessaria o alla configurazione del cluster. Amazon EKS può impiegare tre ore per rilevare problemi o verificare che un problema è stato risolto.

L'integrità di un cluster Amazon EKS rappresenta una responsabilità condivisa tra Amazon EKS e i suoi utenti. Sei responsabile dell'infrastruttura indispensabile per i ruoli IAM e le sottoreti Amazon VPC, nonché di altre infrastrutture necessarie, che devono essere fornite anticipatamente. Amazon EKS rileva le modifiche nella configurazione di questa infrastruttura e del cluster.

Per accedere all'integrità del cluster nella console Amazon EKS, è necessario trovare una sezione chiamata Problemi di integrità nella scheda Panoramica della pagina dei dettagli del cluster Amazon EKS. Questi dati saranno disponibili anche richiamando l'azione DescribeCluster nell'API EKS, ad esempio dall'interno della AWS Command Line Interface.

Qual è il vantaggio di utilizzare questa funzionalità?

Otterrai una maggiore visibilità sullo stato del tuo cluster Amazon EKS, diagnosticherai e risolverai rapidamente eventuali problemi, senza dover dedicare tempo al debug o all'apertura di casi di supporto. AWS Ad esempio: hai eliminato accidentalmente una sottorete per il cluster Amazon EKS, Amazon EKS non sarà in grado di creare interfacce e Kubernetes AWS CLI comandi di rete tra account come kubectl exec o logs. kubectl Queste operazioni non riusciranno e restituiranno l'errore: Error from server: error dialing backend: remote error: tls: internal error. Ora sarà visualizzato un problema di integrità di Amazon EKS con il seguente messaggio: subnet-da60e280 was deleted: could not create network interface.

In che modo questa funzionalità si collega o funziona con altri servizi? AWS

I ruoli IAM e le sottoreti Amazon VPC sono due esempi di elementi dell'infrastrutture indispensabile per i quali l'integrità del cluster può rilevare problemi. Se tali risorse non sono configurate correttamente, questa funzionalità restituirà informazioni dettagliate.

Un cluster con problemi di integrità comporta costi?

Sì, ogni cluster Amazon EKS viene fatturato ai prezzi standard di Amazon EKS. La funzionalità integrità del cluster è disponibile senza costi aggiuntivi.

Questa funzionalità funziona con i cluster Amazon EKS su AWS Outposts?

Sì, vengono rilevati problemi di cluster per i cluster EKS nel AWS cloud, inclusi i cluster estesi attivi AWS Outposts e i cluster locali attivi. AWS Outposts L'integrità del cluster non rileva problemi con Amazon EKS Anywhere o Amazon EKS Distro (EKS-D).

Posso ricevere una notifica quando vengono rilevati nuovi problemi?

No, è necessario controllare la console Amazon EKS o effettuare una chiamata all'API DescribeCluster di EKS.

La console mi avvisa in caso di problemi di integrità?

Sì, qualsiasi cluster con problemi di integrità presenterà un banner di avviso nella parte superiore della console.

Le prime due colonne sono quelle necessarie per i valori di risposta dell'API. Il terzo campo dell' ClusterIssueoggetto Health èresourceIds, la cui restituzione dipende dal tipo di problema.

Codice Messaggio ResourceIds Cluster recuperabile?

SUBNET_NOT_FOUND

Non è stato possibile trovare una o più sottoreti attualmente associate al tuo cluster. Effettua una chiamata all'API update-cluster-config di Amazon EKS per aggiornare le sottoreti.

ID sottorete
SECURITY_GROUP_NOT_FOUND Non è stato possibile trovare uno o più gruppi di sicurezza attualmente associati al tuo cluster. Chiama l' update-cluster-config API Amazon EKS per aggiornare i gruppi di sicurezza ID gruppo di sicurezza
IP_NOT_AVAILABLE Una o più sottoreti associate al cluster non dispone di indirizzi IP disponibili sufficienti per consentire ad Amazon EKS di eseguire operazioni di gestione dei cluster. Libera indirizzi nelle sottoreti o associa diverse sottoreti al cluster utilizzando l'API Amazon EKS. update-cluster-config ID sottorete
VPC_NOT_FOUND Non è stato possibile trovare il VPC associato al cluster. È necessario eliminare e ricreare il cluster. ID VPC No
ASSUME_ROLE_ACCESS_DENIED Il tuo cluster non utilizza Amazon EKS service-linked-role. Non è stato possibile assumere il ruolo associato al tuo cluster per eseguire le operazioni di gestione di Amazon EKS richieste. Verifica che il ruolo esista e disponga della policy di attendibilità richiesta. Ruolo IAM del cluster

PERMISSION_ACCESS_DENIED

Il tuo cluster non utilizza Amazon EKS service-linked-role. Il ruolo associato al tuo cluster non concede autorizzazioni sufficienti ad Amazon EKS per eseguire le operazioni di gestione richieste. Verifica le policy associate al ruolo del cluster e controlla se vengono applicate policy di negazione separate. Ruolo IAM del cluster

ASSUME_ROLE_ACCESS_DENIED_USING_SLR

Non potevamo supporre la gestione del cluster Amazon EKS service-linked-role. Verifica che il ruolo esista e disponga della policy di attendibilità richiesta. Amazon EKS service-linked-role

PERMISSION_ACCESS_DENIED_USING_SLR

La gestione dei cluster Amazon EKS service-linked-role non concede autorizzazioni sufficienti ad Amazon EKS per eseguire le operazioni di gestione richieste. Verifica le policy associate al ruolo del cluster e controlla se vengono applicate policy di negazione separate.

Amazon EKS service-linked-role

OPT_IN_REQUIRED

Il tuo account non dispone di un abbonamento al servizio Amazon EC2. Aggiorna gli abbonamenti del tuo account nella pagina delle impostazioni dell'account.

N/D

STS_REGIONAL_ENDPOINT_DISABLED

L'endpoint regionale STS è disabilitato. Abilita l'endpoint per Amazon EKS per eseguire le operazioni di gestione dei cluster richieste.

N/D

KMS_KEY_DISABLED

La AWS KMS chiave associata al cluster è disabilitata. Riabilita la chiave per ripristinare il cluster.

Il KMS Key Arn

KMS_KEY_NOT_FOUND

Non siamo riusciti a trovare la AWS KMS chiave associata al tuo cluster. È necessario eliminare e ricreare il cluster.

Il KMS Key ARN

No

KMS_GRANT_REVOKED

Le concessioni per la AWS KMS chiave associata al tuo cluster vengono revocate. È necessario eliminare e ricreare il cluster.

Il KMS Key Arn

No