Perché non riesco a eseguire comandi kubectl in Amazon EKS?

Breve descrizione

Quando provi a eseguire comandi kubectl, potresti riscontrare i seguenti errori:

• Non riesci a eseguire kubectl exec, kubectl logs, kubectl attach o kubectl port-forward.
• kubectl non riesce a raggiungere il piano di controllo (control-plane).
• Non riesci a installare kubectl.
• Riscontri errori di autorizzazione.

Risoluzione

Nota: se ricevi errori quando esegui i comandi dell'Interfaccia della linea di comando AWS (AWS CLI), consulta Risoluzione degli errori per AWS CLI. Inoltre, assicurati di utilizzare la versione più recente di AWS CLI.

Non riesci a eseguire kubectl exec, kubectl logs, kubectl attach o kubectl port-forward

Per eseguire i comandi kubectl exec, kubectl logs, kubectl attach o kubectl port-forward, l'API Amazon EKS deve stabilire una connessione affidabile con kubelet. Se l'autenticazione non riesce, viene visualizzato un errore simile al seguente esempio:

"Error from server: error dialing backend: remote error: tls: internal error"

Verifica la presenza di problemi di connettività di rete

Assicurati che il server API possa comunicare con il nodo worker sulla porta 1025. Il gruppo di sicurezza del nodo worker deve consentire il traffico in entrata dal gruppo di sicurezza del cluster sulla porta 10250. Il gruppo di sicurezza del cluster deve consentire il traffico in entrata dal gruppo di sicurezza del nodo worker sulla porta 443. Assicurati che i gruppi di sicurezza rispettino i requisiti di Amazon EKS.

Verifica eventuali problemi relativi alla CSR

Se il pannello di controllo non approva la richiesta di firma del certificato (CSR) inviata da kubelet, kubelet non può essere eseguito.

Per identificare la CSR che crea problemi, esegui questo comando:

kubectl get certificatesigningrequest

Per verificare lo stato della CSR, esegui questo comando:

kubectl describe certificatesigningrequest csr-name -n namespace

Nota: sostituisci csr-name con il nome della CSR e namespace con il nome del namespace.

Nell'output verifica se sono presenti CSR nello stato Pending (In sospeso) o Approved (Approvata) anziché nello stato Approved, Issued (Approvata, Emessa).

Devi attivare i flag RotateKubeletServerCertificate e ServerTLSBootstrap in kubelet in modo che kubelet invii e ruoti automaticamente il certificato di distribuzione. Per verificare se i flag nel file JSON kubelet-config sono impostati su true, esegui questo comando dall'interno del nodo worker:

cat /etc/kubernetes/kubelet/kubelet-config.json

Esempio di output:

"serverTLSBootstrap": true
"featureGates": {
    "RotateKubeletServerCertificate": true
    }

Affinché kubelet crei e invii la CSR, devi collegare il ruolo eks:node-bootstrapper ai gruppi system:bootstrappers e system:nodes. Per verificare se ClusterRole e ClusterRoleBinding hanno il ruolo eks:node:boostrapper, esegui questi comandi:

kubectl describe clusterrole eks:node-bootstrapper
kubectl describe clusterrolebinding eks:node-bootstrapper

Esempio di output:

kubectl describe clusterrole eks:node-bootstrapper
 Name: eks:node-bootstrapper
 Labels: eks.amazonaws.com/component=node
 Annotations: <none>
 PolicyRule:
 Resources Non-Resource URLs Resource Names Verbs
 --------- ----------------- -------------- -----
 certificatesigningrequests.certificates.k8s.io/selfnodeserver [] [] [create]

$ kubectl describe clusterrolebinding eks:node-bootstrapper
 Name: eks:node-bootstrapper
 Labels: eks.amazonaws.com/component=node
 Annotations: <none>
 Role:
 Kind: ClusterRole
 Name: eks:node-bootstrapper
 Subjects:
 Kind Name Namespace
 ---- ---- ---------
 Group system:bootstrappers
 Group system:nodes

Se il ruolo eks:node-bootstrapper manca, crea un file YAML con la seguente configurazione:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-bootstrapper
  labels:
    eks.amazonaws.com/component: node
