Pourquoi le monitoring et l’alerting d’un cluster K8S sont primordiaux ?

Les équipes informatiques comprennent déjà très bien la nécessité de surveiller leur infrastructure. De nombreux produits sont disponibles pour l’infrastructure historique: Nagios, Zabbix sont par exemple des acteurs bien connus dans ce domaine.

Mais, dans l’écosystème Kubernetes, il y a de nouveaux et nombreux niveaux d’abstraction. Ainsi, le troubleshooting devient beaucoup plus délicat si vous ne disposez pas des bons outils. Combien de DevOps se sont retrouvés confrontés à la fameuse erreur:

Failed scheduling No nodes are available that match all of the following predicates::Insufficient CPU

Le suivi des ressources d’un cluster doit être fait en temps réel car par rapport à l’infrastructure traditionnelle, les ressources d’un cluster évoluent et changent constamment. Vous ne pourrez jamais savoir où vos pods seront lancés sur votre cluster. Pour ces raisons, nous devons surveiller à la fois les ressources sous-jacentes mais aussi la santé du cluster lui même.

Enfin, un simple monitoring ne suffit pas si vous n’utilisez pas d’alertes en complément. On se doute bien que les équipes de production ne resteront pas toute la nuit à contempler leurs dashboards sur les clusters critiques.

Pourquoi choisir Prometheus et Grafana?

Avec un ensemble complet d’outils d’alerte et de surveillance, pourquoi devrions-nous choisir Prometheus et Grafana en particulier?

Prometheus

Prometheus est un outil de surveillance open source. Il a été initialement développé chez Soundcloud mais est désormais un projet open source autonome, qui fait partie de la Cloud Native Computing Foundation (CNCF) en 2016. C’est le deuxième projet après… Kubernetes lui-même. C’est la première raison pour laquelle les deux composants sont souvent associés étant des projets étroitement liés.

En plus de cela, Prometheus diffère de nombreux autres outils de surveillance car son architecture est basée sur du pull. Il récupère en permanence les métriques des composants surveillés.

Enfin, dans son architecture elle-même, Prometheus utilise un modèle de données multidimensionnel très similaire à la façon dont Kubernetes organise ses données par labels. Contrairement à un modèle de données où chaque métrique est unique et chaque paramètre a sa propre métrique, avec Prometheus, tout est stocké sous forme de paires clé / valeur en time-series:

<metric name>{<label name>=<label value>, …}

L’architecture Prometheus comprend trois composants principaux:

• Le serveur prometheus lui-même: qui collecte des métriques et répond aux requêtes via l’API
• Un pushgateway: pour exposer les métriques pour les tâches éphémères et courtes
• Un alertmanager: pour activer la publication des alertes comme son nom l’indique

Nous utiliserons ici une combinaison de Prometheus node_exporter et kube_state_metrics pour publier des métriques sur notre cluster.

Grafana

Grafana est un outil de visualisation open source populaire (licence Apache 2.0) pour Prometheus qui prend en charge nativement les requêtes de données de Prometheus. En fait, la source de données Grafana pour Prometheus est incluse depuis Grafana 2.5.0 (2015–10–28).

Grafana est, de plus, extrêmement facile à utiliser car il offre des fonctionnalités de templates vous permettant de créer des tableaux de bord dynamiques et modifiables en temps réel.

Enfin, il existe une très bonne documentation et une vaste communauté de partage, et notamment de dashboards publics. Nous utiliserons deux dashboards publics spécialement conçus pour Kubernetes dans cet article.

Après toute cette théorie, passons aux choses sérieuses !

Prérequis pour l’installation

La seule exigence que nous ayons pour ce projet est un cluster kubernetes fonctionnel. Par souci de simplicité, j’utiliserai dans cet article une installation de minikube sur une VM AWS EC2.

Minikube est un moyen pratique d’installer un cluster Kubernetes avec un seul node pour de la non-production, sandbox ou des tests. Il est particulièrement efficace sur les ordinateurs individuels, car ne nécessite pas de ressources importantes et prend en charge plusieurs fonctionnalités K8S prêtes à l’emploi.

Il fonctionne normalement en créant une VM directement sur la machine en s’appuyant sur un hyperviseur interne, mais étant sur une VM AWS, j’utiliserai le mode vm–driver = none de Minikube pour cette démonstration.

Installer Prometheus et Grafana avec Helm

