Warum kann ich kubectl-Befehle in Amazon EKS nicht ausführen?

Kurzbeschreibung

Wenn du versuchst, kubectl-Befehle auszuführen, treten möglicherweise die folgenden Probleme auf:

• Du kannst kubectl exec, kubectl logs, kubectl attach oder kubectl port-forward nicht ausführen.
• kubectl kann die Steuerebene nicht erreichen.
• Du kannst kubectl nicht installieren.
• Es treten Autorisierungsfehler auf.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Du kannst „kubectl exec“, „kubectl logs“, „kubectl attach“ oder „kubectl port-forward“ nicht ausführen

Um die Befehle kubectl exec, kubectl logs, kubectl attach oder kubectl port-forward auszuführen, muss die Amazon EKS-API eine vertrauenswürdige Verbindung mit dem Kubelet herstellen. Wenn die Authentifizierung fehlschlägt, erhältst du eine Fehlermeldung, die dem folgenden Beispiel ähnelt:

„Error from server: error dialing backend: remote error: tls: internal error“

Auf Konnektivitätsprobleme prüfen

Stelle sicher, dass der API-Server mit dem Worker-Knoten auf Port 1025 kommunizieren kann. Die Worker-Knoten-Sicherheitsgruppe muss eingehenden Datenverkehr von der Cluster-Sicherheitsgruppe auf Port 10250 zulassen. Die Cluster-Sicherheitsgruppe muss eingehenden Datenverkehr von der Worker-Knoten-Sicherheitsgruppe auf Port 443 zulassen. Stelle sicher, dass die Sicherheitsgruppen die Amazon EKS-Anforderungen erfüllen.

Auf CSR-Probleme prüfen

Wenn die Systemsteuerung die vom Kubelet übermittelte Zertifikatssignierungsanforderung (Certificate Signing Request, CSR) nicht genehmigt, kann das Kubelet nicht ausgeführt werden.

Führe den folgenden Befehl aus, um die CSR mit Problemen zu identifizieren:

kubectl get certificatesigningrequest

Führe den folgenden Befehl aus, um den Status der CSR-Anforderung zu überprüfen:

kubectl describe certificatesigningrequest csr-name -n namespace

Hinweis: Ersetze csr-name durch den CSR-Namen und namespace durch den Namespace-Namen.

Suche in der Ausgabe nach CSRs mit dem Status Ausstehend oder Approved (Genehmigt) statt mit dem Status Approved, Issued (Genehmigt, Ausgestellt).

Du musst die Flags RotateKubeletServerCertificate und ServerTLSBootstrap im Kubelet aktivieren, damit das Kubelet das Bereitstellungszertifikat für sich selbst absendet und rotiert. Um zu überprüfen, ob die Flags in der JSON-Datei kubelet-config auf true (wahr) gesetzt sind, führe den folgenden Befehl im Worker-Knoten aus:

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

Beispielausgabe:

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

Damit das Kubelet die CSR erstellen und absenden kann, musst du die Rolle eks:node-bootstrapper an die Gruppen system:bootstrappers und system:nodes anfügen. Führe die folgenden Befehle aus, um zu überprüfen, ob ClusterRole und ClusterRoleBinding die Rolle eks:node:boostrapper haben:

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

Beispielausgabe:

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

Wenn die Rolle eks:node-bootstrapper fehlt, erstelle eine YAML-Datei mit der folgenden Konfiguration:

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

Führe dann den folgenden Befehl aus, um den Amazon EKS-Cluster zu aktualisieren:

 kubectl apply -f file-name command

Hinweis: Ersetze file-name durch deinen YAML-Dateinamen.

Wenn du die ConfigMap-Authentifizierungsmethode verwendest, musst du auch die instance-role, die du in der aws-auth-Datei aws-auth konfiguriert hast, an die Gruppen system:bootstrappers und system:nodes anfügen. Füge aws-auth die instance-role im folgenden Format hinzu:

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}}

Hinweis: Wenn du die Amazon EKS-API als Cluster-Authentifizierungsmodus konfiguriert hast, überprüfe deine Konfiguration. Stelle sicher, dass die AWS Identity and Access Management (IAM, Integritäts- und Zugriffsmanagement)-Rolle des Worker-Knotens dem Benutzernamen system:node:{{EC2PrivateDNSName}} zugeordnet ist. Diese Konfiguration stellt sicher, dass Amazon EKS den CSR-Anforderer erkennt und die CSR automatisch genehmigt. Amazon EKS genehmigt CSRs nur automatisch vom system:node:{{EC2PrivateDNSName}}.

Führe den folgenden Befehl aus, um die Details des Anforderers zu überprüfen:

kubectl describe csr csr-name

Hinweis: Ersetze csr-name durch deinen CSR-Namen.

Beispielausgabe:

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>

Stelle sicher, dass der CSR-Anforderer das Format system:node:ip-abc-xx-x-xabc.ec2.internal hat. Wenn du dieselbe IAM-Rolle verwendest, mit der der Cluster für Worker-Knoten erstellt wurde, lautet der Anforderer möglicherweise kubernetes-admin statt system:node:EC2PrivateDNSName. Amazon EKS lehnt Anforderungen ab, die nicht von system:node:EC2PrivateDNSName stammen. Wenn du die Worker-Knotenrolle einem benutzerdefinierten Benutzernamen in aws-auth zugeordnet hast, stelle sicher, dass du die Worker-Knotenrolle korrekt system:node:EC2PrivateDNSName zugeordnet hast.

Überprüfen der Kubelet-Protokolle

Führe den folgenden Befehl aus, um den Status des Kubelets zu überprüfen:

systemctl status kubelet

