Surveillance et alertes Kubeadm : guide pratique de mise en œuvre

Introduction

Surveiller un cluster kubeadm ne consiste pas à collecter toutes les métriques possibles. Il s'agit de répondre de manière fiable à trois questions : quel est l'état actuel, qu'est-ce qui a changé et que faut-il faire lorsqu'un seuil est franchi. Ce guide présente une mise en œuvre pratique à l'aide de Prometheus, Alertmanager et Grafana sur un cluster déployé avec kubeadm, avec des commandes concrètes, les sorties attendues et les étapes de récupération.

Le public cible est constitué des développeurs, des consultants DevOps et des équipes techniques de startups qui exploitent leurs propres clusters Kubernetes. Vous apprendrez à déployer une pile de surveillance, à définir des règles d'alerte, à vérifier que les alertes se déclenchent et à répondre aux modes de défaillance courants. Chaque étape suit un modèle de sécurité opérationnelle : observer avant de modifier, délimiter le changement, vérifier le résultat et documenter la récupération.

Tout au long de l'article, remplacez les valeurs d'espace réservé (comme <votre-namespace>, <votre-email>) par les vôtres. Les commandes supposent un cluster kubeadm fonctionnel avec kubectl configuré et Helm v3 installé. Aucune information d'identification réelle ni identifiant de production n'est utilisé.

Inventaire des versions et de l'environnement

Avant de toucher à un composant, établissez une base de référence. Vous devez connaître la version de Kubernetes, la version de kubeadm, le système d'exploitation des nœuds et l'état actuel du cluster. Exécutez ces commandes en lecture seule :

kubectl version --short
kubeadm version -o short
kubectl get nodes -o wide

Sortie attendue pour la première commande sur un cluster typique :

Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.27.3

Si kubectl get nodes affiche un nœud à l'état NotReady, résolvez ce problème avant d'installer les outils de surveillance. Un nœud sain doit afficher Ready et la version correcte dans la colonne VERSION.

Prérequis pour la pile de surveillance :

• Cluster créé avec kubeadm (version 1.22 ou ultérieure recommandée pour des API de métriques stables).
• kubectl configuré pour accéder au cluster avec des privilèges d'administrateur de cluster.
• Helm 3 installé localement.
• Accès Internet depuis le cluster pour extraire les images de conteneurs (ou un registre pré-rempli).
• Au moins 2 Go de mémoire libre et 2 cœurs de processeur disponibles sur les nœuds de travail pour les composants de surveillance.

Enregistrez les éléments suivants dans un runbook : nom du cluster, version de kubeadm, version de Kubernetes, liste des nœuds avec leurs rôles et date de la base de référence. Utilisez une commande horodatée comme date -u pour enregistrer le moment où la base de référence a été prise. Stockez ces informations dans un endroit sécurisé, pas dans un dépôt public.

Déploiement de Prometheus avec Helm

La méthode standard pour installer Prometheus sur kubeadm consiste à utiliser le chart Helm prometheus-community/kube-prometheus-stack. Il regroupe Prometheus, Alertmanager, Grafana et un ensemble d'exportateurs spécifiques à Kubernetes. Tout d'abord, ajoutez le dépôt :

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Créez un namespace dédié à la surveillance :

kubectl create namespace monitoring

Installez la pile avec des valeurs par défaut raisonnables, mais commencez par examiner les valeurs du chart. N'installez pas sans personnaliser la rétention et la taille du stockage, car les paramètres par défaut peuvent ne pas convenir à votre environnement. Créez un fichier values.yaml avec le contenu suivant :

prometheus:
  prometheusSpec:
    retention: 15d
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 20Gi

grafana:
  adminPassword: "admin"  # changez ceci dans un gestionnaire de secrets
alertmanager:
  config:
    global:
      resolve_timeout: 5m
    route:
      group_by: ['alertname']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      receiver: 'default-receiver'
    receivers:
      - name: 'default-receiver'
        email_configs:
          - to: '[email protected]'
            from: '[email protected]'
            smarthost: 'smtp.example.com:587'
            auth_username: '[email protected]'
            auth_password: 'SMTP_PASSWORD'

Remplacez les paramètres d'e-mail et SMTP par les vôtres. Ne stockez jamais de mots de passe en clair dans les fichiers de valeurs ; utilisez des secrets Kubernetes ou un outil de gestion des secrets. Pour ce guide, nous définirons temporairement adminPassword sur admin, mais vous devez le modifier immédiatement après l'installation.

Installez le chart :

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --values values.yaml

Vérifiez que les pods sont en cours d'exécution :

kubectl get pods -n monitoring

