Webinar Kubernetes Monitoring 10 Juin 2022

Le 10 juin 2022, Lionel Porcheron a présenté pendant une heure comment monitorer un cluster Kubernetes : les éléments à superviser, les bons indicateurs à remonter, comment ne pas surcharger son cluster avec le monitoring, et quelques erreurs à éviter. Le webinar s'adressait à toute personne ayant des connaissances générales d'infrastructure et de DevOps ; le replay et les slides sont disponibles ci-dessous.

Ce que couvrait le webinar

Pourquoi Kubernetes change la donne

Kubernetes repose sur de nombreux composants (API server, kubelets, scheduler, controller manager…), le nombre de nœuds varie à la demande, les conteneurs sont redémarrés, mis à jour et déplacés en permanence, et les ressources ne sont souvent accessibles que depuis le cluster lui-même. Les outils de la génération Nagios, construits autour d’un inventaire statique, ne sont pas conçus pour ces workloads dynamiques ; Prometheus, qui s’appuie massivement sur les labels, l’est.

Les indicateurs à suivre

Pour les services, la méthode RED : taux de requêtes, taux d’erreurs, distribution des durées. Pour les ressources, la méthode USE : utilisation, saturation (longueur de file d’attente), erreurs. Sur les nœuds du cluster, on surveille en plus :

• l’utilisation des ressources : CPU, mémoire, I/O, espace disque ;
• le bon fonctionnement des composants Kubernetes : kubelet, API ;
• la validité des certificats, émis pour un an par défaut ;
• le nombre de nœuds et de pods du cluster.

La collecte passe généralement par un DaemonSet, et le projet kube-state-metrics fournit une bonne base de métriques Kubernetes.

Monitorer les services qui tournent dans le cluster

Le monitoring doit trouver les pods par service discovery plutôt que par une liste figée. Au-delà des ressources et de l’usage (débit, temps de réponse, codes d’erreur), l’instrumentation du code avec un SDK Prometheus apporte les métriques applicatives. Attention aux labels : dans le modèle Prometheus, changer un label crée une nouvelle série.

Dashboards et alertes sans surcharger le cluster

Le tableau de bord par défaut doit montrer les golden signals de tout le cluster, avec des vues détaillées par nœud et par pod pour creuser. Côté alerting, la règle est simple : une alerte signifie qu’une action humaine immédiate est nécessaire ; tout le reste relève du dashboard.

Aller plus loin

• Monitoring Kubernetes avec Bleemeo : l’agent en DaemonSet et le tableau de bord du cluster.
• Monitorer un cluster Kubernetes en 10 minutes, pas à pas.
• Monitoring de disponibilité : la sonde externe qui voit le service comme vos utilisateurs.
• Getting started with Kubernetes monitoring (article en anglais).

Replay

Voir le replay sur la chaîne Youtube de Bleemeo:

Slides

Les slides présentés lors de ce webinar: