Comment puis-je faire passer le statut de mes nœuds du statut NotReady ou Inconnu au statut Prêt ?

Lecture de 7 minute(s)
0

Mes composants master Amazon Elastic Kubernetes Service (Amazon EKS) affichent les statuts NotReady ou Inconnu. Je souhaite remettre mes composants master en mode Prêt.

Brève description

Vous ne pouvez pas planifier des pods sur un nœud dont le statut afficheNotReady ou Inconnu. Vous pouvez planifier des pods uniquement sur un nœud dont le statut affiche Prêt.

La résolution suivante concerne les nœuds dont le statut affiche NotReady ou Inconnu.

Lorsque le statut de votre nœud afficheMemoryPressure, DiskPressure ou PIDPressure, vous devez gérer vos ressources pour permettre la planification des pods supplémentaires sur le nœud.

Si le statut NetworkUnavailable de votre nœud est défini, vous devez configurer correctement le réseau sur le nœud. Pour plus d’informations, consultez Statut du nœud sur le site Web de Kubernetes.

Remarque : pour plus d’informations sur la gestion des expulsions des pods et des limites de ressources, consultez Node-pressure eviction sur le site Web de Kubernetes.

Résolution

Vérifier les pods aws-node et kube-proxy pour identifier la raison pour laquelle les nœuds affichent le statut NotReady

Un nœud dont le statut est NotReady n’est pas disponible pour la planification des pods.

Pour améliorer la posture de sécurité, le groupe de nœuds géré peut supprimer la spécification Container Network Interface (CNI) de l’Amazon Resource Name (ARN) du rôle de nœud. Cette absence de politique CNI entraîne le passage des nœuds au statut NotReady. Pour résoudre ce problème, suivez les instructions relatives à la configuration des rôles IAM pour les comptes de service (IRSA) pour aws-node DaemonSet.

  1. Pour vérifier le statut de vos pods aws-node et kube-proxy, exécutez la commande suivante :

    $ kubectl get pods -n kube-system -o wide

    Les résultats se présentent de la manière suivante :

    $ kubectl get pods -n kube-system -o wideNAME                             READY   STATUS    RESTARTS   AGE        IP              NODE
    aws-node-qvqr2                    1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
    kube-proxy-292b4                  1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
  2. Vérifiez la sortie. Si le statut de votre nœud est normal, cela signifie que vos pods aws-node et kube-proxy affichent En cours d’exécution.
    Si aucun pod aws-node ou kube-proxy n’est répertorié, passez à l’étape 3. Les pods aws-node et ** kube-proxy** sont gérés par un DaemonSet. Cela signifie que chaque nœud du cluster doit avoir un pod aws-node et kube-proxy qui s’exécute sur lui. Pour plus d’informations, consultez DaemonSet sur le site Web de Kubernetes.

    Si le statut de l’un des pod n’affiche pas En cours d’exécution, exécutez la commande suivante :

    $ kubectl describe pod yourPodName -n kube-system

    Pour obtenir des informations supplémentaires à partir des journaux des pods aws-node et kube-proxy, exécutez la commande suivante :

    $ kubectl logs yourPodName -n kube-system

    Les journaux et les événements de la sortie décrite peuvent révéler la raison pour laquelle les pods n’affichent pas En cours d’exécution. Pour qu’un nœud affiche le statut Prêt, les pods aws-node et kube-proxy doivent tous deux être En cours d’exécution sur ce nœud.

  3. Si les pods aws-node et kube-proxy n’apparaissent pas dans la sortie de commande, exécutez les commandes suivantes :

    $ kubectl describe daemonset aws-node -n kube-system
    $ kubectl describe daemonset kube-proxy -n kube-system
  4. Recherchez dans la sortie la raison pour laquelle les pods ne peuvent pas être démarrés :

    Remarque : vous pouvez également rechercher dans les journaux du plan de contrôle d’Amazon EKS des informations sur la raison pour laquelle les pods ne peuvent pas être planifiés.

  5. Vérifiez que les versions d’aws-node et de kube-proxy sont compatibles avec la version du cluster conformément aux directives AWS. Par exemple, exécutez les commandes suivantes pour vérifier les versions des pods :

    $ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2$ kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

    Remarque : pour mettre à jour la version aws-node, consultez Utilisation du module complémentaire Amazon VPC CNI pour Kubernetes Amazon EKS. Pour mettre à jour la version kube-proxy, suivez l’étape 4 de la section Mettre à jour la version Kubernetes de votre cluster Amazon EKS.