Sortie attendue (les noms peuvent varier légèrement) :

NAME                                                     READY   STATUS    RESTARTS   AGE
alertmanager-monitoring-kube-prometheus-alertmanager-0   2/2     Running   0          2m
monitoring-grafana-7c9c8b7d9b-xyz12                      2/2     Running   0          2m
monitoring-kube-prometheus-operator-6f9f8b7c9d-abc34     1/1     Running   0          2m
monitoring-kube-state-metrics-7b8c9d8f6f-def56           1/1     Running   0          2m
monitoring-prometheus-node-exporter-9g8h7f6d5e-ghi78    1/1     Running   0          2m
monitoring-prometheus-monitoring-kube-prometheus-0      2/2     Running   0          2m

Si un pod est en CrashLoopBackOff, consultez les journaux avec kubectl logs -n monitoring <nom-du-pod> et assurez-vous que le PVC pour Prometheus a été créé avec succès (kubectl get pvc -n monitoring).

Configuration des règles d'alerte

Le kube-prometheus-stack inclut des règles d'alerte par défaut, mais vous devez ajouter les vôtres pour la santé du cluster. Créez une PrometheusRule personnalisée. Par exemple, une alerte pour une utilisation élevée du processeur des nœuds :

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: custom-node-alerts
  namespace: monitoring
  labels:
    release: monitoring
spec:
  groups:
    - name: node-health
      rules:
        - alert: NodeHighCPUUsage
          expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Utilisation élevée du processeur sur {{ $labels.instance }}"
            description: "L'utilisation du processeur a dépassé 80 % pendant 10 minutes (valeur actuelle : {{ $value }}%)."

Appliquez cette règle :

kubectl apply -f custom-node-alerts.yaml

Vérifiez que la règle a été chargée en interrogeant l'API Prometheus. Faites un port-forward vers Prometheus :

kubectl port-forward -n monitoring svc/monitoring-kube-prometheus-prometheus 9090:9090

Dans un autre terminal, interrogez la règle :

curl -s http://localhost:9090/api/v1/rules | jq '.data.groups[] | select(.name=="node-health")'

La règle doit apparaître avec son nom et son expression. Sinon, vérifiez les journaux de Prometheus pour détecter les erreurs de configuration.

Test des alertes et du routage Alertmanager

Pour vérifier que les alertes atteignent réellement votre canal de notification, utilisez l'interface utilisateur d'Alertmanager ou l'API pour envoyer une alerte de test. Tout d'abord, accédez à Alertmanager :

kubectl port-forward -n monitoring svc/monitoring-kube-prometheus-alertmanager 9093:9093

Ouvrez http://localhost:9093 et cliquez sur « Nouveau silence » ou utilisez l'API pour publier une alerte de test. Vous pouvez également générer une charge sur un nœud pour déclencher l'alerte CPU. Par exemple, exécutez un conteneur de stress sur un nœud (attention : il s'agit d'une intervention réelle) :

kubectl run stress --image=polinux/stress --restart=Never --command -- stress --cpu 2 --timeout 600s

Après quelques minutes, l'alerte doit passer à l'état Pending puis Firing. Consultez la page des alertes de Prometheus à l'adresse http://localhost:9090/alerts ou interrogez l'API :

curl -s http://localhost:9090/api/v1/alerts | jq '.data.alerts[] | select(.labels.alertname=="NodeHighCPUUsage")'

La réponse attendue inclut une alerte avec "state": "firing". Sinon, vérifiez que l'expression de l'alerte renvoie des données en utilisant l'interface de requête de Prometheus. Une fois confirmé, supprimez le pod de stress :

kubectl delete pod stress

Une fois l'alerte résolue, vous devriez recevoir une notification de résolution conformément à la route d'Alertmanager (après repeat_interval).

Création de tableaux de bord avec Grafana

Grafana est inclus dans la pile et préconfiguré avec des tableaux de bord pour Kubernetes. Accédez à Grafana :

kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80

Ouvrez http://localhost:3000 et connectez-vous avec admin et le mot de passe du fichier values.yaml. Les tableaux de bord par défaut incluent « Kubernetes / Nœuds » et « Kubernetes / Ressources de calcul / Pod ». Ils vous offrent une visibilité immédiate sur les métriques des nœuds et des pods.

Pour créer un tableau de bord personnalisé pour une charge de travail spécifique, utilisez des requêtes Prometheus. Par exemple, pour suivre le taux de requêtes d'un déploiement, ajoutez un panneau avec la requête :

sum(rate(container_cpu_usage_seconds_total{namespace="default", pod=~"my-app-.*"}[5m])) by (pod)