Nous allons installer les deux produits en nous appuyant sur Helm , un gestionnaire de packages Kubernetes qui a été mis à jour vers la version 3.0 en novembre 2019.

Pour information, cette mise à jour est très importante car Helm a été profondément réécrit pour rattraper les évolutions de Kubernetes telles que RBAC et les définitions de rôles personnalisés. Cela le rend beaucoup plus production-ready que les versions précédentes. Auparavant, de nombreux experts étaient réticents à utiliser Helm pour les clusters de production en raison de son modèle de sécurité permissif et de sa dépendance à un composant controversé nommé Tiller (désormais supprimé de la version 3.0).

Nous utiliserons des charts (format de packaghing de Helm) du repo stable Helm pour vous aider à démarrer avec la surveillance des composants du cluster Kubernetes et des métriques système.

Installation de Helm

Ajoutez le référentiel stable à votre installation Helm:

$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/
 $ helm repo update

Ensuite, nous allons créer un custom namespace sur notre cluster K8s pour gérer toute la pile de surveillance:

$ kubectl create ns monitoring

Installer Prometheus

Nous pouvons maintenant installer le chart Prometheus dans namespace monitoring nouvellement créé

$ helm install prometheus stable/prometheus --namespace monitoring
NAME: prometheus
LAST DEPLOYED: Tue Apr 14 09:22:27 2020
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The Prometheus server can be accessed via port 80 on the following DNS name from within your cluster:
prometheus-server.monitoring.svc.cluster.local[...]

Ensuite, nous pouvons créer un NodePort à l’aide de la commande impérative native de K8s qui nous permet de communiquer directement avec le pod depuis l’extérieur du cluster. Sachez simplement que cette étape est facultative si vous n’avez pas l’intention d’interroger Prometheus sans Grafana.

Nous pouvons voir que le port 30568 a été automatiquement alloué pour mapper le port 9090 au pod.

Je peux maintenant accéder au endpoint Prometheus en utilisant mon DNS public et le port 30568 de mon navigateur.

Ainsi, nous pouvons directement interroger Prometheus pour obtenir, par exemple, la consommation CPU par namespace à l’aide de la commande suivante:

sum(rate(container_cpu_usage_seconds_total{container_name!=”POD”,namespace!=””}[5m])) by (namespace)

Installation de Grafana

Maintenant que Prometheus est installé, plutôt que d’interroger chaque métrique individuellement, il est bien plus pratique d’utiliser Grafana pour obtenir des tableaux de bord complets regroupant plusieurs métriques en un seul endroit.

Nous utilisons à nouveau helm pour installer grafana dans le namespace monitoring :

$ helm install grafana stable/grafana --namespace monitoring



Nous pouvons voir que le pod grafana fonctionne ainsi que les composants prometheus

Nous pouvons voir que le pod grafana fonctionne ainsi que les composants prometheus

Là encore, nous créons un service NodePort pour accéder à Grafana depuis l’extérieur du cluster (cette fois c’est obligatoire):

$ kubectl -n monitoring expose pod grafana-5b74c499c6-kt4bw --type NodePort --name grafana-npservice/grafana-np exposed

Récupérons le port externe mappé sur le port d’écoute Grafana 3000: (ici 31399)

$ kubectl -n monitoring get svc grafana-npNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
grafana-np NodePort 10.111.59.2 <none> 80:30368/TCP,3000:31399/TCP 3h8m

Renseignez dans votre navigateur: FQDN:PORT et voilà!

Grafana a des fonctions de gestion des utilisateurs et, par défaut, vous devez vous connecter à l’aide de l’utilisateur admin.

Pour obtenir le mot de passe administrateur, tapez ce qui suit:

kubectl get secret — namespace monitoring grafana -o jsonpath=”{.data.admin-password}” | base64 — decode ; echoADMINPASSWORD

Vous pouvez maintenant vous connecter.

La première étape consiste à configurer Prometheus comme source de données en utilisant la structure DNS interne de Kubernetes:
http: //prometheusServiceName.namespace.svc.cluster.local: port

Ce qui est dans mon cas:
http: //prometheus-server.monitoring.svc.cluster.local (Le :80 est facultatif)

Maintenant que la source de données a été ajoutée, nous allons importer deux dashboards communautaires utiles pour surveiller à la fois notre workload et la santé du cluster. Ils devraient fonctionner directement.

