Le monitoring Kubernetes avec New Relic

Introduction

Avant l'arrivée fracassante de Kubernetes, les administrateurs de clusters, les ingénieurs DevOps, les développeurs d'applications et les équipes opérationnelles devaient réaliser de nombreuses tâches manuelles pour la planification, le déploiement et la gestion de leurs applications conteneurisées. La plateforme d'orchestration de conteneurs Kubernetes a changé bon nombre de ces responsabilités.

Kubernetes facilite le déploiement et l'exploitation des applications dans une architecture microservices en créant une couche d'abstraction sur un groupe d'hôtes. Ainsi, les équipes de développement peuvent déployer leurs applications et confier à Kubernetes la gestion des éléments suivants :

• Contrôle de la consommation des ressources par application ou équipe

• Répartition uniforme de la charge des applications sur l'infrastructure hôte

• Équilibrage automatique de la charge des requêtes sur les différentes instances d'une application

• Monitoring de la consommation et des limites de ressources pour arrêter et redémarrer automatiquement les applications qui consomment trop de ressources

• Déplacement d'une instance d'application d'un hôte à un autre en cas de manque de ressources sur un hôte, ou si l'hôte meurt

• Mobilisation automatique de ressources supplémentaires qui deviennent disponibles lors de l'ajout d'un nouvel hôte au cluster

• Déploiements et rollbacks canary simples

Toutefois, ces fonctions viennent aussi s'ajouter à la déjà longue liste de préoccupations des équipes. Par exemple :

• Le nombre de couches à surveiller est bien plus important.

• La nature éphémère et dynamique de Kubernetes rend la résolution des problèmes beaucoup plus compliquée.

• La planification automatique des pods peut entraîner des problèmes de capacité, surtout si le monitoring de la disponibilité des ressources n'est pas en place.

• Jusqu'à récemment, le monitoring des applications exigeait l'alignement avec les pratiques de monitoring de l'organisation, l'installation des agents de langage, l'instrumentation du code de chaque application et le redéploiement de chaque application.

Le fait est que si Kubernetes résout d'anciens problèmes, il peut aussi en créer de nouveaux. Plus particulièrement, avec l’adoption des conteneurs et de leur orchestration, les équipes doivent repenser et adapter leurs stratégies de monitoring afin de prendre en compte les nouvelles couches d’infrastructure qui sont introduites dans un environnement Kubernetes distribué. 

Sachant cela, nous avons conçu ce guide afin de mettre en lumière les principes fondamentaux à connaître pour assurer un monitoring efficace des déploiements Kubernetes avec  Relic One et notre toute dernière innovation, Auto-telemetry with Pixie. Pixie vous apporte l'observabilité Kubernetes instantanément, sans que vous ayez besoin d'instrumenter votre code manuellement ni d'installer les agents de langage. Vous trouverez ici quelques-unes des meilleures pratiques du monitoring de Kubernetes, ainsi que des conseils approfondis pour y arriver avec la plateforme New Relic One.

Que vous soyez administrateur de clusters Kubernetes, développeur d'applications, ingénieur d'infrastructure, ou membre de l'équipe DevOps, à la fin de ce guide, vous devriez pouvoir utiliser New Relic et Auto-telemetry with Pixie pour obtenir instantanément l'observabilité Kubernetes. Ainsi, vous saurez monitorer l'état de santé et la capacité des ressources Kubernetes, déboguer les applications exécutées dans vos clusters, corréler les événements dans Kubernetes à des informations contextuelles pour résoudre les problèmes, et savoir comment suivre l'expérience de l'utilisateur final à partir de vos applications.

Premiers pas avec Kubernetes et New Relic

Pour permettre un monitoring efficace des déploiements Kubernetes, New Relic vous offre une visibilité sur vos clusters et workloads Kubernetes, que vos clusters soient hébergés sur site ou dans le cloud.

L'observabilité Kubernetes instantanée : Auto-telemetry with Pixie

Le monitoring de la performance de vos clusters Kubernetes et des workloads qui y sont exécutés exigeait jusqu'à récemment l'installation de multiples intégrations et agents de langage. C'était compliqué et le monitoring des applications, en particulier, imposait l'instrumentation manuelle de vos applications, la mise à jour du code, et le redéploiement de ces applications. Heureusement, avec notre acquisition de Pixie Labs, nous vous proposons une méthode plus rapide et plus simple.

Désormais, vous obtenez une visibilité dans vos clusters et workloads Kubernetes en quelques petites minutes, sans devoir installer d'agents de langage ni mettre à jour votre code grâce à Auto-telemetry with Pixie. Pixie est une solution d'observabilité dans le cluster Kubernetes native qui collecte automatiquement les données télémétriques en utilisant eBPF. Les données Pixie entrent directement dans Telemetry Data Platform de New Relic, ce qui vous apporte une rétention évolutive des données, une corrélation avancée, des alertes intelligentes et des vues puissantes.

Les intégrations Kubernetes

New Relic et Pixie opèrent avec les clusters Kubernetes hébergés sur site ou dans le cloud, notamment :

• Amazon Elastic Container Service for Kubernetes (Amazon EKS) fournit Kubernetes en tant que service géré sur AWS. Le déploiement, la gestion, l'évolutivité des applications conteneurisés sur Kubernetes en sont ainsi facilités.

• Google Kubernetes Engine (GKE) met à votre disposition un environnement pour le déploiement, la gestion et la scalabilité des applications conteneurisées avec l'infrastructure fournie par Google.

• Microsoft Azure Kubernetes Service (AKS) gère votre environnement Kubernetes hébergé et facilite ainsi le déploiement et la gestion des applications conteneurisées même sans expertise en orchestration de conteneurs. Ce service élimine également la lourdeur des opérations continues et de la maintenance en assurant le provisionnement, les mises à niveau, et la scalabilité des ressources à la demande, le tout en gardant vos applications en ligne.