Réglez le panneau pour qu'il se rafraîchisse toutes les 30 secondes et utilisez un graphique en série temporelle. Cela vous donne une vue en direct de l'utilisation du processeur par pod.

Les tableaux de bord sont également utiles pour la réponse aux incidents : lorsque vous recevez une alerte, ouvrez le tableau de bord pertinent et comparez les métriques actuelles avec la base de référence pour identifier ce qui a changé.

Pièges courants et comment les éviter

1. Ignorer les paramètres de rétention et de stockage. L'installation par défaut de Prometheus peut utiliser un petit volume emptyDir, ce qui signifie que les données sont perdues lorsque le pod redémarre. Cela rend l'analyse historique impossible. Pourquoi cela arrive : les utilisateurs acceptent les valeurs par défaut sans les examiner. Comment l'éviter : définissez toujours une revendication de volume persistant (comme indiqué dans le values.yaml) et une période de rétention adaptée à vos besoins opérationnels. Pour la plupart des clusters, 15 jours est un bon point de départ. Récupération : si vous avez déjà installé sans persistance, réinstallez avec les paramètres de stockage corrects après avoir sauvegardé les configurations importantes.

2. Fatigue liée aux alertes due à un trop grand nombre d'alertes de faible gravité. Si chaque petit incident déclenche une page, l'équipe commence à ignorer les alertes. Cela va à l'encontre de l'objectif. Pourquoi cela arrive : les règles par défaut ne sont souvent pas adaptées à votre environnement ; les seuils peuvent être trop bas ou les durées for trop courtes. Comment l'éviter : examinez les règles par défaut et désactivez ou ajustez celles qui sont bruyantes. Utilisez des étiquettes de gravité et n'acheminez que les alertes critiques vers la messagerie immédiate. Définissez repeat_interval de manière appropriée (par exemple, 4 heures) pour éviter les notifications en double. Récupération : ajustez les expressions d'alerte en fonction des métriques de base sur une semaine. Augmentez les seuils ou la durée for pour filtrer les pics transitoires.

3. Prometheus et Alertmanager inaccessibles en raison de politiques réseau ou de mauvaises configurations de service. Pourquoi cela arrive : dans kubeadm, les politiques réseau par défaut ne sont pas installées, mais si vous les ajoutez plus tard, elles peuvent bloquer le trafic vers les composants de surveillance. De plus, le port-forwarding peut échouer si le sélecteur de service est incorrect. Comment l'éviter : testez l'accès immédiatement après l'installation. Utilisez kubectl describe svc -n monitoring pour vérifier que les endpoints sont peuplés. Récupération : si les endpoints sont vides, vérifiez que le sélecteur de service correspond aux étiquettes des pods. Pour les politiques réseau, créez des politiques autorisant le trafic entrant depuis le namespace de surveillance vers les ports pertinents.

4. Stockage de secrets en clair dans les valeurs Helm ou les fichiers de configuration. Pourquoi cela arrive : par commodité. Les développeurs placent souvent les mots de passe SMTP, les mots de passe admin Grafana ou les jetons API directement dans des fichiers qui sont versionnés. Comment l'éviter : utilisez des secrets Kubernetes et référencez-les dans le chart. Par exemple, créez un secret pour le mot de passe SMTP d'Alertmanager et utilisez existingSecret dans les valeurs. Pour Grafana, utilisez admin.existingSecret. Récupération : si des secrets sont divulgués, faites-les pivoter immédiatement. Supprimez-les du contrôle de version, forcez le push pour nettoyer l'historique et mettez à jour le secret dans le cluster.

5. Ne pas tester les procédures de récupération. Avoir une alerte ne suffit pas ; vous devez savoir quoi faire lorsqu'elle se déclenche. Les équipes paniquent souvent lors d'un incident parce qu'elles n'ont jamais répété. Pourquoi cela arrive : la surveillance est traitée comme un système à configurer et à oublier. Comment l'éviter : planifiez des exercices réguliers : choisissez une alerte à faible risque, déclenchez-la intentionnellement (comme le test de stress ci-dessus) et suivez la réponse. Documentez les étapes dans un runbook. Récupération : si vous constatez des lacunes lors d'un exercice, mettez à jour le runbook et attribuez un propriétaire pour résoudre le problème. Le propriétaire doit être un ingénieur nommé, par exemple « Priya Shah, ingénieure DevOps », et l'examen doit avoir lieu tous les trimestres.

Liste de contrôle opérationnelle et responsabilités

Voici une liste de contrôle pour la mise en place et la maintenance de la surveillance kubeadm. Chaque élément a un propriétaire et une fréquence d'examen.

