Résoudre ces 6 problèmes de surveillance avec Kubernetes.

Kubernetes, l’un des systèmes de gestion de conteneurs les plus populaires, automatise le travail nécessaire au déploiement et à la mise à l’échelle d’une application conteneurisée en gérant un grand nombre de microservices interdépendants. En outre, il permet la migration et le déploiement d’applications conteneurisées sur différentes plateformes dans un environnement multicloud.

Une récente enquête menée par Red Hat révèle qu’environ 70 % des responsables informatiques travaillent pour des organisations qui utilisent Kubernetes, aussi communément appelé K8s, car il y a des mises à jour régulières par la communauté qui alimente l’écosystème avec les dernières solutions. Cependant, la croissance constante des microservices au sein de la plateforme Kubernetes donne lieu à une multitude de problèmes qui pourraient rendre vos applications critiques indisponibles pour les utilisateurs finaux. Même si Kubernetes est réputé pour déployer des applications pratiquement n’importe où, il fait également face à un retour de bâton pour avoir trop de composants au sein de son réseau. L’un des principaux inconvénients de Kubernetes est que même une minuscule interruption de service au sein du réseau du cluster peut entraîner l’arrêt de toute l’opération.

Il est donc crucial pour les administrateurs informatiques d’être conscients des difficultés qui peuvent survenir dans Kubernetes. Cet article aborde les différents défis auxquels les administrateurs informatiques sont confrontés avec les systèmes K8s et la manière dont un outil de surveillance de Kubernetes les surmonte.

Problèmes rencontrés avec Kubernetes :

• Utilisation inefficace des ressources

• Restriction de l’utilisation du CPU

• OOMKilled

• Erreur CrashLoopBackOff

• Erreur ErrImagePull

• Perturbation du service

• PVC indisponibles pour la liaison

• Indisponibilité de l’application

1. Utilisation inefficace des ressources  

La majorité des problèmes du système Kubernetes sont dus à une mauvaise configuration des ressources du gestionnaire de conteneurs. Lorsqu’une charge de travail est planifiée, le conteneur peut demander la quantité requise de ressources CPU et mémoire. Le planificateur de Kubernetes attribue alors le bon nœud au pod qui peut prendre en charge la tâche en fonction de la quantité de ressources demandées.

Une valeur est généralement spécifiée pour garantir que Kubernetes alloue suffisamment de ressources nodales à un module sans dépasser la limite. Cependant, lorsqu’un conteneur alloue plus de ressources que celles disponibles, l’application ralentit et il en résulte une surutilisation. De même, il y a sous-utilisation lorsque les ressources demandées allouent plus que ce qui est utilisé, ce qui tend également à ralentir l’application.

En outre, une limite peut également être définie pour restreindre la quantité de ressources auxquelles le conteneur peut accéder. Ces contraintes sont préconfigurées dans le pod afin de garantir que la charge de travail est exécutée sans retard et n’entrave pas la progression des autres. Chaque fois qu’une demande de CPU ou de mémoire est faite, la limite d’utilisation est fixée à une valeur telle qu’il y a assez de place pour accommoder une utilisation excessive de ces ressources.

Mais que se passe-t-il si le pod consomme plus que ce qu’il est autorisé à faire ? Cela peut entraîner deux problèmes majeurs pour Kubernetes :

 Restriction de l’utilisation du CPU

La limitation du CPU se produit lorsque l’utilisation du CPU s’approche de la limite du CPU. Étant donné que la limite spécifie l’utilisation maximale du CPU disponible pour le module, l’application n’aura pas accès à une quantité adéquate de ressources nécessaires pour exécuter la charge de travail. Le module peut alors s’arrêter et redémarrer. Comme mécanisme de réponse, le CPU est étranglé pour minimiser l’utilisation du CPU, ce qui ralentit l’application.

OOMKilled  

Le code d’erreur OOMKilled se produit chaque fois que le conteneur consomme plus de ressources mémoire qu’il n’en a été alloué. Lorsque l’utilisation de la mémoire tente de dépasser la limite de mémoire, le processus associé est OOMKilled (Out of Memory Killed), c’est-à-dire qu’il se termine. Le kubelet peut alors redémarrer le pod et essayer d’allouer de la mémoire en fonction de la demande. Si le pod redémarre, il y aura un certain retard dû au temps de chargement qui aura un impact sur l’application conteneurisée.

