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

Brève description

Lorsque vous essayez d'exécuter des commandes kubectl, vous pouvez rencontrer les problèmes suivants :

• Vous ne pouvez pas exécuter kubectl exec, kubectl logs, kubectl attach ni kubectl port-forward.
• kubectl ne peut pas atteindre le plan de contrôle.
• Vous ne pouvez pas installer kubectl.
• Vous rencontrez des erreurs d'autorisation.

Résolution

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l’AWS CLI.

Vous ne pouvez pas exécuter kubectl exec, kubectl logs, kubectl attach ni kubectl port-forward

Pour exécuter les commandes kubectl exec, kubectl logs, kubectl attach ou kubectl port-forward, l'API Amazon EKS doit établir une connexion sécurisée avec le kubelet. Si l'authentification échoue, un message d'erreur similaire à l'exemple suivant s'affiche :

« Error from server: error dialing backend: remote error: tls: internal error » (Erreur du serveur : erreur lors de la numérotation du backend : erreur distante : tls : erreur interne)

Vérifier les problèmes de connectivité réseau

Assurez-vous que le serveur API peut communiquer avec le composant master sur le port 1025. Le groupe de sécurité de composant master doit autoriser le trafic entrant en provenance du groupe de sécurité de cluster sur le port 10250. Le groupe de sécurité de cluster doit autoriser le trafic entrant en provenance du groupe de sécurité de composant master sur le port 443. Assurez-vous que vos groupes de sécurité respectent les exigences d’Amazon EKS.

Rechercher des problèmes liés à la CSR

Si le panneau de configuration n'approuve pas la demande de signature de certificat (CSR) soumise par le kubelet, celui-ci ne peut pas fonctionner.

Pour identifier la CSR présentant des problèmes, exécutez la commande suivante :

kubectl get certificatesigningrequest

Pour vérifier l'état de la demande de CSR, exécutez la commande suivante :

kubectl describe certificatesigningrequest csr-name -n namespace

Remarque : Remplacez csr-name par le nom de la CSR et namespace par le nom de l'espace de noms.

Dans la sortie, recherchez les CSR à l'état En attente ou Approuvé plutôt qu’à l'état Approuvé, émis.

Vous devez activer les indicateurs RotateKubeletServerCertificate et ServerTLSBootstrap dans le kubelet afin que celui-ci soumette et renouvelle le certificat actif même. Pour vérifier si les indicateurs du fichier JSON kubelet-config sont définis sur vrai, exécutez la commande suivante depuis le composant master :

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

Exemple de sortie :

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

Pour que le kubelet puisse créer et soumettre la CSR, vous devez associer le rôle eks:node-bootstrapper aux groupes system:bootstrappers et system:nodes. Pour vérifier si ClusterRole et ClusterRoleBinding ont le rôle eks:node:boostrapper, exécutez les commandes suivantes :

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

Exemple de sortie :

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

Si le rôle eks:node-bootstrapper est manquant, créez un fichier YAML avec la configuration suivante :

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

Puis, exécutez la commande suivante pour mettre à jour le cluster Amazon EKS :

 kubectl apply -f file-name command

Remarque : Remplacez file-name par le nom de votre fichier YAML.

Si vous utilisez la méthode d'authentification ConfigMap, vous devez également associer le rôle d'instance que vous avez configuré dans le fichier aws-auth aux groupes system:bootstrappers et system:nodes. Ajoutez le rôle d'instance à aws-auth au format suivant :

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

Remarque : Si vous avez configuré l'API Amazon EKS comme mode d'authentification du cluster, vérifiez votre configuration. Assurez-vous que le rôle Gestion des identités et des accès AWS (AWS IAM) du composant master correspond au nom d'utilisateur system:node:{{EC2PrivateDNSName}}. Cette configuration s’assure qu'Amazon EKS reconnaît le demandeur de CSR et approuve automatiquement la CSR. Amazon EKS n’approuve automatiquement que les CSR provenant de system:node:{{EC2PrivateDNSName}}.

Pour vérifier les informations du demandeur, exécutez la commande suivante :

kubectl describe csr csr-name

Remarque : Remplacez csr-name par le nom de votre CSR.

Exemple de sortie :

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>

Assurez-vous que le demandeur de CSR est au format system:node:ip-abc-xx-x-xabc.ec2.internal. Si vous utilisez le même rôle IAM que celui qui a créé le cluster pour les composants master, le demandeur peut être kubernetes-admin au lieu de system:node:EC2PrivateDNSName. Amazon EKS rejette les requêtes qui ne proviennent pas de system:node:EC2PrivateDNSName. Si vous avez mappé le rôle de composant master à un nom d'utilisateur personnalisé dans aws-auth, assurez-vous d'avoir correctement mappé le rôle de composant master à system:node:EC2PrivateDNSName.

Vérifier les journaux de kubelet

Pour vérifier l'état du kubelet, exécutez la commande suivante :

systemctl status kubelet

Si la sortie indique que l'état du kubelet est Arrêté, exécutez la commande suivante pour redémarrer le kubelet :

sudo systemctl restart kubelet

Pour rechercher le mot-clé cert dans les journaux de kubelet, exécutez la commande suivante :

 journalctl -u kubelet | grep cert

Exemple d’erreur :

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

