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

Letzte Aktualisierung: 24.11.2021

Ich kann Kubectl-Befehle wie Kubectl-Exec, Kubectl-Protokolle, Kubectl-Anhängen oder Kubectl-Port-Forward in Amazon Elastic Kubernetes Service (Amazon EKS) nicht erfolgreich ausführen.

Lösung

Der häufigste Grund, warum Sie Befehle wie kubectl exec, kubectl logs, kubectl attach oder kubectl port-forward in Ihrem Amazon-EKS-Cluster nicht erfolgreich ausführen können, ist, dass der API-Server nicht richtig mit dem Kubelet kommuniziert, das auf Worker-Knoten läuft.

Um dieses Problem zu beheben, überprüfen Sie Folgendes:

  • Pods werden im sekundären Classless Inter Routing (CIDR)-Bereich ausgeführt.
  • Sicherheitsgruppen, die für die Steuerebene und den Knoten verwendet werden, verwenden die bewährten Methoden für eingehende und ausgehende Regeln.
  • Die aws-auth ConfigMap hat die richtige AWS Identity und Access-Management (IAM)-Rolle mit dem Kubernetz-Benutzernamen, der Ihrem Knoten zugeordnet ist.
  • Die Anforderung zur Einreichung eines neuen Zertifikats ist erfüllt.

Pods werden im sekundären Classless-Inter-Routing (CIDR)-Bereich ausgeführt

Amazon EKS kann nicht mit Knoten kommunizieren, die in Subnetzen von zusätzlichen CIDR-Blöcken gestartet werden, die unmittelbar nach der Erstellung eines Clusters zu einer Virtual Private Cloud (VPC) hinzugefügt wurden. Bei einem aktualisierten Bereich, der durch Hinzufügen von CIDR-Blöcken zu einem vorhandenen Cluster verursacht wird, kann es bis zu fünf Stunden dauern, bis er von Amazon EKS erkannt wird. Weitere Informationen finden Sie unter Überlegungen zu Cluster-VPC.

Wenn die Pods im sekundären CIDR-Bereich laufen, gehen Sie wie folgt vor:

  • Warten Sie bis zu fünf Stunden, bis diese Befehle funktionieren.
  • Stellen Sie sicher, dass Sie mindestens fünf freie IP-Adressen in jedem Subnetz haben, um die Automatisierung erfolgreich abzuschließen.

Verwenden Sie die folgende Beispielrichtlinie, um die freien IP-Adressen für alle Subnetze in einer beliebigen VPC anzuzeigen:

[ec2-user@ip-172-31-51-214 ~]$ aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-078af71a874f2f068" | jq '.Subnets[] | .SubnetId + "=" + "\(.AvailableIpAddressCount)"'
"subnet-0d89886ca3fb30074=8186"
"subnet-0ee46aa228bdc9a74=8187"
"subnet-0a0186a277b8b6a51=8186"
"subnet-0d1fb1de0732b5766=8187"
"subnet-077eff87a4e25316d=8187"
"subnet-0f01c02b04708f638=8186"

Sicherheitsgruppen, die für die Steuerebene und den Knoten verwendet werden, haben die mindestens erforderlichen Regeln für ein- und ausgehenden Datenverkehr

Damit ein API-Server einen API-Aufruf an Kubelet tätigen kann, während er auf Arbeitsknoten ausgeführt wird, muss er über die mindestens erforderlichen eingehenden und ausgehenden Regeln verfügen. Um zu überprüfen, ob die für die Steuerebene und den Knoten verwendeten Sicherheitsgruppen über die mindestens erforderlichen Regeln für ein- und ausgehende Datenverkehr verfügen, lesen Sie Überlegungen zur Amazon-EKS-Sicherheitsgruppe.

Die aws-auth ConfigMap hat die richtige IAM-Rolle mit dem Kubernetes-Benutzernamen, der Ihrem Knoten zugeordnet ist

Sie müssen die richtige IAM-Rolle mit dem Kubernetes-Benutzernamen, der Ihrem Knoten zugeordnet ist, auf die aws-auth ConfigMap angewendet haben. Informationen zum Anwenden der aws-auth ConfigMap auf Ihren Cluster finden Sie unter Verwalten von Benutzern oder IAM-Rollen für Ihren Cluster.

Die Anforderung, ein neues Zertifikat einzureichen, ist erfüllt

Amazon-EKS-Cluster erfordern, dass das Kubelet des Knotens das Serving-Zertifikat für sich selbst einreicht und dreht. Ein Zertifikatfehler tritt auf, wenn kein Serving-Zertifikat verfügbar ist.

1.    Führen Sie den folgenden Befehl aus, um das Kubelet-Server-Zertifikat zu überprüfen:

cd /var/lib/kubelet/pki/# use openssl command to validate kubelet server cert 
sudo openssl x509 -text -noout -in kubelet-server-current.pem

