Comment procéder lorsque mon composant master Amazon EKS passe au statut NotReady en raison de problèmes liés au module PLEG ?

Solution

Lorsque les composants master de votre cluster Amazon EKS passent à l'état NotReady ou Unknown, les charges de travail planifiées sur ce nœud sont perturbées. Afin de corriger le problème, procédez comme suit :

Obtenez des informations sur le composant master en exécutant la commande suivante :

$ kubectl describe node node-name

Dans la sortie, examinez la section Conditions pour trouver la cause du problème.

Exemple :

KubeletNotReady  PLEG is not healthy: pleg was last seen active xx

Les raisons les plus courantes d'un dysfonctionnement de PLEG sont les suivantes :

• Kubelet ne peut pas communiquer avec le démon Docker car celui-ci est occupé ou mort. Par exemple, le démon Docker de votre composant master EKS est peut-être défaillant.
• Un problème de mémoire insuffisante (OOM) ou d'utilisation du CPU au niveau de l'instance cause le dysfonctionnement du PLEG.
• Si le composant master possède un grand nombre de pods, le kubelet et le démon Docker peuvent être confrontés à des charges de travail plus élevées, provoquant des erreurs liées au PLEG. Des charges de travail plus élevées peuvent également survenir si les probes liveness et readiness (tests de vitalité et de réactivité) sont fréquemment sollicitées.

Vérification des journaux kubelet

Vous pouvez vérifier les journaux kubelet sur l'instance pour identifier la cause du dysfonctionnement du module PLEG.

1.    Utilisez SSH pour vous connecter à l'instance et exécutez la commande suivante :

$ journalctl -u kubelet > kubelet.log

Si vous utilisez l'AMI optimisée pour Amazon EKS et que SSH n'est pas activé, vous pouvez vous connecter via SSM. Pour plus d'informations, veuillez consulter la section Se connecter à votre instance Linux à l'aide du gestionnaire de session.

2.    Vérifiez les événements liés au PLEG publiés par kubelet dans ces journaux :

Exemple :

28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m43.659028227s ago; threshold is 3m0s"
28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m48.659213288s ago; threshold is 3m0s"

3.    Vérifiez dans les journaux kubelet s'il existe des pods qui ne répondent pas aux probes liveness et readiness. Ces messages de journaux ressemblent à ce qui suit :

"Probe failed" probeType="Liveness" pod="nginx/bus" podUID=2527afb7-b32c-4c84-97e2-246eb48c97a9 containerName="nginx" probeResult=failure output="Get \"http://192.168.154.18:15020/app-health/livez\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

Utilisez ces journaux afin d'identifier les pods défaillants. Pour les pods identifiés, vérifiez et assurez-vous que les probes sont correctement configurées.

Surveillance de l'utilisation des ressources du composant master

Vérifiez s'il existe un problème au niveau de l'instance, tel qu'une pénurie de ressources due à des problèmes de mémoire insuffisante (OOM) ou à une utilisation élevée du CPU.

Surveillez la métrique d'utilisation du CPU pour le composant master Amazon Elastic Compute Cloud (Amazon EC2) sous-jacent. À l'aide de cette métrique, vérifiez s'il existe des pics soudains ou si l'utilisation du CPU atteint 100 %.

Kubelet indique que le nœud est sous pression lorsqu'il atteint des seuils d'expulsion stricts ou modérés (hard/soft) quelles que soient les périodes de grâce configurées. Vous pouvez vérifier la condition du nœud en exécutant la commande suivante :

$ kubectl describe node <node_name>

Vérifiez si la condition du nœud est indiquée comme MemoryPressure dans la sortie. Dans ces cas, l'instance peut se bloquer en raison de l'indisponibilité des ressources. Cela peut entraîner l'absence de réponse du processus.

Afin d'atténuer les problèmes liés à la pénurie de ressources, il est recommandé de définir des limites d'utilisation du CPU et de la mémoire pour vos pods.

Lorsque vous spécifiez une limite de ressources pour votre conteneur, kubelet applique ces limites. Ces limites restreignent l'utilisation du conteneur en cours d'exécution. Cela permet d'empêcher le pod de mobiliser plus de mémoire que nécessaire et éviter les problèmes de mémoire insuffisante (OOM). Pour plus d'informations, veuillez consulter la section Gestion des ressources pour les pods et les conteneurs sur le site Web de Kubernetes (français non garanti).

Vous pouvez également utiliser Container Insights pour collecter, agréger et résumer les métriques et journaux de vos applications et microservices conteneurisés. Pour plus d'informations, veuillez consulter la section Métriques de Container Insights pour Amazon EKS et Kubernetes. Vous pouvez utiliser node_cpu_utilization et node_memory_utilization pour surveiller l'utilisation des ressources au niveau du nœud. Vous pouvez également définir des alarmes et recevoir des notifications lorsqu'un certain seuil est atteint.

Surveillance des performances du volume Amazon EBS racine

Le module PLEG peut être défectueux en raison de problèmes de disque sur votre volume Amazon Elastic Block Store (Amazon EBS). Dans ce cas, les journaux kubelet ressemblent à ce qui suit :

fs: disk usage and inodes count on following dirs took 1.262610491s: [/var/lib/docker/overlay2/709e904d843733d746e5134e55e3c6553db4c0f5297d5e3c3a86c206bcb6b172/diff /var/lib/docker/containers/158725d2d97578713034c5f5c16291a068349b7e989b417324c142bb584f79ad]; will not log again for this container unless duration exceeds 2s

Cela se produit lorsque vos applications utilisant les pods sur l'instance effectuent des opérations d'E/S intensives sur le disque.

Vous pouvez surveiller l'utilisation des IOPS ainsi que le débit de votre volume Amazon EBS à l'aide des métriques Amazon CloudWatch pour Amazon EBS.

Utilisez les métriques CloudWatch suivantes pour surveiller le débit et les IOPS d'un volume Amazon EBS :

• VolumeReadOps
• VolumeWriteOps
• VolumeReadBytes

Par exemple, vous pouvez calculer la moyenne des IOPS en ops/s à l'aide de la formule suivante :

((VolumeReadOps) + (VolumeWriteOps)) / (Period)

Vous pouvez calculer le débit moyen en octets/s à l'aide de la formule suivante :

((VolumeReadBytes) + (VolumeWriteBytes)) / (Period)

Pour plus d'informations, veuillez consulter la section Comment puis-je utiliser les métriques CloudWatch pour calculer le débit moyen et le nombre moyen d'IOPS fournis par mon volume EBS ?

Afin de résoudre ce problème, vous pouvez augmenter la taille du disque ou modifier le type de volume EBS pour obtenir un meilleur débit d'E/S.

---