• RedHat OpenShift apporte aux développeurs un environnement de développement intégré (IDE) pour développer et déployer les conteneurs au format Docker et les gérer ensuite avec Kubernetes.

• Pivotal Container Service (PKS) fournit l'infrastructure et les ressources nécessaires pour déployer et exécuter efficacement les workloads conteneurisés sur les clouds publics et privés.

Le déploiement de l'instrumentation

La solution Kubernetes de New Relic comprend plusieurs composants qui fonctionnent ensemble pour vous apporter l'observabilité de bout en bout sur tous vos clusters. Bien que vous ayez la possibilité de déployer le composant que vous préférez, installez le package entier pour profiter de l'observabilité intégrale.

Pour déployer les solutions d'instrumentation à partir du tableau ci-dessus, nous proposons deux méthodes : l'installation guidée et la configuration manuelle. Déterminez la méthode qui convient le mieux à vos besoins ci-dessous.

Installation guidée

L'installation guidée rend l'instrumentation Kubernetes simple et rapide. Si vous optez pour cette méthode, il vous suffit de choisir Add more data pour ajouter des données, de sélectionner Guided install pour lancer l'installation guidée, puis d'appuyer sur Kubernetes. Sélectionnez Auto-telemetry with Pixie pour obtenir une visibilité APM au niveau du code sans avoir à installer d'agents de langage.

Configuration manuelle

Si vous souhaitez installer manuellement chaque élément de notre solution Kubernetes, suivez les instructions sur la page d'installation de l'intégration Kubernetes avec Helm.

APM : Auto-telemetry with Pixie ou installation d'agents de langage New Relic

Avec Auto-telemetry with Pixie, il n'est plus nécessaire d'installer d'agents de langage afin d'obtenir des informations au niveau du code pour la gestion de la performance des applications (APM) exécutées dans Kubernetes. Pour déployer Pixie, choisissez l'installation guidée.

