Comment intégrer Kubernetes dans sa stratégie de monitoring ?

La stratégie de supervision de Kubernetes dépasse le cadre même de Kubernetes. On ne va pas construire une plateforme de monitoring spécifiquement pour Kubernetes mais bien intégrer K8s dans notre stratégie globale.

Historiquement, on parlait de supervision mais cette simple notion a beaucoup évolué avec le temps. La fonction primaire d’une solution de supervision est de nous informer sur l’état d’un système d’information (SI) : fonctionnel/dysfonctionnel, et ce pour chacune des applications le composant. C’est une information importante pour le calcul de nos SLAs mais ce dont nous avons besoin, c’est de déterminer pourquoi un SI n’est pas fonctionnel. De plus, nous devons distinguer l’état de notre plateforme Kubernetes (qui est un système complexe) et l’état de notre application. Devons-nous nous focaliser sur la recherche de potentielles défaillances ou sur la compréhension du fonctionnement de notre écosystème ?

Supervision versus observabilité

La supervision telle que nous la concevons se focalise sur la défaillance. Cependant, l’absence de défaillance peut tout simplement vouloir dire que nous ne regardons pas au bon endroit. Tous les composants peuvent être « au vert » sur le dashboard sans que nous ne comprenions si tout se passe bien en dessous. La supervision telle que nous la connaissons se contente de répondre à deux questions simples :

• Quel est le composant dysfonctionnel ?
• Pourquoi ce composant est-il dysfonctionnel ?

Notre maîtrise de la supervision passe donc par notre retour d’expérience sur les situations déjà rencontrées par le passé pour améliorer notre capacité à détecter ces situations.

Pour aller plus loin, il faut s’intéresser au fonctionnement global du système indépendamment de son état. Kubernetes est un système complexe sur lequel nous allons déployer des applications qui sont également des systèmes complexes (micro-services). Les causes de dysfonctionnements peuvent être multiples : on doit donc comprendre leur fonctionnement pour ne plus se contenter de constater les effets (défaillances). Dans cette approche, nous devrons nous intéresser aux logs et métriques de performances mais aussi aux traces. Chaque composant de notre écosystème interagit avec un ou plusieurs autres. Ces interactions sont matérialisées par des traces que nous pouvons exploiter pour analyser notre écosystème dans le temps. L’exploitation des traces passées permet de détecter/anticiper des situations et donc d’y répondre plus vite. Par extrapolation, nous pouvons en déduire le comportement de notre écosystème et anticiper les problèmes en connaissance de cause.

Développer l’observabilité de son écosystème passe par la compréhension de ses composants et de leur état (supervision). En conséquence développer l’observabilité passe déjà par une bonne culture du monitoring.

Quelles données collecter ?

Historiquement, les solutions de supervision sont axées sur la collecte et l’analyse de deux types de données :

• Les logs ;
• Les métriques/indicateurs de performance.

Avec les logs, nous sommes capables de déterminer l’état d’un système en distinguant différents types de messages (information, avertissement, erreur). Alors qu’avec les métriques, nous analysons le comportement de ce système en comparant un indicateur de performance avec un seuil préalablement établi. C’est le dépassement de ces seuils que nous utilisons pour déclencher des alertes et affecter des incidents à des groupes de personnes pour prise en charge.

Avec le Cloud, les choses ont un peu évolué. Les applications que nous hébergeons dans Azure sont capables de produire des logs et des métriques en quantités bien plus importantes que par le passé. Avec Kubernetes, la volumétrie de données produites s’est même accentuée, ce qui pose plusieurs questions :

• Devons-nous tout logger ? Technologiquement, c’est faisable mais il faut s’interroger : en quoi ce log/métrique me permet-il de prendre de meilleures décisions ?
• De quelle fréquence d’échantillonnage ai-je besoin pour prendre des décisions ? La réponse dépendra de plusieurs critères techniques mais aussi contractuels avec le SLA (Service Level Agreement) pour lequel nous sommes engagés. Plus nous sommes exigeants dans notre engagement, plus notre temps de remise en état doit être court, plus nous avons besoin d’informations actualisées.
• Quelle est la valeur de l’information que je collecte ? La réponse à cette question dépend du destinataire de l’information. La métrique de performance d’exécution d’un appel à une API intéresse clairement un développeur pour l’aider à optimiser la performance de son code. A l’opposé, la valeur marchande des transactions en attente de paiement sur un site de commerce électronique a beaucoup de valeur pour le management.

