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

Risoluzione

In genere, i comandi kubectl non riescono nel cluster Amazon EKS perché il server API non comunica con il kubelet in esecuzione sui nodi worker. I comandi kubectl più comuni includono kubectl exec, kubectl logs, kubectl attach o kubectl port-forward.

Per risolvere il problema, verifica quanto segue:

• I pod devono essere in esecuzione nell'intervallo di instradamento interdominio senza classi (CIDR) secondario.
• I gruppi di sicurezza utilizzati per il piano di controllo e il nodo devono utilizzare le best practice per le regole in entrata e in uscita.
• Il ConfigMap aws-auth deve avere il ruolo AWS Identity and Access Management (IAM) corretto con il nome utente Kubernetes associato al nodo.
• Il requisito di presentare un nuovo certificato è soddisfatto.

I pod sono in esecuzione nell'intervallo di instradamento interdominio senza classi (CIDR) secondario

Subito dopo la creazione di un cluster, Amazon EKS non è in grado di comunicare con i nodi lanciati in sottoreti da blocchi CIDR aggiuntivi aggiunti a un cloud privato virtuale (VPC). Un intervallo aggiornato causato dall'aggiunta di blocchi CIDR a un cluster esistente potrebbe richiedere fino a cinque ore per essere riconosciuto da Amazon EKS. Per ulteriori informazioni, consulta Requisiti e considerazioni su VPC e sottoreti di Amazon EKS.

Se i pod sono in esecuzione nell'intervallo CIDR secondario, completa le seguenti operazioni:

• Affinché questi comandi inizino a funzionare è necessario attendere fino a cinque ore.
• Assicurati di avere almeno cinque indirizzi IP liberi in ogni sottorete per completare correttamente l'automazione.

Utilizzare la seguente policy di esempio per visualizzare gli indirizzi IP gratuiti per tutte le sottoreti in qualsiasi VPC:

[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"

I gruppi di sicurezza utilizzati per il piano di controllo e il nodo hanno le regole minime richieste in entrata e in uscita

Affinché un server API effettui una chiamata API a kubelet durante l'esecuzione sui nodi worker, deve avere le regole minime richieste in entrata e in uscita. Per verificare che il piano di controllo e i gruppi di sicurezza del nodo abbiano le regole minime richieste in entrata e in uscita, consulta Requisiti e considerazioni sui gruppi di sicurezza Amazon EKS.

Il ConfigMap aws-auth ha il ruolo IAM corretto con il nome utente Kubernetes associato al nodo

È necessario applicare il ruolo IAM corretto al ConfigMap aws-auth. Assicurati che il ruolo IAM abbia il nome utente Kubernetes associato al tuo nodo. Per applicare il ConfigMap aws-auth al tuo cluster, consulta Aggiunta di utenti o ruoli IAM al cluster Amazon EKS.

Il requisito di presentare un nuovo certificato è soddisfatto

I cluster Amazon EKS richiedono che il kubelet del nodo invii e ruoti il certificato di servizio. Quando un certificato di servizio non è disponibile viene restituito un errore di certificazione.

1.    Esegui il comando riportato per convalidare il certificato del server kubelet:

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

Dovresti visualizzare un output simile al seguente:

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.    Esamina i log kubelet per gli errori di certificazione. Se non viene visualizzato alcun errore, allora il requisito per l'invio di nuovi certificati è soddisfatto.

Esempio di errore di certificazione del log kubelet:

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

Nota: per log più dettagliati, attiva i log dettagliati di kubelet con il flag --v=4, quindi riavvia il kubelet sul nodo worker. Il log dettagliato di kubelet ha un aspetto simile al seguente:

#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.    Se viene visualizzato un errore, verifica il file di configurazione kubelet: /etc/kubernetes/kubelet/kubelet-config.json sul nodo worker, quindi conferma che i flag RotateKubeletServerCertificate e serverTLSBootstrap siano riportati come true:

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

4.    Esegui il comando eks:node-bootstrapper per confermare che il kubelet dispone delle autorizzazioni di sistema RBAC (Role-Based Access Control) necessarie per inviare la richiesta di firma del certificato (CSR):

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

Dovresti visualizzare un output simile al seguente:

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

Le autorizzazioni RBAC richieste includono i seguenti attributi:

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

5.    Esegui il comando riportato per verificare se il ruolo del cluster eks:node-bootstrapper è associato a system:bootstrappers e system:nodes. Ciò consente al kubelet di inviare e ruotare il certificato di servizio da solo.

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

Dovresti visualizzare un output simile al seguente:

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

---