Pourquoi ne puis-je pas exécuter de commandes kubectl dans Amazon EKS ?

Résolution

Il est possible que les commandes kubectl échouent dans votre cluster Amazon EKS car le serveur d'API ne communique pas avec le kubelet qui s'exécute sur les composants master. Les commandes kubectl courantes incluent kubectl exec, kubectl logs, kubectl attach ou kubectl port-forward.

Afin de résoudre ce problème, vérifiez les éléments suivants :

• Les pods s'exécutent dans une plage de routage inter-domaines sans classe (CIDR) secondaire.
• Les groupes de sécurité utilisés pour le plan de contrôle et le nœud appliquent les pratiques recommandées pour les règles entrantes et sortantes.
• L'aws-auth ConfigMap possède le rôle Gestion des identités et des accès AWS (AWS IAM) correct avec le nom d'utilisateur Kubernetes associé à votre nœud.
• L'obligation de soumettre un nouveau certificat est remplie.

Les pods s'exécutent dans une plage de routage inter-domaines sans classe (CIDR) secondaire

Immédiatement après la création d'un cluster, Amazon EKS se trouve dans l'incapacité de communiquer avec les nœuds lancés dans les sous-réseaux à partir de blocs CIDR ajoutés à un cloud privé virtuel (VPC). En effet, une plage mise à jour provoquée par l'ajout de blocs CIDR à un cluster existant peut prendre jusqu'à cinq heures avant d'être reconnue par Amazon EKS. Afin d'obtenir davantage d'informations, veuillez consulter la section Exigences et considérations relatives aux sous-réseaux et VPC Amazon EKS.

Si les pods s'exécutent dans une plage CIDR secondaire, procédez comme suit :

• Patientez jusqu'à cinq heures afin que ces commandes prennent effet.
• Assurez-vous que vous disposez d'au moins cinq adresses IP libres dans chaque sous-réseau pour réussir l'automatisation.

Utilisez l'exemple de politique suivant pour afficher les adresses IP libres pour tous les sous-réseaux d'un 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"

Les groupes de sécurité utilisés pour le plan de contrôle et le nœud disposent des règles entrantes et sortantes minimales requises

Lorsqu'il est exécuté sur des composants master, un serveur d'API doit disposer du minimum de règles entrantes et sortantes requises pour effectuer un appel d'API à kublet. Pour vérifier que le plan de contrôle et les groupes de sécurité des nœuds disposent des règles entrantes et sortantes minimales requises, veuillez consulter la section Considérations et exigences relatives aux groupes de sécurité Amazon EKS.

L'aws-auth ConfigMap possède le rôle IAM correct avec le nom d'utilisateur Kubernetes associé à votre nœud

Vous devez appliquer le rôle IAM correct à l'aws-auth ConfigMap. Assurez-vous que le rôle IAM possède le nom d'utilisateur Kubernetes associé à votre nœud. Pour appliquer l'aws-auth ConfigMap à votre cluster, veuillez consulter la section Ajout d'utilisateurs ou de rôles IAM à votre cluster Amazon EKS.

L'obligation de soumettre un nouveau certificat est remplie

Les clusters Amazon EKS requièrent le kubelet du nœud pour envoyer et faire pivoter le certificat de service pour lui-même. Une erreur de certificat se produit lorsqu'un certificat de service n'est pas disponible.

1.    Exécutez la commande suivante pour valider le certificat du serveur kubelet :

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

Le résultat est similaire à ce qui suit :

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.    Vérifiez que les journaux kubelet ne contiennent aucune erreur de certificat. Si tel est le cas, l'obligation de soumettre de nouveaux certificats est remplie.

Exemple d'erreur de certificat de journal 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

Remarque : pour des journaux plus détaillés, activez les journaux détaillés kubelet avec l'indicateur --v=4, puis redémarrez le kubelet sur le composant master. Le journal détaillé de kubelet est similaire à ce qui suit :

#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.    Si vous détectez une erreur, vérifiez le fichier de configuration kubelet : /etc/kubernetes/kubelet/kubelet-config.json sur le composant master, puis confirmez que les indicateurs RotateKubeletServerCertificate et serverTLSBootstrap sont répertoriés comme « true » :

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

4.    Exécutez la commande eks:node-bootstrapper suivante afin de confirmer que le kubelet détient les autorisations système de contrôle d'accès basé sur les rôles (RBAC) requises pour soumettre la demande de signature de certificat (CSR) :

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

Le résultat est similaire à ce qui suit :

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

Les autorisations RBAC requises incluent les attributs suivants :

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

5.    Exécutez la commande suivante pour vérifier si le rôle de cluster eks:node-bootstrapper est lié à system:bootstrappers et system:nodes. Cela permet au kubelet de soumettre et effectuer une rotation du certificat de service pour lui-même.

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

Le résultat est similaire à ce qui suit :

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

---