Les informations que nous allons collecter ont donc de la valeur, et cette dernière peut être différente en fonction de celui qui va l’utiliser. Il faudra être en mesure d’identifier ce qui a de l’intérêt pour nous et sous quel format. Bien souvent, la véritable valeur de cette donnée ne pourra être perceptible qu’après une phase de mise en corrélation et de raffinage. A l’ère du Cloud, les données constituent une grande richesse (on parle même d’ « or noir ») mais il ne faut pas perdre de vue que la donnée « raffinée » a un coût et que sa valeur dépend de chaque acteur.

Ne pas négliger la mesure des usages

La plateforme Kubernetes est en mesure de fournir un grand nombre d’informations pouvant être exploitée par plusieurs équipes :

• Opérations (Ops) ;
• Applicatives ;
• Etc.

Les équipes Ops vont s’intéresser à la mesure des usages de la plateforme Kubernetes pour déterminer si notre cluster dispose des ressources suffisantes (les CPU – Central Processing Units – et la mémoire sont des ressources rares) pour héberger nos applications. Les Ops utilisent ces métriques pour configurer des seuils déclencheurs pour ajuster dynamiquement le nombre de nœuds dans notre cluster (mécanisme de cluster autoscaler).

AKS Cluster Autoscaler

Au niveau applicatif, la mesure des usages nous permet de gérer la mise à l’échelle de notre application pour s’adapter dynamiquement à l’usage (mécanisme d’Horizontal Pod scaler). A ce niveau, on observe les critères techniques (CPU & mémoire) mais aussi les indicateurs de performance créés pour observer l’application (nombre d’utilisateurs connectés, nombre d’opérations métiers réalisées…). On utilise ces indicateurs pour déterminer le nombre de pods nécessaires à notre application pour toujours être en mesure de répondre aux sollicitations.

AKS Horizontal Pod Autoscaler

Au niveau FinOps, la mesure des usages se focalise sur le bon usage des ressources mises à disposition pour minimiser le « waste », c’est-à-dire la part de ressource Cloud que nous payons mais que nous ne consommons pas efficacement. Dans un cluster Kubernetes, il y a toujours un niveau de « waste » nécessaire et acceptable pour le bon fonctionnement. Une solution comme KubeCost collecte des métriques qui sont ensuite qualifiées en unités de mesure monétaires via les APIs de cost management de la plateforme Azure. Nous venons ainsi de « raffiner » une donnée brute en lui apportant du contexte.

Un des principes de FinOps est de responsabiliser les consommateurs sur leur usage du Cloud. Appliqué à Kubernetes, chaque équipe en charge d’une application doit être en mesure d’avoir une projection du coût de ses ressources hébergées sur Kubernetes. Cellenza a déjà publié une série d’articles sur FinOps : nous vous invitons à les consulter.

Quelles sont les solutions de supervision ?

Les solutions de supervision sont nombreuses sur le marché. Sans rentrer dans un inventaire détaillé, on peut en identifier plusieurs familles :

• Solution du Cloud provider ;
• Solutions éditeurs ;
• Solutions open-source.

Pour chaque famille, nous avons retenu un candidat, le plus représentatif possible.

Solution du Cloud Provider

Dans un premier temps, il est logique de s’intéresser aux solutions mises à disposition par notre fournisseur Cloud. Dans le contexte d’Azure, c’est Azure Monitor, solution de type SaaS, nativement présente sur la plateforme Azure, rapide à mettre en œuvre et pour laquelle tout est livré sur étagère, prêt à consommer, sans aucun coût de build/run. Les clusters Kubernetes sont pris en charge par Container Insights. L’avantage de la solution est qu’elle prend en charge AKS mais aussi d’autres distributions de Kubernetes grâce à Azure ARC, que celles-ci soient déployées dans Azure, on-premise ou même chez un autre Cloud provider.

Source : Container Insights

La solution Azure Monitor présente de nombreux avantages mais peut avoir un défaut : elle est intrinsèquement liée à Azure, ce qui exclut de l’utiliser dans un contexte multicloud. Nous devons alors envisager des solutions indépendantes de notre/nos fournisseur(s) Cloud.

Solutions éditeurs

Dans cette deuxième catégorie de solutions, on trouve principalement des solutions de type SaaS. Cela présente de multiples avantages :

• Nous n’avons pas de coût de build/run d’une infrastructure ;
• La solution étant indépendante de notre fournisseur Cloud, nous pouvons avoir une vue complète de notre écosystème applicatif, que celui-ci soit localisé dans un datacenter ou chez n’importe quel fournisseur Cloud ;
• Les fournisseurs de ce type de solutions peuvent proposer un monitoring spécifique à certains usages comme Kubernetes ou les micro-services, ce qui peut être un accélérateur non négligeable.

Un acteur comme Splunk propose une offre SaaS couvrant tous les domaines de l’observabilité, jusqu’à la mesure de l’expérience utilisateur de nos applications. Dans le contexte de Kubernetes, la solution de Splunk se positionne à plusieurs niveaux :