Wenn die Ausgabe zeigt, dass der Kubelet-Status Stopped (Gestoppt) lautet, führe den folgenden Befehl aus, um das Kubelet neu zu starten:

sudo systemctl restart kubelet

Führe den folgenden Befehl aus, um die Kubelet-Protokolle auf das Schlüsselwort cert zu überprüfen:

 journalctl -u kubelet | grep cert

Beispielfehler:

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

Wenn in der Befehlsausgabe keine cert-Fehler angezeigt werden, kannst du eine neue CSR absenden. Verwende für detailliertere Protokolle das Flag --v=4. Verwende das log-collector-script auf der GitHub-Website, um Worker-Knotenprotokolle für eine detaillierte Analyse zu sammeln.

Überprüfen der Protokolle der Steuerebene

Voraussetzung: Erlaube dem Amazon EKS-Cluster, Protokolle der Steuerebene an Amazon CloudWatch Logs Insights zu senden.

Führe für weitere Einblicke in CSR-Probleme den folgenden Befehl aus, um mit CloudWatch Logs Insights die Protokolle der Steuerebene zu überprüfen:

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

Hinweis: Ersetze csr-name durch den Namen der CSR, bei der Probleme auftreten.

Kubectl kann die Steuerebene nicht erreichen

Überprüfen des Zugriffs auf den Amazon EKS-Endpunkt

Wenn du den privaten Zugriff für den Kubernetes-API-Serverendpunkt des Clusters aktiviert hast, kannst du nur aus den folgenden Quellen auf den API-Server zugreifen:

• Aus deinem virtuellen privaten Netzwerk (VPN)
• Aus einem verbundenen Netzwerk

Wenn du kubectl von einem Client aus ausführst, der nicht Teil der VPC oder in einem verbundenen Netzwerk ist, kannst du den API-Server des Clusters nicht erreichen. Du erhältst eine Fehlermeldung, die der folgenden ähnelt:

„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“

Um dieses Problem zu beheben, ändere den Cluster-Endpunktzugriff auf Öffentlicher Zugriff. Wenn du einen privaten Cluster benötigst, erstelle einen Amazon Elastic Compute Cloud (Amazon EC2)-Bastion-Host in der VPC des Clusters. Verwende dann den Bastion-Host, um auf den Cluster zuzugreifen. Du musst die Sicherheitsgruppe des Bastion-Hosts zur Sicherheitsgruppe des Clusters hinzufügen.

Überprüfen deiner Host- und Port-Konfigurationen

Wenn du die Fehlermeldung The connection to the server localhost:8080 was refused erhältst, überprüfe deine Host- und Port-Konfigurationen. Der Fehler tritt normalerweise auf, wenn kubectl die richtigen Port- und Host-Informationen des Amazon EKS-API-Serverendpunkts in der kubeconfig-Datei nicht finden kann.

Gehe wie folgt vor, um dieses Problem zu beheben:

1. Führe den folgenden AWS-CLI-Befehl update-kubeconfig aus, um die kubeconfig-Datei zu aktualisieren:

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

   Hinweis: Ersetze region-code durch deine AWS-Region und my-cluster durch deinen Cluster-Namen.

2. Führe den folgenden Befehl aus, um deinen aktuellen Kontext anzuzeigen:

   kubectl config current-context

3. Führe den folgenden Befehl get-caller-identity aus, um den IAM-Benutzer oder die IAM-Rolle zu überprüfen, den/die du in deiner Umgebung konfiguriert hast:

   aws sts get-caller-identity

Informationen zur Behebung von IAM-Problemen findest du unter Wie gewähre ich anderen IAM-Benutzern und -Rollen Zugriff auf einen Cluster, nachdem ich einen Cluster in Amazon EKS erstellt habe?

Überprüfen der Regeln für Sicherheitsgruppen der Steuerebene und des Worker-Knotens

Wenn deine Regeln für die Steuerebene und die Knoten-Sicherheitsgruppe den Zugriff auf den API-Server blockieren, erhältst du die folgende Fehlermeldung:

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

Um dieses Problem zu lösen, stelle sicher, dass die Sicherheitsgruppen der Steuerebene und der Knoten über die erforderlichen Regeln für eingehenden und ausgehenden Datenverkehr verfügen. Die API-Server-Sicherheitsgruppe muss Zugriff auf eingehende Daten vom API-Serverclient auf Port 443 zulassen.

Du kannst kubectl nicht installieren

Du musst eine kubectl-Version verwenden, die sich innerhalb eines geringfügigen Versionsunterschieds deines Clusters befindet. Ein v1.31-Client kann beispielsweise mit den Steuerebenenversionen v1.30, v1.31 und v1.32 kommunizieren. Installiere die neueste kompatible Version von kubectl, um Probleme zu vermeiden.

Wenn du kubectl installierst, wird möglicherweise eine der folgenden Fehlermeldungen angezeigt:

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

-oder-

„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"“

Die oben genannten Fehler treten normalerweise auf, wenn du eine frühere Version der AWS-CLI verwendest, um den Befehl update-kubeconfig auszuführen. Um dieses Problem zu beheben, befolge AWS CLI aktualisieren. Weitere Informationen findest du unter Deprecate Kubernetes client API version v1alpha1 (Veraltete Kubernetes-Client-API-Version v1alpha1) auf der GitHub-Website.

Beim Ausführen von kubectl-Befehlen treten Autorisierungsfehler auf

Beim Ausführen von kubectl-Befehlen kann der folgende Fehler auftreten:

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

Informationen zur Behebung dieses Problems findest du unter Wie behebe ich den Fehler „You must be logged in to the server (Unauthorized)“, wenn ich eine Verbindung zum Amazon EKS-API-Server herstelle?