Comment puis-je modifier l'état de mes nœuds NotReady (Indisponible) ou Unknown (Inconnu) en Ready (Prêt) ?

Brève description

Vous ne pouvez pas planifier des pods sur un nœud dont l'état indique NotReady (Indisponible) ou Unknown (Inconnu). Vous pouvez planifier des pods uniquement sur un nœud dont l'état indique Ready (Prêt).

La résolution suivante s'adresse aux nœuds dont l'état indique NotReady (Indisponible) ou Unknown (Inconnu).

Si votre nœud indique l'état MemoryPressure (Pression de la mémoire), DiskPressure (Pression du disque) ou PIDPressure (Pression du PID), vous devez alors gérer vos ressources pour autoriser la planification de pods supplémentaires sur le nœud. Si votre nœud indique l'état NetworkUnavailable(Réseau Indisponible), vous devez alors configurer correctement le réseau sur le nœud. Pour plus d'informations, veuillez consulter la sectionNode status (« État des nœuds ») sur le site Web de Kubernetes.

Remarque : pour plus d'informations sur la gestion des expulsions de pods et des limites de ressources, consultez la section éviction par pression de nœudssur le site internet de Kubernetes.

Solution

Vérifiez les pods aws-node et kube proxy pour découvrir la raison pour laquelle les nœuds indiquent l'état NotReady (Indisponible)

Un nœud indiquant l'état NotReady (Indisponible) n'est pas disponible pour les pods à programmer.

Le groupe de nœuds gérés a cessé d'attacher la stratégie CNI (Container Network Interface) à l'Amazon Resource Name (ARN) du rôle de nœud afin d'améliorer le niveau de sécurité. Cela entraîne le passage des nœuds à l'état Notready (Indisponible) en raison d'une stratégie CNI manquante.

1.    Pour voir si le pod aws-node est en état d'erreur, exécutez la commande suivante :

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

Pour résoudre ce problème, suivez les instructions pour configurer les rôles IAM pour les comptes de service (IRSA) pour aws-node DaemonSet.

2.    Pour vérifier l'état de vos pods aws-node et kube proxy, exécutez la commande suivante :

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

3.    Vérifiez l'état des pods aws-node et kube proxy en passant en revue le résultat de l'étape 1.

Remarque : 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 en cours d'exécution. Si aucun pod aws-node ou kube proxy n'est indiqué, passez directement à l'étape 4. Pour plus d'informations, consultez la section DaemonSet sur le site Web de Kubernetes.

Si l'état de votre nœud est normal, vos pods aws-node et kube proxy doivent alors indiquer l'état Running (En cours d'exécution). Par exemple :

$ kubectl get pods -n kube-system -o wide
NAME                             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

Si l'un des deux pods présente un état différent de Running (En cours d'exécution), exécutez la commande suivante :

$ kubectl describe pod yourPodName -n kube-system

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

$ kubectl logs yourPodName -n kube-system

Les journaux et les événements du résultat de describe (description) peuvent révéler la cause pour laquelle les pods n'indiquent pas l'état Running (En cours d'exécution). Pour qu'un nœud passe à l'état Ready (Prêt), les pods aws-node et kube proxy doivent tous deux être en cours d'exécution sur ce nœud.

Remarque : le nom des pods peut être différent de aws-node-qvqr2 et kube-proxy-292b4, comme illustré dans les exemples précédents.

5.    Si les pods aws-node et kube proxy ne sont pas indiqués après l'exécution de la commande à partir de l'étape 1, exécutez les commandes suivantes :

$ kubectl describe daemonset aws-node -n kube-system

$ kubectl describe daemonset kube-proxy -n kube-system

6.    Recherchez dans le résultat des commandes à l'étape 4 une raison pour laquelle les pods ne peuvent pas être démarrés.

Conseil : vous pouvez rechercher des informations sur les raisons pour lesquelles les pods ne peuvent pas être planifiés dans les journaux du plan de contrôle Amazon EKS.

7.    Vérifiez que les versions de aws-node et kube-proxy sont compatibles avec la version du cluster selon les directives AWS. Par exemple, vous pouvez exécuter les commandes suivantes pour vérifier les versions du pod :

$ 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, veuillez consulter le plugin Amazon VPC CNI pour Kubernetes. Pour mettre à jour la version kube-proxy, suivez l'étape 4 de la section mettre à jour la version de Kubernetes pour votre cluster Amazon EKS.

Dans certains cas, le nœud peut afficher un état Unknown (« inconnu »). Cela signifie que le kubelet sur le nœud ne peut pas communiquer avec le plan de contrôle en ayant le bon état du nœud.

Pour résoudre le problème des nœuds présentant l'état Unknown (Inconnu), suivez les étapes décrites dans les sections suivantes :

• Vérifiez la configuration réseau entre les nœuds et le plan de contrôle
• Vérifiez l'état du kubelet
• Vérifiez que le point de terminaison de l'API Amazon EC2 est accessible

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

1.    Confirmez qu'aucune règle de liste de contrôle d'accès au réseau (ACL) de votre sous-réseau ne bloque le trafic entre le plan de contrôle Amazon EKS et vos nœuds de travail.

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 entrantes et sortantes.

3.    (Facultatif) Si vos nœuds sont configurés pour utiliser un proxy, confirmez que le 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 d'API, exécutez la commande netcat suivante depuis l'intérieur de votre nœud de travail :

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

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

5.    Vérifiez que les tableaux de routage sont correctement configurés pour permettre la communication avec le point de terminaison du serveur API via une passerelle Internet ou une passerelle NAT. Si le cluster utilise la mise en réseau PrivateOnly, vérifiez que les points de terminaison de VPC sont correctement configurés.

Vérifiez l'état du kubelet

1.    Utilisez SSH pour vous connecter au nœud de travail affecté.

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

$ journalctl -u kubelet > kubelet.log

Remarque : le fichier kubelet.log contient des informations sur les opérations kubelet qui peuvent vous aider à identifier la cause racine du problème de l'état du nœud.

Si les journaux ne vous fournissent pas d'informations sur la source du problème, exécutez la commande suivante pour vérifier l'état du kubelet sur le nœud de travail :

$ 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 2019-12-04 08:57:33 UTC; 40s ago

Si le kubelet n'indique pas l'état Running (En cours d'exécution), exécutez la commande suivante pour redémarrer le kubelet :

$ sudo systemctl restart kubelet

Vérifiez que le point de terminaison de l'API Amazon EC2 est accessible

1.    Utilisez SSH pour vous connecter à l'un des nœuds de travail.

2.    Pour vérifier si le point de terminaison d'API Amazon Elastic Compute Cloud (Amazon EC2) pour votre région AWS est accessible, exécutez la commande suivante :

$ nc -vz ec2.<region>.amazonaws.com 443
Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!

Remarque : remplacez us-east-1 par la région AWS où se trouve votre nœud de travail.

Vérifiez le profil d'instance de nœud de travail et le ConfigMap

1.    Vérifiez que le profil d'instance de nœud de travail possède les politiques recommandées.

2.    Vérifiez que le rôle d'instance de nœud de travail est présent dans le 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 avoir une entrée pour le rôle AWS Identity and Access Management (IAM) de l'instance de nœud de travail. Par exemple :

apiVersion: v1
kind: 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

---