Cliquez sur le bouton d’importation et saisissez l’ID du tableau de bord Grafana:

Installons 1860 puis 8685 qui sont complémentaires:

Vous devriez maintenant avoir deux tableaux de bord fonctionnels:

Nous sommes désormais en mesure de surveiller facilement les métriques système et la configuration du cluster!

Alerting sur Channel Slack

Maintenant que nous avons une solution de surveillance fonctionnelle, la deuxième étape consiste à activer l’alerting.

Il existe deux façons d’implémenter l’alerting dans notre stack de surveillance. Nous pourrions utiliser le composant prometheus AlertManager (qui est installé par le helm chart) ou la fonction d’alerting intégrée de Grafana. Nous allons opter pour cette dernière car plus facile à mettre en œuvre.

Grafana peut envoyer une alerte sur Slack, courrier, webhook ou d’autres canaux de communication. Comme j’utilise beaucoup Slack et que je sais que plusieurs entreprises le font également, je vais prendre cet exemple.

Créer le canal de notification Slack

La première étape consiste à ajouter Slack en tant que canal de notification. Dans grafana, cliquez sur la cloche à gauche, sélectionnez le menu canal de notification puis créez un nouveau canal.

Vous verrez le grand nombre d’outils compatibles avec Grafana pour l’alerting.

Sélectionnez Slack et saisissez l’URL de votre URL de webhook Slack (les autres champs sont facultatifs).

Si vous ne disposez pas déjà d’une URL de webhook, suivez ce tutoriel: https://api.slack.com/messaging/webhooks

Cela vous aidera à créer un point de terminaison pour envoyer des messages à un canal spécifique de votre serveur Slack.

Créez et testez votre alerte personnalisée

Maintenant que votre canal est configuré, prenez votre tableau de bord «K8S Cluster Summary» et cliquez sur le titre Cluster Pod Capacity pour modifier le panel.

Nous allons mettre en place une alerte pour surveiller la capacité du pod, qui est limitée à 110 par Kubernetes par défaut sur chaque nœud. Cette limite est considérée comme la limite de fiabilité. Si le nombre de nœuds dans votre cluster est limité et si vous atteignez cette limite stricte de 110, les pods restants entreront dans un état d’attente. Ce qui pourrait être très problématique dans un cluster de production en plein scaling lors d’un pic d’activité par exemple.

Nous allons configurer une alarme à 90 pods:

De retour sur notre cluster, créons un déploiement arbitraire avec 100 réplicas nginx:

$ kubectl create ns loadtest
namespace loadtest created$ kubectl create deployment nginx --image=nginx -n loadtest
deployment.apps/nginx created$ kubectl -n loadtest scale deployment nginx --replicas=100
deployment.apps/nginx scaled

Nous pouvons voir que la capacité du pod augmente rapidement à 115 en raison des 15 pods initiaux existants dans le cluster:

C’est 5 pods de plus que les 110 autorisés et effectivement, nous pouvons constater sur les dashboards que 5 pods sont en attente.

Après 5 minutes, l’alerte passe à l’état ALERTING et envoie notre notification sur le canal Slack avec le message personnalisé et la valeur correspondante.

Nous pouvons réduire le déploiement à 1 pod:

$ kubectl -n loadtest scale deployment nginx — replicas=1
deployment.apps/nginx scaled

La capacité du pod est redescendue:

Et une alerte de retour à la normale est envoyée sur Slack.

Ce petit exercice était très intéressant car il est assez simple à mettre en œuvre mais propose quand même un scénario réaliste.

Il y a quand même quelque chose à noter concernant la fonction d’alerting Grafana. Nos deux tableaux de bord utilisent des fonctions appelées template variables. Les variables sont les valeurs que vous pouvez modifier en haut des tableaux de bord comme l’hôte, le cluster ou le namespace.

De par sa conception, Grafana n’autorise pas les alertes sur les template variables pour plusieurs raisons que vous pouvez lire ici . Si vous essayez de mettre des alertes sur certains panneaux des dashboards, vous pourrez avoir une erreur pour cette raison. La solution sera de spécifier pour chaque alerte un hôte, un cluster ou un node spécifique à surveiller sans utiliser de variable.

Conclusion

Après avoir pris en main Prometheus et Grafana, j’espère que vous avez apprécié cet article et compris pourquoi la surveillance était primordiale dans l’écosystème de Kubernetes.

This post was originally available on Medium on 27/11/2020.