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

Lösung

In der Regel schlagen Kubectl-Befehle in Ihrem Amazon-EKS-Cluster fehl, weil der API-Server nicht mit dem Kubelet kommuniziert, das auf Workerknoten ausgeführt wird. Zu den gebräuchlichen Kubectl-Befehlen gehören Kubectl-Exec, Kubectl-Protokolle, Kubectl-Anhänge oder Kubectl-Port-Forward.

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

• Pods werden im sekundären Classless-Inter-Domain-Routing-Bereich (CIDR) 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-Rolle (IAM) 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-Domain-Routing-Bereich (CIDR) ausgeführt.

Unmittelbar nach der Erstellung eines Clusters kann Amazon EKS nicht mit Knoten kommunizieren, die in Subnetzen von CIDR-Blöcken gestartet wurden, die 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 Amazon-EKS-VPC- und Subnetzanforderungen und Überlegungen.

Wenn die Pods im sekundären CIDR-Bereich laufen, dann ergreifen Sie die folgenden Maßnahmen:

• 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

Wenn er auf Worker-Knoten läuft, muss ein API-Server über die erforderlichen Mindestregeln für eingehende und ausgehende Anrufe verfügen, um einen API-Aufruf an Kublet zu tätigen. Um zu überprüfen, ob die Sicherheitsgruppen der Steuerebene und des Knotens über die mindestens erforderlichen Regeln für eingehende und ausgehende Daten verfügen, lesen Sie Anforderungen und Überlegungen zu Amazon-EKS-Sicherheitsgruppen.

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 auf die **aws-auth-**ConfigMap anwenden. Stellen Sie sicher, dass die IAM-Rolle den Kubernetes-Benutzernamen hat, der Ihrem Knoten zugeordnet ist. Informationen zum Anwenden der **aws-auth-**ConfigMap auf Ihren Cluster finden Sie unter Hinzufügen von IAM-Benutzern oder -Rollen zu Ihrem Amazon-EKS-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 wie die folgende aus:

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 dann 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 das folgende 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 wie die folgende aus:

apiVersion: rbac.authorization.k8s.io/v1
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: "2021-11-09T10:07:42Z"
  labels:
    eks.amazonaws.com/component: node
  name: eks:node-bootstrapper
  resourceVersion: "199"
  uid: da268bf3-31a3-420a-9a71-414229437b7e
rules:
- apiGroups:
  - certificates.k8s.io
  resources:
  - certificatesigningrequests/selfnodeserver
  verbs:
  - create

Zu den erforderlichen RBAC-Berechtigungen gehören die folgenden Attribute:

- 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 wie die folgende aus:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"labels":{"eks.amazonaws.com/component":"node"},"name":"eks:node-bootstrapper"},"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"}]}
  creationTimestamp: "2021-11-09T10:07:42Z"
  labels:
    eks.amazonaws.com/component: node
  name: eks:node-bootstrapper
  resourceVersion: "198"
  uid: f6214fe0-8258-4571-a7b9-ff3455add7b9
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

---