Risolvi i problemi con i EKS cluster e i nodi Amazon

Questo capitolo descrive alcuni errori comuni che potresti riscontrare durante l'utilizzo di Amazon EKS e come aggirarli. Se hai bisogno di risolvere EKS aree Amazon specifiche, consulta gli argomenti separati Risoluzione dei problemi relativi a IAM e Risoluzione dei problemi per l'ADOTutilizzo dei EKS componenti aggiuntivi. Risolvi i problemi relativi ad Amazon Connector EKS

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

Capacità insufficiente

Se ricevi il seguente errore durante il tentativo di creare un EKS cluster Amazon, significa che una delle zone di disponibilità che hai specificato non ha una 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 creare il cluster con le sottoreti del cluster ospitate nelle zone di disponibilità restituite da VPC questo messaggio di errore.

Esistono zone di disponibilità in cui un cluster non può risiedere. Confronta le zone di disponibilità in cui si trovano le tue sottoreti con l'elenco delle zone di disponibilità nella sezione Requisiti e considerazioni sulla Considerazioni e requisiti relativi alle sottoreti sottorete.

Impossibile aggiungere i nodi al cluster

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

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, vedere il riferimento AWSSupport-TroubleshootEKSWorkerNode al runbook di riferimento di AWS Systems Manager Automation.

Accesso negato o non autorizzato (kubectl)

Se ricevi uno dei seguenti errori durante l'esecuzione dei kubectl comandi, significa che non hai kubectl configurato correttamente per Amazon EKS o le credenziali per il IAM principale (ruolo o utente) che stai utilizzando non sono mappate a un Kubernetes nome utente con autorizzazioni sufficienti per Kubernetes oggetti sul tuo EKS cluster Amazon.

Questo potrebbe essere dovuto a uno dei seguenti fattori:

Se si installa e si configura il AWS CLI, è possibile configurare IAM le credenziali utilizzate. Per ulteriori informazioni, vedere Configurazione della Guida per l'utente dell'interfaccia AWS CLI a riga di AWS comando. È inoltre possibile kubectl configurare l'utilizzo di un IAM ruolo, se si assume un IAM ruolo di accesso Kubernetes oggetti sul tuo cluster. Per ulteriori informazioni, consulta Connect kubectl a un EKS cluster creando un file kubeconfig.

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 verso AmazonEKS. Per ulteriori informazioni, consulta Cosa sono gli errori «il nome host non corrisponde»? nelle Domande frequenti sulle richieste di Python.

getsockopt: no route to host

Docker viene eseguito nell'172.17.0.0/16CIDRintervallo nei EKS cluster Amazon. Ti consigliamo che le VPC sottoreti del tuo 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 CIDR blocchi per l'accesso pubblico agli endpoint. Per ulteriori informazioni, consulta Controlla l'accesso alla rete all'endpoint API del server del cluster.

Codici di errore dei gruppi di nodi gestiti

Se il tuo gruppo di nodi gestiti riscontra un problema di integrità dell'hardware, Amazon EKS restituisce un codice di errore per aiutarti a diagnosticare il problema. Questi controlli sanitari non rilevano problemi software perché si basano sui controlli EC2 sanitari di Amazon. Nel seguente elenco vengono descritti i codici di errore.

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

kubectl describe clusterrole eks:node-manager

kubectl describe clusterrolebinding eks:node-manager

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

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

Not authorized for images

Una potenziale causa di un messaggio di Not authorized for images errore è l'utilizzo di un Amazon privato EKS Windows AMIlanciare Windows gruppi di nodi gestiti. Dopo aver rilasciato nuovi Windows AMIs, AWS rende privati AMIs i file più vecchi di 4 mesi, il che li rende non più accessibili. Se il gruppo di nodi gestito utilizza un nodo privato Windows AMI, valuta la possibilità di Aggiorna un gruppo di nodi gestiti per il tuo cluster aggiornare il gruppo di nodi gestiti di Windows. Sebbene non possiamo garantire di poter fornire l'accesso a AMIs ciò che è stato reso privato, puoi richiedere l'accesso inviando un ticket a AWS Support. Per ulteriori informazioni, consulta Patches nella Amazon EC2 User Guide.