Dans certains scénarios, le nœud peut afficher le statut Inconnu. Cela signifie que le kubelet sur le nœud ne peut pas communiquer le statut exact du nœud au plan de contrôle.

Pour résoudre les problèmes des nœuds dont le statut affiche Inconnu, suivez les étapes décrites dans les sections suivantes.

Vérifier la configuration du réseau entre les nœuds et le plan de contrôle

  1. Vérifiez qu’il n’existe pas de règles de liste de contrôle d’accès au réseau (ACL) sur vos sous-réseaux qui bloquent le trafic entre le plan de contrôle Amazon EKS et vos composants master.

  2. Vérifiez que les groupes de sécurité de votre plan de contrôle et de vos nœuds sont conformes aux exigences minimales en matière de trafic entrant et sortant.

  3. (Facultatif) Si vos nœuds sont configurés pour utiliser un proxy, vérifiez que ce proxy autorise le trafic vers les points de terminaison du serveur d’API.

  4. Pour vérifier que le nœud a accès au serveur API, exécutez la commande netcat suivante depuis le composant master :

    $ nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

    Remarque : remplacez 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com par le point de terminaison de votre serveur d’API.

  5. Vérifiez que les tables de routage sont configurées pour autoriser la communication avec le point de terminaison du serveur d’API. Cette opération peut être effectuée par le biais d’une passerelle internet ou d’une passerelle NAT. Si le cluster utilise un réseau PrivateOnly, vérifiez que les points de terminaison d’un VPC sont convenablement configurés.

Vérifier l’état de kubelet

  1. Utilisez SSH pour vous connecter au composant master concerné.

  2. Pour vérifier les journaux de kubelet, exécutez la commande suivante :

    $ journalctl -u kubelet > kubelet.log

    Remarque : le fichier kubelet.log contient des informations sur les opérations de kubelet qui peuvent vous aider à trouver la cause première du problème du statut du nœud.

  3. Si les journaux ne fournissent aucune information sur la source du problème, exécutez la commande suivante. La commande vérifie l’état du kubelet sur le composant master :

    $ sudo systemctl status kubelet  kubelet.service - Kubernetes Kubelet
       Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
      Drop-In: /etc/systemd/system/kubelet.service.d
               └─10-eksclt.al2.conf
       Active: inactive (dead) since Wed 2023-12-04 08:57:33 UTC; 40s ago

    Si le kubelet n’affiche pas En cours d’exécution, exécutez la commande suivante pour redémarrer le kubelet :

    $ sudo systemctl restart kubelet

Vérifier que le point de terminaison de l’API Amazon EC2 est accessible

  1. Utilisez SSH pour vous connecter à l’un des composants master.
  2. Pour vérifier si le point de terminaison de l’API Amazon Elastic Compute Cloud (Amazon EC2) de votre Région AWS est accessible, exécutez la commande suivante :
    $ nc -vz ec2.<region>.amazonaws.com 443Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!
    Remarque : remplacez us-east-1 par la région AWS dans laquelle se trouve votre composant master.

Vérifier le profil d’instance du composant master et le ConfigMap

  1. Vérifiez que le profil d’instance du composant master est conforme aux politiques recommandées.
  2. Vérifiez que le rôle d’instance du composant master se trouve dans le fichier ConfigMap aws-auth. Pour vérifier le ConfigMap, exécutez la commande suivante :
    $ kubectl get cm aws-auth -n kube-system -o yaml
    Le ConfigMap doit contenir une entrée pour le rôle AWS Identity and Access Management (IAM) de l’instance du composant master. Exemple :
    apiVersion: v1kind: ConfigMap
    metadata:
      name: aws-auth
      namespace: kube-system
    data:
      mapRoles: |
        - rolearn: <ARN of instance role (not instance profile)>
          username: system:node:{{EC2PrivateDNSName}}
          groups:
            - system:bootstrappers
            - system:nodes
AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 mois