Souvent le résultat d’une mauvaise configuration, le CPU throttling et les erreurs OOMKilled peuvent être résolus en optimisant ou en supprimant la limite de ressources. Cependant, dans une grande infrastructure de conteneurs, l’identification de ces problèmes peut être un énorme défi car ils se traduisent souvent par une latence et un retard de performance. Comme de nombreux éléments Kubernetes sont impliqués, il peut s’avérer difficile de naviguer dans le réseau et de limiter les anomalies.

Un logiciel de surveillance Kubernetes comme ManageEngine Applications Manager collecte des données pour afficher la valeur limite du CPU et de la mémoire pour chaque pod. Le moniteur de cette solution suit également l’état du module, l’activité d’utilisation du CPU et de la mémoire du cluster, ainsi que le nombre de processeurs CPU allouables pour chaque nœud. En outre, le moniteur affiche des graphiques montrant les 5 nœuds ou pods les plus sollicités, ce qui permet d’identifier facilement les composants qui ont dépassé leur limite de requête.

L’analyse collective de ces données permet de prendre des décisions pour supprimer ou modifier la limite imposée aux pods et aider à contrer la limitation du CPU et le code d’erreur OOMkilled.

2. Erreur CrashLoopBackOff  

Lorsque les ressources CPU ou mémoire sont insuffisantes, les pods peuvent être interrompus sans pouvoir être programmés sur un nœud. Cela incite le kubelet à redémarrer le pod défaillant, qui est alors susceptible de se bloquer à nouveau et d’entrer dans une boucle qui déclenche le code d’erreur CrashLoopBackOff. Chaque fois que le conteneur recule pour redémarrer, le temps de chargement augmente de manière exponentielle. Le code d’erreur CrashLoopBackOff peut également apparaître lorsqu’un conteneur démarre pour la première fois et entre dans une boucle. Parmi les autres responsables de l’erreur CrashLoopBackOff, on peut citer les mauvaises configurations, la non-concordance des noms de ressources, les ressources verrouillées et les problèmes de connectivité.

Comme mentionné précédemment, avoir une visibilité sur l’utilisation des ressources et la configuration de votre conteneur peut aider à éviter que vos pods ne tombent dans la boucle de redémarrage. Le moniteur de conteneurs Kubernetes d’Applications Manager fournit l’état de chaque conteneur et le nombre de fois où ils ont redémarré sur une période donnée. Ces détails peuvent être analysés pour aider à identifier une erreur CrashLoopBackOff potentielle qui pourrait être difficile à repérer autrement.

3. Erreur ErrImagePull

ErrImagePull est une autre erreur qui se produit lorsqu’un pod n’est pas en mesure d’extraire l’image demandée du registre des conteneurs. Le module passe alors à l’état ErrImageBackOff. Cette erreur peut se produire lorsque le nom de l’image du conteneur spécifié dans le module de conteneur est incorrect. La récupération d’une mauvaise image peut également entraîner une défaillance du pod, ce qui peut s’avérer fatal pour les opérations de l’application.

Le recours aux services d’un outil de surveillance de Kubernetes comme Applications Manager aide les administrateurs à effectuer un contrôle approfondi de leur système de conteneurs afin d’identifier les inadéquations potentielles. Ils peuvent alors modifier la spécification du pod pour fournir le nom correct et tirer manuellement l’image. Vous pouvez également consulter le nombre total d’images disponibles dans chaque nœud dans notre tableau de bord Kubernetes.

4. Perturbation des services

Plusieurs services Kubernetes sont chargés de faciliter la communication entre les différents nœuds d’un réseau de clusters. Une interruption de l’un de ces services peut avoir une incidence sur le partage des ressources entre les conteneurs, car le nœud ne sera pas accessible. Les raisons d’une interruption de service peuvent être multiples et avoir un impact considérable sur la connectivité du réseau.

