## 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 ``, ``) 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 : ```bash kubectl version --short kubeadm version -o short kubectl get nodes -o wide ``` Sortie attendue pour la première commande sur un cluster typique : ```text 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 : ```bash helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update ``` Créez un namespace dédié à la surveillance : ```bash 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 : ```yaml 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: 'ops-team@example.com' from: 'alertmanager@example.com' smarthost: 'smtp.example.com:587' auth_username: 'alertmanager@example.com' 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 : ```bash helm install monitoring prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --values values.yaml ``` Vérifiez que les pods sont en cours d'exécution : ```bash kubectl get pods -n monitoring ``` Sortie attendue (les noms peuvent varier légèrement) : ```text 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 ` 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 : ```yaml 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 : ```bash 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 : ```bash kubectl port-forward -n monitoring svc/monitoring-kube-prometheus-prometheus 9090:9090 ``` Dans un autre terminal, interrogez la règle : ```bash 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 : ```bash 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) : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```promql 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. | Élément | Propriétaire (rôle spécifique) | Fréquence | Commande de vérification | |---------|--------------------------------|-----------|--------------------------| | Examiner la rétention et le stockage de Prometheus | Ingénieur plateforme (ex. : Alex Chen) | Mensuel | `kubectl get pvc -n monitoring` et `kubectl describe statefulset -n monitoring monitoring-kube-prometheus-prometheus` | | Valider que toutes les règles d'alerte se chargent et se déclenchent correctement | Responsable SRE (ex. : Maria Garcia) | Hebdomadaire | `curl -s http://localhost:9090/api/v1/rules \| jq '.data.groups[] \| .rules[] \| select(.health!="ok")'` | | Tester les canaux de notification (e-mail, Slack, etc.) | Ingénieur d'astreinte (rotation) | Mensuel | Envoyer une alerte de test via l'interface ou l'API d'Alertmanager, vérifier la réception | | Examiner la pertinence et l'utilisation des tableaux de bord | Propriétaire produit pour l'observabilité (ex. : John Doe) | Trimestriel | Vérifier la liste des tableaux de bord Grafana, l'horodatage du dernier accès via l'API | | Mettre à jour la version de la pile de surveillance | Ingénieur plateforme (Alex Chen) | Trimestriel | `helm list -n monitoring` et comparer avec la dernière version du chart, puis planifier la mise à niveau | | Examiner les seuils d'alerte par rapport à la base de référence sur 24 heures | Responsable SRE (Maria Garcia) | Mensuel | Extraire les données Prometheus des dernières 24 heures et comparer les valeurs maximales | 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.