rules:
  - apiGroups: ["certificates.k8s.io"]
    resources: ["certificatesigningrequests/selfnodeserver"]
    verbs: ["create"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-bootstrapper
  labels:
    eks.amazonaws.com/component: node
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-bootstrapper
subjects:
  - kind: Group
    name: system:bootstrappers
  - kind: Group
    name: system:nodes

Quindi esegui questo comando per aggiornare il cluster Amazon EKS:

 kubectl apply -f file-name command

Nota: sostituisci file-name con il nome del tuo file YAML.

Se utilizzi il metodo di autenticazione ConfigMap, devi anche collegare l'instance-role che hai configurato nel file aws-auth ai gruppi system:bootstrappers e system:nodes. Aggiungi instance-role a aws-auth nel seguente formato:

kubectl get cm aws-auth -n kube-system -o yaml
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::12345678912:role/kubectl-cluster-nodegroup-custo-NodeInstanceRole-1KFZHWE6FCBDS
      username: system:node:{{EC2PrivateDNSName}}

Nota: se hai configurato l'API Amazon EKS come modalità di autenticazione del cluster, controlla la configurazione. Assicurati che il ruolo del nodo worker AWS Identity and Access Management (AWS IAM) sia mappato sul nome utente system:node:{{EC2PrivateDNSName}}. Questa configurazione assicura che Amazon EKS riconosca il richiedente della CSR e la approvi automaticamente. Amazon EKS approva automaticamente solo le CSR provenienti da system:node:{{EC2PrivateDNSName}}.

Per controllare i dettagli del richiedente, esegui questo comando:

kubectl describe csr csr-name

Nota: sostituisci csr-name con il nome della tua CSR.

Esempio di output:

Name:               csr-tpb4m
Labels:             <none>
Annotations:        <none>
CreationTimestamp:  Tue, 12 Dec 2023 11:18:30 +0530
Requesting User:    system:node:ip-000-00-00-000.ec2.internal
Signer:             kubernetes.io/kubelet-serving
Status:             Approved,Issued
Subject:
  Common Name:    system:node:ip-172-31-73-240.ec2.internal
  Serial Number:  
  Organization:   system:nodes
Subject Alternative Names:
         DNS Names:     ip-172-31-73-240.ec2.internal
         IP Addresses:  172.31.73.240
Events:  <none>

Assicurati che il richiedente della CSR sia nel formato system:node:ip-abc-xx-x-xabc.ec2.internal. Se utilizzi lo stesso ruolo IAM che ha creato il cluster per i nodi worker, il richiedente potrebbe essere kubernetes-admin anziché system:node:EC2PrivateDNSName. Amazon EKS rifiuta le richieste che non provengono da system:node:EC2PrivateDNSName. Se hai mappato il ruolo del nodo worker su un nome utente personalizzato in aws-auth, assicurati di aver mappato correttamente il ruolo del nodo worker su system:node:EC2PrivateDNSName.

Controlla i log kubelet

Per verificare lo stato di kubelet, esegui questo comando:

systemctl status kubelet

Se l'output mostra che lo stato di kubelet è Stopped (Arrestato), esegui questo comando per riavviarlo:

sudo systemctl restart kubelet

Per controllare la presenza della parola chiave cert nei log kubelet, esegui il questo comando:

 journalctl -u kubelet | grep cert

Esempio di errore:

kubelet[8070]: I1021 18:49:21.594143 8070 log.go:184] http: TLS handshake error from 192.168.130.116:38710: no serving certificate available for the kubelet

Se non vedi errori cert nell'output del comando, puoi inviare una nuova CSR. Per log più dettagliati, usa il flag --v=4. Per raccogliere i log dei nodi worker per un'analisi dettagliata, utilizza il log-collector-script sul sito web GitHub.

Controlla i log del piano di controllo (control-plane)

Prerequisito: consenti al cluster Amazon EKS di inviare i log del piano di controllo (control-plane) ad Approfondimenti di Amazon CloudWatch Logs.

Per ulteriori informazioni sui problemi delle CSR, esegui questo comando per controllare i log del piano di controllo (control-plane) utilizzando Approfondimenti di CloudWatch Logs:

fields @timestamp, @message, @logStream, @log
| filter message like 'csr-name'
| sort @timestamp desc
| limit 10000

Nota: sostituisci csr-name con il nome della CSR che presenta problemi.