Parfois, les services échouent à l’étape de la création et il peut être difficile de les localiser, en particulier lorsque vous travaillez avec un grand nombre d’entre eux. C’est un autre exemple où la surveillance des services Kubernetes d’Application Manager s’avère utile, car elle répertorie chaque service de conteneur avec l’espace de noms associé et les détails de l’application. Il affiche également le protocole, le type et le port cible de chaque service, ce qui peut être utile pour s’assurer que vos pods écoutent le bon service. Vous pouvez également suivre les espaces de noms associés à chaque service, car toute divergence peut entraîner un échec.

5. PV indisponibles pour  la liaison

Pour une gestion efficace du stockage, il est important de suivre l’état de disponibilité de chaque unité de stockage Persistent Volume (PV) et Persistent Volume Claim (PVC) après son utilisation par un pod. Souvent, lorsqu’un PVC est supprimé, le PV peut rester indisponible après le redémarrage, car d’anciennes données de pod peuvent encore être stockées. Grâce à notre moniteur Kubernetes, les utilisateurs peuvent identifier les PV et PVC indisponibles afin de procéder aux rectifications nécessaires. En outre, notre outil affiche également la classe de stockage de chaque PVC, car il est important de s’assurer qu’ils sont correctement définis. Les PVC sans classe de stockage définie échoueront.

Il est également essentiel de veiller à ce que le bon PV soit référencé dans les gousses. Si la capacité de stockage n’est pas suffisante pour répondre à la demande, il peut en résulter une défaillance du PV. En surveillant les PVC avec Applications Manager, les utilisateurs peuvent avoir une vue d’ensemble de la quantité de stockage demandée par les PVC et vérifier s’ils peuvent être pris en charge par le PV lié.

6. Indisponibilité de l’application  

Chaque nœud est limité à un certain nombre de modules qui peuvent être alloués pour l’utilisation des ressources. Le dépassement de cette limite maximale peut rendre le nœud inaccessible à d’autres pods dont la perturbation de la charge de travail pourrait affecter directement l’application conteneurisée elle-même.

Notre outil de surveillance K8s aide à prévenir l’indisponibilité des applications en décomposant le nombre maximum de pods disponibles et le nombre de pods utilisés pour chaque nœud Kubernetes. Les administrateurs peuvent prendre des mesures rapides pour éviter toute perturbation en désignant des alarmes qui se déclenchent chaque fois que le nombre de pods approche de la limite.

Les avantages de l’outil de surveillance Kubernetes d’Applications Manager :

• Visibilité complète d’un cluster Kubernetes avec des statistiques approfondies et l’état d’activité des nœuds, pods, services et PV.

• Santé et disponibilité en temps réel des différents composants et espaces de noms Kubernetes.

• Graphiques visuels qui trient les différents nœuds et pods, ce qui peut aider à une gestion efficace des ressources.

• Une surveillance sans agent qui peut être configurée en quelques minutes.

• Gestion des pannes avec des alertes instantanées qui se déclenchent dès qu’un paramètre franchit le seuil souhaité.

• Des rapports prévisionnels intelligents qui peuvent aider à prédire les tendances de croissance des ressources Kubernetes sur la base de données historiques.

Conclusion  

Naviguer à travers les différents obstacles courants de Kubernetes à l’aide d’un outil de surveillance complet comme Applications Manager vous permet de tirer le meilleur parti de votre système de gestion de conteneurs. Applications Manager creuse en profondeur dans votre système Kubernetes pour aider à mettre en lumière tout problème susceptible de se présenter.

Applications Manager surveille également d’autres composants de votre infrastructure informatique, tels que les services cloud, les bases de données, les serveurs, le matériel, les services et même l’application elle-même. Avec la prise en charge de plus de 150 technologies, Applications Manager est la solution de surveillance unique pour votre entreprise basée sur des applications.

Apprenez-en plus sur Applications Manager en l’explorant par vous-même grâce à une version d’essai gratuite de 30 jours. Vous pouvez découvrir tous les avantages de la surveillance Kubernetes et comprendre comment le moniteur s’intègre dans votre organisation. Vous pouvez également recevoir des réponses à vos questions sur le produit de la part de nos experts en solutions en planifiant une démonstration gratuite et personnalisée.

 Source : 6 common issues and how to tackle them with Kubernetes monitoring tools  by Karthik Rajakumar