Si vous voulez installer des agents de langage, instrumentez votre application avec l'API Kubernetes Downward. Nous avons créé un exemple d'application pour vous montrer comment cela fonctionne dans une application Node.js ; vous pouvez cloner ce référentiel pour votre propre utilisation (notre blog sur le monitoring des performances des applications dans Kubernetes explique comment ajouter ce type de métadonnées Kubernetes au monitoring APM des transactions d'applications).

Intégration Kubernetes

L'installation de l'intégration Kubernetes est simple. Suivez les instructions sur la page d'installation et de configuration de l'intégration Kubernetes.

Intégration Prometheus

L'installation de l'intégration Prometheus OpenMetrics dans un cluster Kubernetes est aussi simple que le changement de deux variables dans un manifeste et son déploiement dans le cluster. Consultez la page d'instructions sur l'envoi des données de métriques Prometheus dans New Relic.

Logs

New Relic propose un plug-in de sortie Fluent Bit pour activer New Relic Logs pour Kubernetes afin de collecter les données de log du cluster. Une fois le plug-in téléchargé, vous pouvez le déployer en tant que graphique Helm, ou manuellement sur la ligne de commande, comme indiqué dans la documentation. 

Exploration des données avec Kubernetes Cluster Explorer

Dans New Relic, l'explorateur de clusters Kubernetes Cluster Explorer vous apporte une représentation multidimensionnelle d’un cluster Kubernetes à partir de laquelle vous pouvez explorer vos namespaces, déploiements, nœuds, pods, conteneurs et applications. Cette fonctionnalité vous permet de facilement récupérer les données et métadonnées de ces éléments et de comprendre les relations entre eux.

Kubernetes Cluster Explorer dans New Relic One

Dans Kubernetes Cluster Explorer, vous pouvez :

• Sélectionner le cluster à explorer

• Filtrer par namespace ou déploiement

• Sélectionner des pods spécifiques ou des nœuds pour obtenir des détails sur l'état

Kubernetes Cluster Explorer comporte deux parties principales :

1. Une présentation visuelle de l'état d'un cluster (jusqu'à 24 nœuds) dans laquelle l'explorateur de clusters montre les nœuds présentant le plus de problèmes dans une série de quatre anneaux concentriques :

• L'anneau extérieur affiche les nœuds du cluster avec, pour chacun d'eux, les métriques de performance du CPU, de la mémoire et du stockage.

• L'anneau intérieur suivant affiche la distribution et l'état des pods ne présentant pas d'alerte associée au nœud.

• Le troisième anneau affiche les pods en alerte qui peuvent aussi présenter des problèmes d'intégrité, même s'ils sont toujours fonctionnels.

• Enfin, l'anneau central affiche les pods qui sont en attente ou que Kubernetes ne peut pas exécuter.

Vous pouvez sélectionner n'importe quel pod pour afficher ses informations détaillées (namespaces, déploiement, conteneurs, état d'alerte, utilisation du CPU, utilisation de la mémoire, etc.).

2. Le tableau des nœuds de Cluster Explorer affiche tous les nœuds du cluster, de l'espace de nom ou du déploiement sélectionné et peut être trié en fonction du nom ou de l'état du nœud, du pod ou de son état, du conteneur, du pourcentage d'utilisation du CPU par rapport à la limite, et du pourcentage d'utilisation de la mémoire par rapport à la limite.

Avantages du monitoring avec Cluster Explorer

L'explorateur de clusters élargit les fonctionnalités de monitoring Kubernetes déjà intégrées à la plateforme New Relic One. Utilisez ses fonctions avancées pour filtrer, trier et rechercher les entités Kubernetes afin de mieux comprendre les relations et les dépendances dans un environnement. La visualisation des données par défaut de votre cluster permet d'obtenir des réponses rapidement et de manière intuitive, mais aussi de comprendre les environnements Kubernetes. Ainsi, vous pouvez maîtriser la complexité associée à l'exécution de Kubernetes à l'échelle.

Si votre équipe adopte Kubernetes Cluster Explorer, vous pouvez vous attendre à des performances améliorées, une plus grande cohérence et une résolution plus rapide des erreurs que vous dépannez. Notre plateforme peut vous aider à vous assurer que vos clusters fonctionnent comme prévu ou à détecter rapidement les problèmes de performance au sein de votre cluster, avant même qu’ils n'aient un impact visible sur vos clients.

Développement d'une stratégie d'observabilité Kubernetes complète

Nous vous recommandons de commencer l'observabilité Kubernetes en suivant ces sept étapes :

1. Visualisez vos services

2. Monitorez l'intégrité et la capacité des clusters

3. Corrélez les événements Kubernetes avec l'intégrité des clusters

4. Comprenez les corrélations de l'APM

5. Intégrez les métriques Prometheus

6. Monitorez les logs en contexte

7. Comprenez l'expérience de l'utilisateur final

1. Visualisez vos services

Lorsque vous travaillez dans un environnement Kubernetes, il peut s'avérer difficile de démêler les dépendances entre applications et infrastructure, ou d'explorer dans le détail toutes les entités (conteneurs, pods, nœuds, déploiements, namespaces, etc.) et de naviguer entre toutes celles qui peuvent être impliquées dans un effort de dépannage. Vous devez observer les performances et les dépendances sur tout l'environnement Kubernetes.

Vous devriez pouvoir visualiser les éléments clés de vos services, notamment :

• La structure de votre application et ses dépendances 

• Les interactions entre différents microservices

Aide apportée par New Relic

Kubernetes Cluster Explorer fournit une représentation multidimensionnelle d'un cluster Kubernetes qui vous permet de descendre dans la hiérarchie des données et métadonnées avec une interface haute-fidélité et organisée qui simplifie les environnements complexes. Vos équipes peuvent utiliser cet explorateur de clusters pour dépanner plus rapidement les pannes, goulots d'étranglement et autre comportement anormal dans tous vos environnements Kubernetes.

Alertes suggérées

Lors du premier déploiement dans un compte de l'intégration Kubernetes de New Relic, un ensemble de conditions d'alerte par défaut est déployé sur le compte. La règle d'alerte est configurée sans canal de notification afin d'éviter les alertes indésirables.

Vous pouvez personnaliser les seuils d'alerte selon votre environnement et réviser la règle d'alerte pour envoyer des notifications. Pour plus d'informations, consultez la documentation sur les alertes de New Relic Infrastructure.

2. Monitorez l'intégrité et la capacité des clusters

Les environnements Kubernetes varient de déploiement en déploiement, mais ils ont tous en commun quelques composants, ressources et erreurs potentielles clés. Les sections suivantes présentent les meilleures pratiques et quelques conseils sur la façon d'utiliser New Relic et les alertes pour le monitoring de l'intégrité (état de santé) et de la capacité de tout environnement Kubernetes :

• Suivi de l’utilisation des ressources par les clusters
• Monitoring de la consommation des ressources par les nœuds
• Monitoring des pods manquants
• Recherche des pods qui ne fonctionnent pas
• Dépannage des redémarrages de conteneurs
• Suivi de l’utilisation des ressources par les conteneurs
• Monitoring des volumes de stockage
• Monitoring du serveur maître

Suivi de l’utilisation des ressources par les clusters

Lorsque vous administrez des clusters, vous devez disposer de suffisamment de ressources exploitables dans votre cluster pour éviter tout problème lors de la planification des pods ou du déploiement de conteneurs. Si vous n'avez pas une capacité suffisante pour répondre aux besoins minimaux en ressources de tous vos conteneurs, vous devez accroître la capacité des nœuds ou en ajouter d'autres pour distribuer le workload.

Vous devez savoir :

• Le pourcentage de ressources de clusters utilisées à tout moment 

• Si les clusters sont sur ou sous-provisionnés

• La demande placée sur vos systèmes

Aide apportée par New Relic

Notre intégration Kubernetes réalise le monitoring et le suivi de l'utilisation agrégée des noyaux et de la mémoire sur tous les nœuds de votre cluster, ce qui vous permet de répondre aux demandes de ressources et d'assurer la performance optimale des applications.

Le dashboard New Relic Infrastructure par défaut pour l’utilisation des noyaux et de la mémoire

Alertes suggérées

Définissez des alertes sur l’utilisation des noyaux et de la mémoire des hôtes de votre cluster.

Monitoring de la consommation des ressources par les nœuds

Au-delà du simple suivi des nœuds dans votre cluster, vous devez faire le monitoring de l'utilisation du CPU, de la mémoire et du disque pour les nœuds Kubernetes (workers et masters) afin de vous assurer que tous les nœuds de votre cluster sont sains.

Utilisez ces données pour vérifier que :

• Vous avez suffisamment de nœuds dans votre cluster

• Les ressources allouées aux nœuds existants sont suffisantes pour les applications déployées

• Vous n'atteignez pas les limites de ressources

• etcd fonctionne normalement

Aide apportée par New Relic

New Relic fait le suivi de la consommation des ressources (mémoire et noyaux utilisés) pour chaque nœud Kubernetes, ce qui vous permet de faire le suivi du nombre de demandes réseau envoyées aux conteneurs sur différents nœuds d'un service distribué. Vous pouvez également faire le suivi des métriques sur les ressources pour tous les conteneurs d'un nœud particulier, quel que soit le service auquel ils appartiennent.

Le dashboard New Relic Infrastructure par défaut pour le monitoring de la consommation des ressources des nœuds

Assurez-vous toujours que votre déploiement actuel dispose des ressources suffisantes pour pouvoir évoluer. Sinon, vous risqueriez de ne pas pouvoir déployer de nouveaux nœuds.

Alertes suggérées

Définissez des alertes pour recevoir une notification si les hôtes cessent le reporting ou si l'utilisation du CPU ou de la mémoire d'un nœud tombe en dessous d'un seuil voulu.

Monitoring des pods manquants

De temps en temps, il vous arrivera peut-être de remarquer qu'il manque un pod dans votre cluster. Un pod peut disparaître si les ingénieurs n’ont pas fourni de ressources suffisantes au moment de la planification. Il est possible que le pod n’ait jamais démarré, qu’il soit dans une boucle de redémarrage ou qu’il ait disparu à cause d’une erreur de configuration.

Pour vous assurer que Kubernetes fonctionne correctement, vous devez confirmer l'intégrité et la disponibilité des déploiements de pods. En effet, ces déploiements déterminent le nombre d'instances nécessaires pour chaque pod, instances de sauvegarde comprises. Dans Kubernetes, cela s'appelle un ReplicaSet. Il arrive parfois que le nombre de pods actifs ne soit pas spécifié dans le champ Replicas de chaque déploiement. Mais même quand ils le sont, Kubernetes peut décider de l'exécution d'une autre instance en fonction des ressources que l'administrateur a définies.

Aide apportée par New Relic

New Relic permet d’éviter facilement ce problème en connaissant les limites en ressources du cluster.  

Si vous n’avez pas suffisamment de ressources pour planifier un pod, ajoutez plus d’instances de conteneur au cluster ou remplacez une instance de conteneur par une autre disposant de suffisamment de ressources. En général, vous pouvez utiliser l’intégration New Relic Kubernetes pour repérer les pods manquants et identifier sans délai les déploiements nécessitant votre attention. Cela permet souvent de résoudre les problèmes de ressources ou de configuration avant qu’ils n’affectent la disponibilité ou les performances des applications.

Le dashboard New  Relic Infrastructure par défaut pour le monitoring des pods manquants par déploiement

Alertes suggérées

Définissez une alerte quand le nombre de pods manquants dans un déploiement dépasse un certain seuil pour une période donnée. Si le nombre de pods disponibles pour un déploiement est inférieur au nombre de pods que vous avez spécifiés au moment de la création du déploiement, l'alerte est déclenchée. L’alerte sera appliquée à chaque déploiement qui correspond aux filtres que vous avez définis.

Recherche des pods qui ne fonctionnent pas

Kubernetes planifie les pods dans le cluster de façon dynamique. En cas de problèmes de ressources ou d'erreurs de configuration, la planification risque d’échouer. Si un pod ne s’exécute pas ou s'il n'est pas planifié, il y a sans doute un problème au niveau du pod ou du cluster, voire sur l'ensemble de votre environnement Kubernetes.

Si vous vous rendez compte que des pods ne s’exécutent pas, vérifiez les points suivants :

• Certains pods se trouvent-ils dans une boucle de redémarrage ?

• Quelle est la fréquence des échecs de requêtes ?

• Y a-t-il des problèmes de ressources ou des erreurs de configuration ?

• Un pod a-t-il été désactivé ?

Aide apportée par New Relic

N’oubliez pas que si vous avez des problèmes de ressources ou des erreurs de configuration, Kubernetes risque de ne pas pouvoir planifier les pods. Dans de tels cas, vous devez vérifier le bon fonctionnement de vos déploiements et identifier les erreurs de configuration et les problèmes de ressources.

Avec l’intégration Kubernetes de New Relic Infrastructure (déployée automatiquement lors de l'installation guidée), vous pouvez utiliser les données de déploiement par défaut pour identifier et suivre les pods qui ne s’exécutent pas et les trier par cluster et namespace.

Dashboard New  Relic Infrastructure par défaut pour le monitoring des pods par cluster ou namespace 

En outre, vous pouvez analyser plus avant les causes profondes des pods désactivés, avec les métriques correspondantes. Par exemple, si un pod est désactivé parce que la mémoire d'application a atteint la limite de mémoire définie sur les conteneurs, il est désactivé par le service OOM (Out Of Memory). Dans ce cas, New Relic indique la raison de la désactivation du pod.

Alertes suggérées

Définissez des alertes en fonction du statut de vos pods. Ces alertes doivent se déclencher avec un statut de pod « Échec », « En attente » ou « Inconnu » pendant la période de temps que vous spécifiez.

Dépannage des redémarrages de conteneurs

Dans des conditions normales, les conteneurs ne devraient pas redémarrer. Les redémarrages signalent un dépassement probable d'une limite de mémoire dans les conteneurs ou un problème au niveau du conteneur ou de son hôte. En outre, la façon dont Kubernetes planifie les conteneurs peut rendre difficile le dépannage des problèmes de ressources des conteneurs, car il les redémarre (ou les désactive) dès ils atteignent leurs limites.

Le monitoring des redémarrages de conteneurs vous aide à savoir :

• Si un ou plusieurs conteneurs se trouvent dans une boucle de redémarrage

• Combien de conteneurs ont redémarré au cours d’une période X

• Pourquoi les conteneurs redémarrent

Aide apportée par New Relic

La totalisation des redémarrages de conteneurs fait partie des données de conteneurs que New Relic collecte par défaut avec l’intégration Kubernetes.

Le dashboard New Relic Infrastructure par défaut pour le monitoring des redémarrages de conteneurs

Alertes suggérées

Définissez les alertes sur le nombre de redémarrages de conteneurs Kubernetes. Si vous définissez une alerte, vous recevez immédiatement des informations utiles, mais elle ne laissera pas les redémarrages de conteneurs vous empêcher de dormir.

Suivi de l’utilisation des ressources par les conteneurs

Le monitoring de l’utilisation des ressources par les conteneurs vous aide à vous assurer que les conteneurs et les applications continuent de fonctionner normalement. Par exemple, si un conteneur atteint la limite d’utilisation de la mémoire, l'agent kubelet risque de le désactiver.

Quand vous monitorez l’utilisation des ressources de conteneurs, vous devez savoir si :

• Vos conteneurs dépassent les limites de ressources et affectent la performance des applications

• Il existe des pics de consommation de ressources

• La distribution des erreurs par conteneur suit un schéma particulier

Aide apportée par New Relic

Identifiez tout d'abord la capacité CPU et mémoire qu'un conteneur requiert pour son exécution (ce qui doit être garanti par le cluster) et assurez le monitoring de ces ressources avec New Relic.

Réalisez ensuite le monitoring des limites de ressources des conteneurs. Il s’agit de la quantité maximum de ressources que le conteneur est autorisé à consommer. Dans Kubernetes, les limites de ressources sont illimitées par défaut.

Le dashboard New Relic Infrastructure par défaut pour le monitoring de l’utilisation de la mémoire par les conteneurs 

Le dashboard New Relic Infrastructure par défaut pour le monitoring de l’utilisation du CPU par les conteneurs

Ce type de monitoring peut vous aider à résoudre de manière proactive les problèmes d’utilisation des ressources avant qu’ils n’impactent votre application.

Alertes suggérées

Définissez des alertes sur l’utilisation du CPU et de la mémoire par les conteneurs et sur les limites de ces métriques.

Monitoring des volumes de stockage

Vous devez éviter la perte de données ou les plantages d'application en raison d'un manque d'espace sur vos volumes de stockage.

Dans Kubernetes, les volumes de stockage sont attribués aux pods et ont le même cycle de vie qu'eux ; en d'autres termes, si un conteneur est redémarré, le volume n'est pas affecté, mais si un pod est désactivé, le volume est détruit en même temps. Cette approche convient bien à une application stateless (sans état) ou au traitement par lots quand les données n'ont pas besoin de survivre à la transaction.

Par contre, les volumes persistants sont utilisés pour les applications stateful (avec état) et quand les données doivent être préservées au-delà de la durée de vie d'un pod. Ces volumes conviennent bien aux instances de base de données ou aux files d'attente des messages.

Pour monitorer les volumes Kubernetes :

• Assurez-vous que 1) votre application dispose de suffisamment d'espace disque et 2) vos pods ont suffisamment d'espace.

• Vérifiez l'utilisation des volumes et ajustez soit la quantité de données générées par l'application, soit la taille du volume (en fonction de l'utilisation).

• Identifiez les volumes persistants et appliquez une notification ou un seuil d'alerte différent pour ces volumes, car ils détiennent vraisemblablement des données d'application importantes.

Aide apportée par New Relic

Effectuez le monitoring et recevez des alertes pour les problèmes sur le volume de disques, en particulier dans le contexte des volumes persistants sur lesquels les données doivent être continuellement à la disposition des applications avec état. En effet, celles-ci ne doivent pas être détruites si un pod spécifique fait l'objet d'une nouvelle planification ou est recréé (quand une image de conteneur passe à une nouvelle version, par exemple).

Avec le monitoring des volumes Kubernetes dans New Relic One, vous pouvez définir des alertes afin d'être informé dès qu'un volume atteint un certain seuil. Cette approche proactive vise à limiter les problèmes de performance ou de disponibilité des applications.

Le dashboard New Relic Infrastructure par défaut pour le monitoring des volumes de stockage Kubernetes

Alertes suggérées

Définissez les alertes en fonction des octets disponibles, de la capacité et de l'utilisation des nœuds dans votre cluster. 

Monitoring du serveur maître

Le serveur maître assure que l'état actuel du cluster correspond à l'état souhaité en démarrant ou redémarrant automatiquement les conteneurs et en faisant évoluer le nombre de répliques d'une application données. Il conserve un enregistrement de tous les objets Kubernetes dans le cluster et exécute en continu des boucles de contrôle pour gérer l'état de ces objets.

Le monitoring du serveur maître aide les opérateurs de Kubernetes à connaître l'état de ses composants, ce qui leur permet de réagir de manière proactive avant que le problème n'impacte les services et les utilisateurs finaux.

L'intégration Kubernetes réalise le monitoring et collecte les métriques à partir des composants du serveur maître :

etcd

C'est ici que sont stockés l'état actuel et l'état souhaité du cluster avec les informations sur tous les pods, les déploiements, les services, les secrets, etc. C'est le seul endroit où Kubernetes stocke ses informations.

Pour monitorer un cluster etcd, faites le suivi des éléments ci-dessous :

• Existence d'un leader et taux de modification

• Propositions engagées, appliquées, en attente et en échec

• Performance gRPC

Alertes suggérées

Définissez les alertes pour être notifié si les propositions en attente ou en échec atteignent des seuils inacceptables.

Serveur d'API

L'API centrale RESTful HTTP traite toutes les requêtes provenant des utilisateurs, des nœuds, des composants du serveur maître, et de l'automatisation. Le serveur de l'API traite l'authentification, l'autorisation, la validation de tous les objets, et est responsable du stockage de ces objets dans etcd. Il s'agit du seul composant qui dialogue avec etcd.

Pour monitorer le serveur de l'API, faites le suivi des éléments ci-dessous :

• Taux et nombre de requêtes HTTP

• Taux et nombre de requêtes apiserver

Alertes suggérées

Définissez les alertes à déclencher si le taux ou le nombre de requêtes HTTP dépasse le seuil voulu.

Planificateur

Le planificateur attribue les pods créés aux nœuds workers qui peuvent exécuter ces pods. Pour ce faire, le planificateur actualise les définitions des pods par le biais du serveur de l'API.

Lors de la sélection d'un nœud worker, le planificateur tient compte de plusieurs facteurs, dont le taux de CPU ou de mémoire requis par rapport à ce qui est disponible sur le nœud. Le planificateur actualise les définitions des pods via le serveur de l'API.

Pour monitorer le planificateur, faites le suivi des éléments ci-dessous :

• Taux, nombre et latence des requêtes HTTP

• Latence de planification

• Tentatives de planifications par résultat

• Latence de planification de bout en bout (somme de planification)

Alertes suggérées

Définissez les alertes à déclencher si le taux ou le nombre de requêtes HTTP dépasse le seuil voulu.

Gestionnaire du contrôleur

C'est ici que tous les contrôleurs sont exécutés. Tout comme le planificateur, les contrôleurs utilisent les capacités de surveillance du serveur de l'API pour être notifiés des changements d'état. Une fois notifiés, ils cherchent à rétablir l'état actuel du cluster à l'état souhaité. Par exemple, si nous créons un nouvel objet qui crée un nombre Y de pods, le contrôleur associé est chargé de faire passer l'état actuel du cluster de X pods à un nombre Y de pods.

Pour monitorer le planificateur, faites le suivi des éléments ci-dessous :

• Longueur de la file d'attente

• Nombre de tentatives traitées par la file d'attente

Alertes suggérées

Définissez les alertes à déclencher si les requêtes sur la file d'attente worker dépassent un seuil maximal.

3. Corrélez les événements Kubernetes avec l'intégrité des clusters

Lorsque vous monitorez les événements Kubernetez, vous pouvez corréler l'intégrité (l'état de santé) de votre cluster et d'autres objets avec ces événements, ce qui accélère le dépannage et la résolution des problèmes. Si vous exécutez des environnements Kubernetes complexes, ou si vous n'avez pas accès à la ligne de commande de votre cluster, les événements Kubernetes vous apportent les informations dont vous avez besoin pour comprendre ce qui se passe dans votre cluster.

Par exemple, il est possible qu'un pod ne soit pas correctement planifié et qu'il ne démarre pas parce que le nœud auquel il est affecté ne dispose pas de suffisamment de mémoire. Dans ce cas, le nœud ne peut pas gérer le pod et donc celui-ci reste en attente, mais aucune autre métrique ou métadonnée ne donne d'information plus complète sur le problème. Avec les événements Kubernetes, vous recevez un message clair :

Si vous gérez un déploiement Kubernetes ou si vous développez par dessus un déploiement Kubernetes, vous avez besoin de :

• Visibilité sur les événements Kubernetes pour chaque cluster

• Visibilité sur les événements Kubernetes associés à des objets spécifiques, comme des pods ou des nœuds

• Alertes sur les événements Kubernetes

Aide apportée par New Relic

Comme indiqué dans l'exemple précédent, les événements Kubernetes donnent des informations contextuelles supplémentaires qui ne sont pas fournies par les métriques et les métadonnées. Lorsque vous utilisez les événements Kubernetes avec l'explorateur de clusters, vous obtenez une vue globale de l'état de santé de votre plateforme.

Accédez aux événements Kubernetes à partir de l'onglet Events de l'explorateur de clusters

Lors du dépannage d'un problème dans un pod, les événements Kubernetes trouvent plus facilement les causes profondes et le contexte. New Relic ajoute aussi des détails importants à chaque événement, afin que vous puissiez déterminer si un événement impacte plusieurs pods ou nœuds d'un cluster (lorsque ReplicaSet est ajusté ou un StatefulSet crée un pod, par exemple).

Vous pouvez interroger les événements Kubernetes avec le créateur de graphiques de New Relic, ou les afficher à partir de Kubernetes Cluster Explorer.

Alertes suggérées

Définissez les alertes pour des événements spécifiques sur les objets et les ressources dans votre cluster. Par exemple, New Relic peut envoyer des alertes si une action d'ajustement automatique attendue ne se produit pas.

4. Comprenez les corrélations de l'APM

L’un des principaux avantages de Kubernetes est la dissociation de votre application et de sa logique commerciale des détails spécifiques de son environnement d’exécution. Cela signifie que si vous devez transférer l’infrastructure sous-jacente à une nouvelle version Linux, par exemple, il n'est pas nécessaire de réécrire entièrement le code de l’application.

Quand vous monitorez des applications gérées par une couche d'orchestration, il peut être très utile de pouvoir mettre en relation une trace d’erreur d’une application, par exemple, avec le conteneur, le pod ou l’hôte dans lequel elle s’exécute à des fins de débogage ou de dépannage.

Au niveau des applications, vous devez monitorer la performance et la disponibilité des applications qui s’exécutent dans votre cluster Kubernetes. Pour ce faire, suivez des métriques comme le taux de requêtes, le débit ou le taux d’erreurs.

New Relic APM vous permet d’ajouter des attributs personnalisés et ces métadonnées sont disponibles dans les traces de transactions collectées dans votre application. Vous pouvez créer des attributs personnalisés pour collecter des informations sur le nœud, le pod ou le namespace Kubernetes exact dans lequel a eu lieu une transaction.

Les sections suivantes présentent les éléments clés des applications hébergées dans Kubernetes qui doivent être monitorés :

• Monitoring de l'intégrité des applications
• Prévention des erreurs

Monitoring de l'intégrité des applications

Lorsque vous exécutez des applications dans Kubernetes, les conteneurs dans lesquels elles tournent se déplacent souvent au sein de votre cluster en fonction de l'augmentation ou de la réduction des instances. Dans Kubernetes, cette planification se fait automatiquement, mais elle peut affecter les performances ou la disponibilité de vos applications. Si vous êtes développeur d’applications, il est important de pouvoir corréler les objets Kubernetes aux applications afin de les déboguer et de les dépanner.Vous devez savoir :

• Quelles applications sont associées à quels clusters

• Combien de transactions s’effectuent au sein d’un pod donné

• Quelle est la latence ou le débit sur un pod donné

Aide apportée par New Relic

Pour surveiller les traces des transactions dans Kubernetes, il vous faut une vue de vos applications fondée sur les données. Vous devez corréler les applications avec le conteneur, le pod ou l’hôte sur lequel elles sont exécutées. Vous devez aussi pouvoir identifier les problèmes de performance liés au pod pour la workload de n’importe quelle application.

Utilisez la vue sur les détails du pod dans Kubernetes Cluster Explorer pour analyser la performance des applications exécutées dans ce pod 

Le fait de connaître le nom du pod et celui du nœud où une erreur s'est produite peut accélérer le dépannage. La visibilité sur les traces des transactions met rapidement en relief les anomalies de votre application hébergée dans Kubernetes.

En outre, vous avez la possibilité d'inspecter les traces distribuées de toute application exécutée dans le cluster. Si vous cliquez sur un span particulier dans une trace distribuée, vous pouvez rapidement voir les attributs Kubernetes pertinents pour cette application ; par exemple, vous pouvez savoir à quel pod, cluster, et déploiement le span appartient.

Le tracing distribué de New Relic capture les détails sur les traces à partir de vos applications exécutées dans Kubernetes

La fonctionnalité de tracing distribué de New Relic permet la détection automatisée des anomalies pour identifier les spans lents et les goulots d'étranglement. Nous vous recommandons également de définir des alertes sur les transactions et communications clés avec des API de tiers.

Pour savoir comment gagner en visibilité sur les traces de transactions dans Kubernetes, consultez notre blog sur le monitoring des performances des applications dans Kubernetes.

Alertes suggérées

Définissez des alertes pour toutes les applications exécutées dans l’environnement de production, et plus particulièrement, pour les requêtes de services d'API, les transactions, les latences de service, le temps de disponibilité et le débit, afin qu’une alerte soit envoyée chaque fois qu’une de ces métriques tombe sous le seuil que vous avez défini.

Prévention des erreurs

Si un seul pod ou IP de pod spécifique commence à montrer des signes de défaillance ou à renvoyer des erreurs, vous devez le dépanner avant que ces erreurs n'impactent négativement le cluster ou l'application. Quand un problème survient, identifiez précisément les causes profondes le plus rapidement possible.

Vous devez savoir :

• Dans quel namespace/hôte/pod une transaction a échoué

• Si votre application se comporte comme attendu dans tous les pods

• Quelles sont les performances de l’application X tournant sur le pod Y

Aide apportée par New Relic

New Relic One offre une vue centrée sur le code pour les applications exécutées dans votre cluster, et vous aide à monitorer les applications hébergées dans Kubernetes pour repérer les anomalies au niveau des performances, et identifier les erreurs.

Les profils d’erreurs de l'APM notent automatiquement si des erreurs surviennent dans les mêmes pods depuis les mêmes adresses IP de pods

Alertes suggérées

Définissez des alertes pour suivre les taux d’erreur de n’importe quelle application exécutée dans les environnements de production de Kubernetes.

5. Intégrez les métriques Prometheus

Prometheus est une boîte à outils open source qui fournit le monitoring et les alertes pour les services et applications tournant dans des conteneurs. Elle est largement utilisée pour collecter les données métriques des environnements Kubernetes. Le mécanisme de Prometheus pour exposer les métriques est devenu le standard de fait pour Kubernetes.

Au lieu de dépendre des services pour pousser les métriques, Prometheus utilise un système basé sur la collecte de métriques chronologiques multidimensionnelles des services au niveau des points de terminaison HTTP. Avec ce système basé sur l'extraction, des tiers, comme New Relic, peuvent développer des intégrations qui fonctionnent avec les exportateurs de métriques de Prometheus pour collecter les données importantes pour le stockage et la visualisation.

Aide apportée par New Relic

L'intégration OpenMetrics de Prometheus de New Relic collecte les données télémétriques de nombreux services (tels que Traefik, Envoy, et etcd) qui affichent les métriques dans un format compatible avec Prometheus. Grâce à cette intégration, vous pouvez monitorer des facteurs clés de vos environnements Kubernetes, comme la performance etcd et les métriques sur l'intégrité, la capacité HPA (Horizontal Pod Autoscaler) Kubernetes et la préparation du nœud.

L'intégration est compatible avec Docker et Kubernetes, en utilisant la version 2 de Prometheus.

Après l'installation de l'intégration pour Docker ou Kubernetes, vous pouvez commencer à développer des requêtes pour faire le suivi et visualiser les données Prometheus dans New Relic One. Lorsque vous dépannez des problèmes dans les clusters Kubernetes, les métriques collectées par cette intégration peuvent être visualisées avec celles collectées nativement par Pixie et d'autres intégrations de New Relic.

Consultez la documentation de New Relic pour en savoir plus sur la compatibilité et les exigences, les options d'installation, les limites de données, la configuration, les requêtes des métriques, le dépannage, la transformation des métriques, et bien plus encore.

Exemples d'utilisation des données Prometheus dans New Relic

Dans New Relic, vous pouvez utiliser les données Prometheus de différentes façons, mais envisagez les cas d'utilisation suivants :

Monitoring d'un cluster etcd

Etcd est un datastore de valeurs clés essentiel pour l'exécution des clusters Kubernetes. Prometheus extrait les métriques d'etcd, ainsi, pour vous assurer que vos clusters sont sains, utilisez l'intégration Prometheus OpenMetrics pour monitorer le serveur etcd, le disque, et les métriques réseau tels que :

• etcd_server_has_leader
• etcd_server_proposals_failed_total
• etcd_network_peer_sent_bytes_total
• etcd_disk_wal_fsync_duration_seconds

Kubernetes HPA (Horizontal Pod Autoscaler)

HPA fait évoluer automatiquement votre déploiement Kubernetes en fonction des limites que vous configurez. Après l'installation de l'intégration Prometheus OpenMetrics, vous pouvez utiliser la requête suivante dans le créateur de requêtes de New Relic One pour développer un widget de dashboard et monitorer la capacité HPA restante.

Préparation du nœud

Dans Kubernetes, un nœud est marqué comme étant prêt quand il accepte les workloads (pods). Si un nœud présente des problèmes, Kubernetes lui ajoute le libellé « not ready ». Pour créer une condition d'alerte pour cet état en utilisant l'intégration, exécutez la requête suivante :

Création d'une condition d'alerte pour l'état du nœud

6. Monitorez les logs en contexte

New Relic Logs est disponible dans Kubernetes Cluster Explorer et effectue une recherche quasi instantanée qui apporte toute l'information contextuelle des logs. Quand vous configurez les logs en contexte, vous pouvez corréler les messages de log avec l'application, l'infrastructure, Kubernetes, et même les données.

Par exemple, vous pouvez facilement corréler les messages de log de l'application avec une trace distribuée dans New Relic APM. New Relic ajoute des identifiants de trace aux logs de l'application correspondante et filtre automatiquement ces logs depuis l'interface des traces distribuées. En rassemblant toutes ces données dans un seul et même outil, vous arrivez plus rapidement à trouver la cause profonde des problèmes en l'isolant à partir de tous les logs et en trouvant les lignes de log exactes qui vous permettent d'identifier et de résoudre le problème.

Vous avez ainsi la visibilité de bout en bout, une profondeur et un niveau de détails qui ne sont tout simplement pas disponibles avec des sources de données de logs en silos.

New Relic Logs collecte les données de log de vos clusters

7. Comprenez l'expérience de l'utilisateur final

Si vous commandez un article auprès d’un service de livraison et qu’il vous parvient en retard ou endommagé, vous souciez-vous vraiment de savoir quelle partie du processus de livraison a échoué ? Que ce soit la faute du fabricant, du distributeur ou du service de livraison, le résultat est tout aussi agaçant.

La même logique s'applique aux entreprises qui hébergent des applications dans Kubernetes : si un client parcourt un site Web et qu'une page ne se charge pas ou prend trop de temps, le client n'est pas intéressé par les raisons techniques derrière ce problème. C'est pourquoi il ne suffit pas de tracer les performances de votre propre système, il est également essentiel de monitorer la performance du front-end de vos applications pour comprendre l'expérience réelle de vos clients.

Même si votre application tourne dans Kubernetes, il vous est quand même possible d'identifier et de tracer les indicateurs clés de l’expérience des clients, et d'expliquer comment les performances sur mobile ou dans un navigateur de l'application impactent l'activité. 

Aide apportée par New Relic

Quand vous migrez pour la première fois sur Kubernetes, vous pouvez définir une référence prémigration pour comparer le temps moyen de chargement de l'application front-end avant et après la migration. Vous pouvez utiliser les mêmes stratégies que pour la performance des applications et ainsi obtenir des informations sur des indicateurs clés, tels que le temps de réponse et les erreurs de performance des applications sur mobile et dans un navigateur. Il est également impératif de monitorer le temps de chargement et la disponibilité pour garantir la satisfaction des clients. New Relic Browser et New Relic Mobile sont conçus pour vous offrir une visibilité cruciale sur l'expérience de vos utilisateurs.

La page d’aperçu de New Relic Browser affiche un récapitulatif de la performance des navigateurs pour cette application

Affichez rapidement les plantages, les lancements d’applications et plus encore avec New Relic Mobile.

En outre, les développeurs et les opérateurs doivent comprendre la disponibilité de tous les services hébergés par Kubernetes, qui peuvent se trouver aux quatre coins du monde. New Relic Synthetics est conçu pour suivre la disponibilité et les performances des applications depuis une vaste gamme d’emplacements.

New Relic regroupe les informations métier et les données de performance en un seul et même endroit. Cela aide les équipes développement, opérations, produits et service client à identifier les points à améliorer dans les produits et à trouver de meilleures moyens pour résoudre les erreurs qui peuvent impacter des clients spécifiques.

Alertes suggérées

Alertes New Relic Mobile

• Taux d’erreurs et temps de réponse du réseau mobile pour vous assurer de recevoir une notification sur les points de terminaison les plus importants

Alertes New Relic Browser : 

• Baisse du nombre de sessions de navigateur indiquant des problèmes de disponibilité 

• Taux ou nombre d’erreurs JavaScript du navigateur 

• Durée des interactions avec le navigateur

Alertes New Relic Synthetics

• Taux ou nombre d’erreurs Synthetics

• Temps de réponse de Synthetics

• Contrôles de ping de Synthetics 

Scalabilité réussie de Kubernetes : un exemple concret

Pour marquer vos premiers pas avec Kubernetes, nous avons pensé que vous pourriez trouver utile l'histoire d'une autre organisation qui a très bien su se servir du monitoring pour assurer sa réussite avec Kubernetes.   

Depuis sa création en 1997, Phlexglobal aide les entreprises dans le domaine des sciences de la vie à rationaliser les essais cliniques en leur permettant de prendre en charge leur dossier principal d’étude clinique (également appelé TMF ou Trial Master File, il s'agit du référentiel de données pour tous les documents associés à un essai clinique).

DÉFIS

• L'évolutivité, le monitoring et la gestion des performances de la plateforme TMF de Phlexglobal pendant la migration des workloads vers Kubernetes 

• Le besoin essentiel d'assurer la bonne maintenance de la plateforme non seulement pour prouver le respect des critères clés de conformité avec les réglementations gouvernementales et les normes du secteur, mais également pour faciliter et améliorer la collaboration entre les nombreux partenaires de tout essai clinique.

SOLUTION

L'équipe recherchait un outil qui permettrait une organisation agile respectant les besoins précis des équipes de développement et des opérations IT. Phlexglobal s'est alors tournée vers New Relic pour pouvoir voir la performance à l'échelle du système et ainsi mettre en place un monitoring proactif. Lisez la suite pour apprécier l'impact et les résultats du monitoring intégral.