Kubectl non riesce a raggiungere il piano di controllo (control-plane)

Verifica l'accesso all'endpoint Amazon EKS

Se hai attivato l'accesso privato per l'endpoint del server API Kubernetes del cluster, puoi accedere al server API solo dalle seguenti origini:

• Rete privata virtuale (VPN)
• Rete connessa

Se esegui kubectl da un client che non fa parte del VPC o che non è in una rete connessa, non puoi raggiungere il server API del cluster. Ricevi un errore simile al seguente:

"E1009 12:33:44.852680 106 memcache.go:265] couldn't get current server API group list: Get "APISERVERENDPOINT": dial tcp 11.11.111.111:443: i/o timeout"

Per risolvere il problema, modifica l'accesso all'endpoint del cluster in Accesso pubblico. Se devi avere un cluster privato, crea un host bastione Amazon Elastic Compute Cloud (Amazon EC2) nel VPC del cluster. Quindi usa l'host bastione per accedere al cluster. Devi aggiungere il gruppo di sicurezza dell'host bastione al gruppo di sicurezza del cluster.

Controlla le configurazioni dell'host e delle porte

Se ricevi il messaggio di errore The connection to the server localhost:8080 was refused, controlla le configurazioni dell'host e delle porte. Generalmente l'errore si verifica quando kubectl non riesce a trovare le informazioni corrette sulla porta e sull'host dell'endpoint del server API Amazon EKS nel file kubeconfig.

Per risolvere il problema, completa i seguenti passaggi:

1. Per aggiornare il file kubeconfig, esegui questo comando AWS CLI update-kubeconfig:

   aws eks update-kubeconfig --region region-code --name my-cluster

   Nota: sostituisci region-code con la tua Regione AWS e my-cluster con il nome del tuo cluster.

2. Per visualizzare il contesto corrente, esegui questo comando:

   kubectl config current-context

3. Per verificare l'utente o il ruolo IAM che hai configurato nel tuo ambiente, esegui questo comando get-caller-identity:

   aws sts get-caller-identity

Per risolvere i problemi relativi a IAM, consulta Come posso fornire l'accesso al cluster ad altri utenti e ruoli IAM dopo aver creato un cluster in Amazon EKS?

Controlla le regole dei gruppi di sicurezza del piano di controllo (control-plane) e del nodo worker

Se le regole dei gruppi di sicurezza del piano di controllo (control-plane) e del nodo bloccano l'accesso al server API, ricevi il seguente errore:

"The connection to the server APISERVERENDPOINT was refused - did you specify the right host or port?"

Per risolvere il problema, assicurati che i gruppi di sicurezza del piano di controllo (control-plane) e del nodo dispongano delle regole in entrata e in uscita richieste. Il gruppo di sicurezza del server API deve consentire l'accesso in entrata dal client del server API sulla porta 443.

Non riesci a installare kubectl

Devi utilizzare una versione di kubectl che non abbia più di una versione secondaria di differenza rispetto a quella del cluster. Ad esempio, un client v1.31 può comunicare con le versioni del piano di controllo (control-plane) v1.30, v1.31 e v1.32. Per evitare problemi, installa l'ultima versione compatibile di kubectl.

Quando installi kubectl, potresti ricevere uno dei seguenti errori:

"error: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1"

-oppure-

"Unable to connect to the server: getting credentials: decoding stdout: no kind "ExecCredential" is registered for version "client.authentication.k8s.io/v1alpha1" in scheme "pkg/client/auth/exec/exec.go:62""

Generalmente gli errori precedenti si verificano quando utilizzi una versione precedente di AWS CLI per eseguire il comando update-kubeconfig. Per risolvere il problema, segui le istruzioni riportate in Installazione o aggiornamento alla versione più recente di AWS CLI. Per ulteriori informazioni, consulta Deprecate Kubernetes client API version v1alpha1 (Deprecata l’API client Kubernetes versione v1alpha1) sul sito web GitHub.

Riscontri errori di autorizzazione quando esegui comandi kubectl

Quando esegui comandi kubectl, potresti riscontrare il seguente errore:

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

Per risolvere il problema, consulta Come faccio a risolvere l'errore "È necessario accedere al server (non autorizzato)" quando mi connetto al server API Amazon EKS?