Si aucune erreur cert ne s'affiche dans la sortie de commande, vous pouvez soumettre une nouvelle CSR. Pour des journaux plus détaillés, utilisez l'indicateur --v=4. Pour collecter les journaux du composant master en vue d’une analyse détaillée, utilisez log-collector-script sur le site Web de GitHub.

Consulter les journaux de plan de contrôle

Prérequis : Autorisez le cluster Amazon EKS à envoyer les journaux de plan de contrôle à Amazon CloudWatch Logs Insights.

Pour en savoir plus sur les problèmes de CSR, exécutez la commande suivante pour utiliser CloudWatch Logs Insights afin de vérifier les journaux de plan de contrôle :

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

Remarque : Remplacez csr-name par le nom de CSR qui présente des problèmes.

Kubectl ne peut pas atteindre le plan de contrôle

Vérifier l'accès au point de terminaison Amazon EKS

Si vous avez activé l'accès privé pour le point de terminaison du serveur API Kubernetes de votre cluster, vous ne pouvez accéder au serveur API qu'à partir des sources suivantes :

• Votre réseau privé virtuel (VPC)
• Un réseau connecté

Si vous exécutez kubectl á partir d'un client qui ne fait pas partie du VPC ou d'un réseau connecté, vous ne pouvez pas accéder au serveur API du cluster. Vous recevez une erreur similaire à l’exemple suivant :

« 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 » (E1009 12:33:44.852680 106 memcache.go:265] n’a pas pu obtenir la liste de groupes de l’API serveur actuelle : Obtenez "APISERVERENDPOINT": composez le code tcp 11.11.111.111:443 : délai d’expiration des i/o)

Pour résoudre ce problème, modifiez l'accès au point de terminaison du cluster en Accès public. Si vous devez disposer d'un cluster privé, créez un hôte bastion Amazon Elastic Compute Cloud (Amazon EC2) dans le VPC du cluster. Puis, utilisez l'hôte bastion pour accéder au cluster. Vous devez ajouter le groupe de sécurité de l'hôte bastion au groupe de sécurité du cluster.

Vérifier la configuration de votre hôte et de vos ports

Si vous recevez le message d'erreur The connection to the server localhost:8080 was refused (La connexion au serveur localhost:8080 a été refusée), vérifiez les configurations de votre hôte et de votre port. L'erreur se produit généralement lorsque kubectl ne trouve pas les informations de port et d'hôte correctes du point de terminaison du serveur API Amazon EKS dans le fichier kubeconfig.

Pour résoudre ce problème, procédez comme suit :

1. Pour mettre à jour le fichier kubeconfig, exécutez la commande update-kubeconfig de l'AWS CLI suivante :

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

   Remarque : Remplacez region-code par votre région AWS et my-cluster par le nom de votre cluster.

2. Pour afficher votre contexte actuel, exécutez la commande suivante :

   kubectl config current-context

3. Pour vérifier l'utilisateur ou le rôle IAM que vous avez configuré dans votre environnement, exécutez la commande get-caller-identity suivante :

   aws sts get-caller-identity

Pour résoudre les problèmes liés à IAM, consultez la section Comment puis-je fournir un accès au cluster à d'autres utilisateurs et rôles IAM après avoir créé un cluster dans Amazon EKS ?

Vérifier les règles du groupe de sécurité de plan de contrôle et de composant master

Si les règles de vos groupes de sécurité de plan de contrôle et de composant master bloquent l'accès au serveur API, le message d'erreur suivant s'affiche :

« The connection to the server APISERVERENDPOINT was refused - did you specify the right host or port? » (La connexion au serveur APISERVERENDPOINT a été refusée. Avez-vous spécifié l’hôte ou le port approprié ?)

Pour résoudre ce problème, assurez-vous que les groupes de sécurité du plan de contrôle et de nœud disposent des règles entrantes et sortantes requises. Le groupe de sécurité du serveur API doit autoriser l'accès entrant depuis le client du serveur API sur le port 443.

Vous ne pouvez pas installer kubectl

Vous devez utiliser une version de kubectl qui se situe dans les limites d'une différence de version mineure par rapport à votre cluster. Par exemple, un client v1.31 peut communiquer avec les versions v1.30, v1.31 et v1.32 du plan de contrôle. Pour éviter tout problème, installez la dernière version compatible de kubectl.

Lorsque vous installez kubectl, l'une des erreurs suivantes peut s'afficher :

« error: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1 »

-ou-

« 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" »

Les erreurs précédentes surviennent généralement lorsque vous utilisez une version antérieure de l'AWS CLI pour exécuter la commande update-kubeconfig. Pour résoudre ce problème, procédez à la mise à jour de l'AWS CLI. Pour plus d'informations, consultez la page Rendre obsolète la version de l’API client Kubernetes v1alpha1 sur le site Web de GitHub.

Vous rencontrez des erreurs d'autorisation lorsque vous exécutez des commandes kubectl

L'erreur suivante peut s'afficher lorsque vous exécutez les commandes kubectl :

« error: You must be logged in to the server (Unauthorized). » (erreur : vous devez être connecté au serveur (Non autorisé)).

Pour résoudre ce problème, consultez la section Comment puis-je corriger l’erreur « You must be logged in to the server (Unauthorized) » (Vous devez être connecté au serveur (Non autorisé)) lorsque je me connecte au serveur d’API Amazon EKS ?