Il nodo è in NotReady stato

Se il nodo entra in uno NotReady stato, è probabile che ciò indichi che il nodo non è integro e non è disponibile per programmarne uno nuovo Pods. Ciò può verificarsi per vari motivi, ad esempio la mancanza di risorse sufficienti per il nodoCPU, di memoria o di spazio su disco disponibile.

EKSOttimizzato per Amazon Windows AMIs, non è prevista alcuna prenotazione per le risorse di elaborazione specificate di default nella kubelet configurazione. Per evitare problemi relativi alle risorse, puoi riservare le risorse di calcolo per i processi di sistema fornendo loro i kubelet valori di configurazione per kube-reserved e/o system-reserved. È possibile eseguire questa operazione utilizzando il parametro della riga di -KubeletExtraArgs comando nello script bootstrap. Per ulteriori informazioni, vedete Reserve Compute Resources for System Daemons nel Kubernetes nella documentazione e Parametri di configurazione dello script di bootstrap in questa guida per l'utente.

CNIstrumento di raccolta dei registri

Il Amazon VPC CNI plugin for Kubernetes dispone di un proprio script di risoluzione dei problemi disponibile sui nodi all'indirizzo/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

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 CNI versione che hai distribuito 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:

TLShandshake (timeout)

Quando un nodo non è in grado di stabilire una connessione all'endpoint del API server pubblico, è possibile che venga visualizzato un errore simile 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 kubelet processo verrà riavviato e testato continuamente l'endpoint del API server. 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 IAM ruoli per gli account di servizio per un Pod oppure DaemonSet distribuito in un cluster in una AWS regione della Cina e non ho impostato la variabile di AWS_DEFAULT_REGION ambiente nelle specifiche, Pod oppure 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 AWS_DEFAULT_REGION ambiente al Pod oppure DaemonSet spec, come illustrato nell'esempio seguente Pod spec.

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"

I gruppi di nodi devono corrispondere Kubernetes versione prima dell'aggiornamento del piano di controllo

Prima di aggiornare un piano di controllo a uno nuovo Kubernetes versione, la versione secondaria dei nodi gestiti e Fargate nel cluster deve essere la stessa della versione corrente del piano di controllo. Amazon EKS update-cluster-version API rifiuta le richieste finché non esegui l'upgrade di tutti i nodi EKS gestiti da Amazon alla versione corrente del cluster. Amazon EKS fornisce APIs l'aggiornamento dei nodi gestiti. Per informazioni sull'aggiornamento di un gruppo di nodi gestiti Kubernetes versione, vedi. Aggiorna un gruppo di nodi gestiti per il tuo cluster Per aggiornare la versione di un nodo Fargate, elimina il pod è rappresentato dal nodo e ridistribuisci il pod dopo aver aggiornato il piano di controllo. Per ulteriori informazioni, consulta Aggiorna il cluster esistente alla nuova versione di Kubernetes.

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

Se avvii più nodi contemporaneamente, potresti visualizzare un messaggio di errore nei log di esecuzione dei dati EC2 degli utenti di Amazon che diceToo Many Requests. 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.

Assicurati che --apiserver-endpoint--b64-cluster-ca, e --dns-cluster-ip gli argomenti vengano passati allo script di bootstrap del nodo. Quando si includono questi argomenti, non è necessario che lo script bootstrap effettui una describeCluster chiamata, il che aiuta a prevenire il sovraccarico del piano di controllo. Per ulteriori informazioni, consulta Fornisci i dati utente per passare argomenti al bootstrap.sh file incluso in un programma EKS ottimizzato per Amazon Linux/Bottlerocket AMI.

HTTP401 risposta di errore non autorizzata su Kubernetes APIrichieste del server

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