Die Ausgabe sieht ähnlich aus wie die folgende:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1e:f1:84:62:a3:39:32:c7:30:04:b5:cf:b0:91:6e:c7:bd:5d:69:fb
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Oct 11 19:03:00 2021 GMT
            Not After : Oct 11 19:03:00 2022 GMT
        Subject: O=system:nodes, CN=system:node:ip-192-168-65-123.us-east-2.compute.internal
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:7f:44:c6:95:7e:0f:1e:f8:f8:bf:2e:f8:a9:40:
                    6a:4f:83:0a:e8:89:7b:87:cb:d6:b8:47:4e:8d:51:
                    00:f4:ac:9d:ef:10:e4:97:4a:1b:69:6f:2f:86:df:
                    e0:81:24:c6:62:d2:00:b8:c7:60:da:97:db:da:b7:
                    c3:08:20:6e:70
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                A8:EA:CD:1A:5D:AB:DC:47:A0:93:31:59:ED:05:E8:7E:40:6D:ED:8C
            X509v3 Authority Key Identifier:
                keyid:2A:F2:F7:E8:F6:1F:55:D1:74:7D:59:94:B1:45:23:FD:A1:8C:97:9B

            X509v3 Subject Alternative Name:
                DNS:ec2-3-18-214-69.us-east-2.compute.amazonaws.com, DNS:ip-192-168-65-123.us-east-2.compute.internal, IP Address:192.168.65.123, IP Address:3.18.214.69

2.    Überprüfen Sie die Kubelet-Protokolle auf Zertifikationsfehler. Wenn Sie keinen Fehler sehen, ist die Anforderung, neue Zertifikate einzureichen, erfüllt.

Beispiel für einen Kubelet-Protokoll-Zertifikationsfehler:

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

Hinweis: Für detailliertere Protokolle schalten Sie die detaillierten Protokolle von Kubelet mit dem Flag —v=4 ein und starten Sie dann das Kubelet auf dem Worker-Knoten neu. Das detaillierte Kubelet-Protokoll sieht in etwa wie folgt aus:

#kubelet verbosity can be increased by updating this file ...max verbosisty level --v=4
sudo vi /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
# Normal kubelet verbosisty is 2 by default
cat /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
[Service]
Environment='KUBELET_ARGS=--node-ip=192.168.65.123 --pod-infra-container-image=XXXXXXXXXX.dkr.ecr.us-east-2.amazonaws.com/eks/pause:3.1-eksbuild.1 --v=2
#to restart the demon and kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet
#make sure kubelet in running state
sudo systemctl status kubelet
# to stream logs for kubelet
journalctl -u kubelet -f

3.    Wenn Sie einen Fehler sehen, überprüfen Sie die Kubelet-Konfigurationsdatei: /etc/kubernetes/kubelet/kubelet-config.json auf dem Worker-Knoten und vergewissern Sie sich dann, dass die rotateKubeletServerCertificate- und ServerTLSBootstrap-Flags als wahr aufgeführt sind:

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

4.    Führen Sie den folgenden Befehl eks:node-bootstrapper aus, um zu bestätigen, dass das Kubelet über die erforderlichen Systemberechtigungen für die rollenbasierte Zugriffssteuerung (RBAC) verfügt, um die Certificate Signing Request (CSR) einzureichen:

$ kubectl get clusterrole eks:node-bootstrapper -o yaml
apiVersion: rbac.authorization.k8s.io/v1

Die Ausgabe sieht ähnlich aus wie die folgende:

kind: ClusterRole
metadata:
 annotations:
 kubectl.kubernetes.io/last-applied-configuration: |
 {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"labels":{"eks.amazonaws.com/component":"node"},"name":"eks:node-bootstrapper"},"rules":[{"apiGroups":["certificates.k8s.io"],"resources":["certificatesigningrequests/selfnodeserver"],"verbs":["create"]}]}
 creationTimestamp: "2019-11-17T05:01:38Z"
 labels:
 eks.amazonaws.com/component: node
 name: eks:node-bootstrapper
 resourceVersion: "168"
 selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/eks%3Anode-bootstrapper
 uid: 564b6a3a-08f7-11ea-9d07-06e275d1e5e0
rules:
- apiGroups:
 - certificates.k8s.io
resources:
- certificatesigningrequests/selfnodeserver
verbs:
- create

Zu den erforderlichen RBAC-Berechtigungen gehört Folgendes:

- apiGroups: ["certificates.k8s.io"]
resources: ["certificatesigningrequests/selfnodeserver"]
verbs: ["create"]

5.    Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Clusterrolle eks:node-bootstrapper an das System:Bootstrappers und System:nodes gebunden ist. Dadurch kann das Kubelet das Serving-Zertifikat für sich selbst einreichen und drehen.

$ kubectl get clusterrolebinding eks:node-bootstrapper -o yaml
apiVersion: rbac.authorization.k8s.io/v1

Die Ausgabe sieht ähnlich aus wie die folgende:

kind: ClusterRoleBinding
metadata:
 labels:
 eks.amazonaws.com/component: node
 name: eks:node-bootstrapper
 resourceVersion: "167"
 selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/eks%3Anode-bootstrapper
 uid: 564a00de-08f7-11ea-9d07-06e275d1e5e0
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: eks:node-bootstrapper
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: system:bootstrappers
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: system:nodes

War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?