• La plateforme en elle-même (Kubernetes) ;
• Les hôtes « nodes » composant notre plateforme Kubernetes ;
• Les conteneurs « pods » qui sont instanciés sur notre plateforme Kubernetes ;
• Les micro-services présents au sein de nos « pods ».

Splunk SaaS Cloud Observability suite – Kubernetes

Un autre intérêt de l’offre Splunk est qu’elle est compatible avec OpenTelemetry, un projet open-source porté par la CNCF (Cloud Computing Native Foundation) qui propose un standard unifié de collecte des données de supervision, donc un agent technique unique, indépendant de la solution de supervision que nous devons choisir. L’initiative est certes récente mais permettra à terme d’introduire une couche d’abstraction entre nos clusters Kubernetes et les solutions de supervisions.

Les solutions open-source

Reste maintenant la dernière catégorie, que l’on pourrait nommer « Do It Yourself » : des solutions open-source. La lecture du Tech-Radar de la CNCF nous permet d’avoir un panorama des solutions recommandées. On retrouve fréquemment l’association des deux projets open-source Prometheus & Grafana comme illustré ci-dessous :

Stack Prometheus + Grafana

D’un côté, nous avons une infrastructure Prometheus qui se charge de la collecte et du stockage des données de supervision (métriques entre autres). De l’autre, Grafana a pour fonction de proposer des dashboards. A cela, nous devons ajouter des mécanismes de notification pour informer les différents acteurs ou déclencher des réactions (WebHook). La particularité de cette infrastructure est qu’il est possible de la déployer sous forme d’applications sur notre cluster Kubernetes. Le principe peut sembler intéressant mais cela implique déjà une certaine expérience dans le domaine de Kubernetes. Autre point d’attention : cette architecture ne prend pas en compte les logs produits par Kubernetes ou ceux de nos applications. Ce n’est donc pas un simple assemblage de deux solutions open-source mais bien un écosystème que nous devons construire.

Ces solutions sont intéressantes mais beaucoup d’entre elles se focalisent uniquement sur Kubernetes. Or, K8s n’est qu’un composant de notre stratégie applicative. Les clusters Kubernetes hébergent nos applications et consomment beaucoup de services externes (stockage, bases de données, secrets) qui doivent eux aussi être pris en compte dans notre stratégie. Pour cette raison, choisir une solution uniquement spécialisée sur Kubernetes n’est pas forcément pertinent.

L’essentiel à retenir sur la stratégie de supervision

Le choix d’un produit en lui-même n’est pas le plus important. L’essentiel est de développer SA stratégie de supervision/observabilité. On part de données « brutes » issues d’Azure et de Kubernetes. Toutes les solutions savent les collecter. Ce qui compte c’est comment nous raffinons ces données pour produire des indicateurs qui permettent une prise de décision éclairée par différents acteurs :

• Les équipes en charge de la gestion de nos infrastructures Cloud ;
• Les équipes en charge des clusters Kubernetes ;
• Les équipes en charge des applications ;
• Les décideurs métiers.

Chacune de ces équipes a des attentes différentes. Au même titre que le DevOps, l’observabilité est une culture que l’on développe : cela prend du temps. D’un point de vue purement opérationnel, il n’est pas envisageable de mettre en production une plateforme Kubernetes sans solution de supervision/observabilité. Une stratégie peut donc impliquer de commencer avec des solutions de type SaaS qui permettent de nous focaliser sur Kubernetes et nos applications, et non sur le maintien en condition opérationnelle de la plateforme. Si en plus, cela peut être la solution que nous utilisons déjà pour Azure, nous nous économisons un temps d’apprentissage, ce qui n’est pas négligeable.

Pour aller plus loin sur Kubernetes

Pour mettre en pratique tout ce que vous avez appris au cours du Mois du Conteneur, Cellenza vous propose de voir le replay du webinaire de clôture. Pendant une heure, Benoît Sautière (Senior Technical Officer chez Cellenza), Stanislas Quastana (Cloud Solution Architect chez Microsoft) et Louis-Guillaume Morand (Cloud Solution Architect chez Microsoft) vous présentent les différentes étapes à suivre pour adopter Kubernetes dans votre entreprise !

Retrouvez également tous les articles du Mois du Conteneur :

• Un mois pour tout savoir sur Kubernetes
• Kubernetes au service de votre stratégie applicative
• Kubernetes : un écosystème à construire
• Stratégie de CI/CD sur Kubernetes
• Mettre en place sa stratégie de migration vers Kubernetes
• Comment intégrer Kubernetes dans sa stratégie de monitoring ?
• Sécuriser son service Kubernetes

Tous ces articles sont compilés dans un livre blanc téléchargeable gratuitement.