I tuoi EKS cluster Amazon Kubernetes APIil server rifiuta le richieste con token più vecchi di 90 giorni. In precedenza Kubernetes nelle versioni, i token non avevano una scadenza. Di conseguenza, i client che si basano su questi token devono aggiornarli entro un'ora. Per evitare che Kubernetes APIil server respinga la tua richiesta a causa di un token non valido, la SDK versione del client Kubernetes utilizzata dal tuo carico di lavoro deve essere la stessa o successiva alle seguenti versioni:

Puoi identificare tutti gli esistenti Pods nel tuo cluster che utilizzano token obsoleti. Per ulteriori informazioni, consulta Token dell'account di servizio.

EKSLa versione della piattaforma Amazon è inferiore a più di due versioni rispetto alla versione attuale della piattaforma

Ciò può accadere quando Amazon EKS non è in grado di aggiornare automaticamente la versione della Visualizza le versioni EKS della piattaforma Amazon per ogni versione di Kubernetes piattaforma del cluster. Sebbene ci siano molte cause, di seguito riportiamo quelle più comuni. Se uno di questi problemi riguarda il tuo cluster, potrebbe continuare a funzionare, ma la sua versione della piattaforma semplicemente non verrà aggiornata da AmazonEKS.

Problema

Il IAM ruolo del EKSIAMRuolo del cluster Amazon 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 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 IAM ruolo EKSIAMRuolo del cluster Amazon 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 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 la sottorete IDs esiste 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"
]

Se la IDs sottorete restituita nell'output non corrisponde alla sottorete specificata al momento della creazione del cluster, se desideri IDs 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 seleziona EKS casualmente le sottoreti che hai specificato per 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 che hai specificato al momento della creazione del cluster in cui Amazon EKS sceglie di creare una nuova interfaccia di rete.

Quando avvii un Kubernetes l'aggiornamento della versione 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 hai specificato i gruppi di sicurezza durante la creazione del cluster, puoi visualizzarli IDs con il seguente comando. Sostituisci my-cluster con il nome del 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, significa che non è stato specificato alcun gruppo di sicurezza al momento della creazione del cluster e il problema non è un gruppo di sicurezza mancante. 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 il gruppo di sicurezza IDs restituito nell'output non corrisponde al gruppo di sicurezza specificato al momento della creazione del cluster, se desideri IDs che Amazon EKS aggiorni il cluster, devi modificare i gruppi di sicurezza utilizzati dal cluster. Amazon EKS non aggiornerà un cluster se il gruppo di sicurezza IDs specificato al momento della creazione del cluster non esiste.

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

Integrità del cluster FAQs e codici di errore con percorsi di risoluzione

Amazon EKS rileva problemi con EKS i cluster e l'infrastruttura del cluster e li archivia nello stato 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, potrebbe essere impossibile eseguire l'aggiornamento a versioni più recenti di Kubernetes o per consentire EKS ad Amazon di installare aggiornamenti di sicurezza su un cluster danneggiato a causa di problemi con l'infrastruttura o la configurazione del cluster necessarie. Amazon EKS può impiegare 3 ore per rilevare problemi o rilevare che un problema è stato risolto.

Lo stato di salute di un EKS cluster Amazon è una responsabilità condivisa tra Amazon EKS e i suoi utenti. Sei responsabile dell'infrastruttura prerequisita dei IAM ruoli e delle VPC sottoreti Amazon, nonché di altre infrastrutture necessarie, che devono essere fornite in anticipo. Amazon EKS rileva i cambiamenti nella configurazione di questa infrastruttura e del cluster.

Per accedere allo stato del cluster nella EKS console Amazon, cerca una sezione chiamata Health Issues nella scheda Panoramica della pagina dei dettagli del EKS cluster Amazon. Questi dati saranno disponibili anche richiamando l'DescribeClusterazione EKSAPI, ad esempio dall'interno dell'interfaccia a riga di AWS comando.

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

📝 Modifica questa pagina su GitHub