Pour chaque élément, le propriétaire est une personne nommée, pas une équipe. Le propriétaire est responsable du résultat et de l'escalade s'il ne peut pas terminer la tâche. Réexaminez la liste de contrôle elle-même tous les six mois pour vous assurer qu'elle correspond à la réalité du cluster.

Modes de défaillance et récupération

Le pod Prometheus redémarre en boucle en raison d'un stockage corrompu. Symptôme : Prometheus est en CrashLoopBackOff. Les journaux affichent des erreurs telles que opening storage failed ou corrupt TSDB. Récupération : tout d'abord, réduisez Prometheus pour empêcher d'autres écritures : kubectl scale statefulset -n monitoring monitoring-kube-prometheus-prometheus --replicas=0. Ensuite, inspectez le stockage. Si vous utilisez un PVC, vous pouvez attacher un pod de débogage au volume. Si les données sont corrompues et inutiles, supprimez le PVC et recréez-le. Si les données sont nécessaires, utilisez promtool tsdb pour tenter une réparation. Restaurez à partir d'une sauvegarde si disponible. Après réparation, remettez à l'échelle et vérifiez avec kubectl get pods -n monitoring.

Alertmanager ne parvient pas à envoyer des notifications. Symptôme : les alertes se déclenchent mais aucune notification n'est reçue. Les journaux d'Alertmanager affichent des erreurs SMTP. Récupération : vérifiez la configuration d'Alertmanager : kubectl get secret -n monitoring alertmanager-monitoring-kube-prometheus-alertmanager -o jsonpath='{.data.alertmanager\.yaml}' | base64 --decode. Validez les paramètres SMTP. Testez la connectivité SMTP depuis le cluster à l'aide d'un pod de débogage avec nc -vz smtp.example.com 587. Corrigez les informations d'identification dans le secret et redémarrez Alertmanager.

Le tableau de bord Grafana n'affiche aucune donnée. Symptôme : les panneaux affichent « Aucune donnée » alors que les métriques existent. Récupération : vérifiez la configuration de la source de données Grafana. Dans Grafana, allez dans Configuration > Sources de données et testez la connexion Prometheus. Si elle échoue, vérifiez que le service monitoring-kube-prometheus-prometheus est accessible depuis le pod Grafana. Vérifiez les politiques réseau. Assurez-vous également que la plage temporelle du tableau de bord est appropriée.

Les alertes ne se déclenchent pas en raison d'étiquettes manquantes. Symptôme : vous avez créé une PrometheusRule, mais elle n'apparaît pas dans les alertes Prometheus. Récupération : vérifiez que la règle a été prise en compte : kubectl get prometheusrule -n monitoring. Si elle existe, vérifiez la configuration de Prometheus : kubectl describe prometheus -n monitoring monitoring-kube-prometheus-prometheus. Recherchez le sélecteur de règles. La règle doit avoir des étiquettes correspondant au sélecteur (dans notre chart, l'étiquette release: monitoring est requise). Si elle est manquante, ajoutez l'étiquette et réappliquez.

L'exportateur de nœuds ne collecte pas de métriques. Symptôme : aucune métrique au niveau des nœuds dans Prometheus. Récupération : vérifiez le daemonset de l'exportateur de nœuds : kubectl get ds -n monitoring monitoring-prometheus-node-exporter. Si les pods ne fonctionnent pas sur tous les nœuds, inspectez les journaux. Les problèmes courants incluent des problèmes de montage hostPath ou des contraintes de ressources. Ajustez les demandes de ressources si nécessaire. Assurez-vous que le service monitoring-prometheus-node-exporter est présent et que Prometheus le scrape : interrogez Prometheus pour up{job="node-exporter"} ; si up vaut 0, vérifiez la cible de scrape.

Conclusion

Une surveillance kubeadm efficace est un processus continu, pas une configuration unique. En suivant les étapes de ce guide, vous avez déployé une pile de surveillance robuste, configuré des alertes pertinentes, créé des tableaux de bord et vous êtes préparé aux modes de défaillance courants. La clé est de traiter la surveillance comme du code : versionnez vos configurations, examinez régulièrement les règles d'alerte et pratiquez la réponse aux incidents.

Commencez petit : installez la pile, vérifiez les tableaux de bord par défaut et créez une alerte personnalisée. Ensuite, ajustez progressivement les seuils et ajoutez d'autres règles. Attribuez des responsabilités claires pour les tâches de surveillance et examinez le système mensuellement. Avec cette base, votre cluster kubeadm sera plus observable, gérable et résilient.