Déployer la stack kube-prometheus complète en environnement de production

Déployer la stack kube-prometheus en production constitue une étape stratégique pour toute équipe gérant des clusters Kubernetes.

Avec 75% des organisations utilisant Prometheus et Grafana pour le monitoring Kubernetes selon Grafana Labs, cette stack s'impose comme le standard de facto. Ce guide détaille l'installation, la configuration avancée et les bonnes pratiques pour un déploiement production-ready.

TL;DR : La stack kube-prometheus combine Prometheus Operator, Grafana, Alertmanager et des dashboards préconfigurés. Elle automatise le monitoring complet d'un cluster Kubernetes avec moins de 30 minutes de configuration initiale.

L'administrateur système ou l'ingénieur infrastructure préparant une formation LFS458 Administration Kubernetes maîtrisera ces compétences dans le programme LFS458.

Qu'est-ce que la stack kube-prometheus ?

La stack kube-prometheus est un ensemble intégré de composants open source pour le monitoring Kubernetes. Elle comprend Prometheus Operator, Prometheus Server, Alertmanager, Grafana, node-exporter et kube-state-metrics. Cette stack collecte, stocke, visualise et alerte sur les métriques de votre cluster.

Composants principaux :

À retenir : La stack kube-prometheus utilise des Custom Resource Definitions (CRDs) pour gérer Prometheus de manière native Kubernetes.

Le Monitoring et dépannage Kubernetes approfondit les concepts d'observabilité.

Pourquoi déployer la stack kube-prometheus en production ?

Avantages par rapport à une installation manuelle

Déployer la stack kube-prometheus offre plusieurs bénéfices :

• Configuration automatisée : ServiceMonitors et PodMonitors détectent automatiquement les cibles
• Haute disponibilité : configuration native multi-replicas
• Dashboards préconfigurés : 20+ dashboards Grafana prêts à l'emploi
• Alertes standards : règles d'alerte couvrant les incidents courants

Selon le CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. Ces environnements nécessitent un monitoring robuste.

Cas d'usage production

Scénarios couverts nativement :

1. Monitoring de la santé des nodes et pods
2. Alerting sur les ressources critiques (CPU, mémoire, disque)
3. Analyse de la performance applicative
4. Détection des anomalies de scheduling
5. Suivi des métriques business exposées par vos applications

Les équipes IT passent en moyenne 34 jours ouvrés par an à résoudre des problèmes Kubernetes selon Cloud Native Now. Un monitoring efficace réduit ce temps de 40 à 60%.

Comment préparer le déploiement de la stack kube-prometheus ?

Prérequis techniques

Avant de déployer la stack kube-prometheus, validez ces éléments :

# Version Kubernetes minimale
kubectl version --short
# Requiert : v1.25+

# Vérifier les ressources disponibles
kubectl top nodes
# Recommandé : 4 vCPU et 8 Go RAM disponibles

# Vérifier Helm
helm version
# Requiert : v3.10+

Dimensionnement production

À retenir : Prévoyez 1 à 2 Mo de stockage par série temporelle par jour. Un cluster de 100 pods génère environ 10 000 séries.

Namespace et RBAC

# namespace-monitoring.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: monitoring
  labels:
    name: monitoring
    pod-security.kubernetes.io/enforce: privileged

kubectl apply -f namespace-monitoring.yaml

Le privilège privileged est requis pour node-exporter qui accède aux métriques système.

Comment déployer la stack kube-prometheus avec Helm ?

Installation via kube-prometheus-stack

Le chart Helm kube-prometheus-stack simplifie le déploiement complet.

# Ajouter le repository Prometheus Community
helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts
helm repo update

# Déployer la stack
helm install kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --version 65.0.0 \
  --values production-values.yaml

Configuration production recommandée

Créez un fichier production-values.yaml :

# production-values.yaml
prometheus:
  prometheusSpec:
    retention: 15d
    retentionSize: "90GB"
    resources:
      requests:
        cpu: "500m"
        memory: "2Gi"
      limits:
        cpu: "2000m"
        memory: "8Gi"
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: standard-ssd
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 100Gi
    replicas: 2
    podAntiAffinity: hard

alertmanager:
  alertmanagerSpec:
    replicas: 3
    resources:
      requests:
        cpu: "100m"
        memory: "256Mi"
    storage:
      volumeClaimTemplate:
        spec:
          storageClassName: standard-ssd
          resources:
            requests:
              storage: 10Gi

grafana:
  replicas: 2
  persistence:
    enabled: true
    size: 10Gi
  adminPassword: "${GRAFANA_ADMIN_PASSWORD}"
  resources:
    requests:
      cpu: "250m"
      memory: "512Mi"

nodeExporter:
  resources:
    requests:
      cpu: "50m"
      memory: "64Mi"

Vérification du déploiement

# Vérifier les pods
kubectl get pods -n monitoring

# Sortie attendue :
# alertmanager-kube-prometheus-alertmanager-0   2/2     Running
# kube-prometheus-grafana-xxx                   3/3     Running
# kube-prometheus-kube-state-metrics-xxx        1/1     Running
# kube-prometheus-operator-xxx                  1/1     Running
# kube-prometheus-prometheus-node-exporter-xxx  1/1     Running
# prometheus-kube-prometheus-prometheus-0       2/2     Running

# Vérifier les CRDs installées
kubectl get crd | grep monitoring.coreos.com

À retenir : Les CRDs Prometheus (ServiceMonitor, PodMonitor, PrometheusRule) permettent de configurer le monitoring de manière déclarative.

Comment configurer déployer la stack kube-prometheus pour la haute disponibilité ?

Architecture multi-replicas

Pour un déploiement production, activez la haute disponibilité :

# ha-config.yaml
prometheus:
  prometheusSpec:
    replicas: 2
    podAntiAffinity: hard
    # Sharding pour très grands clusters
    # shards: 2

alertmanager:
  alertmanagerSpec:
    replicas: 3
    # Clustering automatique entre replicas
    clusterAdvertiseAddress: false

Configuration du stockage persistant

StorageClass recommandée pour la production :

# storageclass-prometheus.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: prometheus-ssd
provisioner: kubernetes.io/gce-pd  # Adapter selon cloud provider
parameters:
  type: pd-ssd
  replication-type: regional-pd
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Les bonnes pratiques de stockage s'appliquent au monitoring.

Network Policies production

# networkpolicy-prometheus.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: prometheus-ingress
  namespace: monitoring
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: prometheus
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              monitoring-access: "true"
      ports:
        - protocol: TCP
          port: 9090
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: grafana
      ports:
        - protocol: TCP
          port: 9090

Comment configurer les ServiceMonitors pour vos applications ?

Créer un ServiceMonitor

Un ServiceMonitor est une CRD qui configure automatiquement Prometheus pour scraper les métriques d'un Service.

# servicemonitor-myapp.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-metrics
  namespace: monitoring
  labels:
    release: kube-prometheus
spec:
  selector:
    matchLabels:
      app: myapp
  namespaceSelector:
    matchNames:
      - production
  endpoints:
    - port: metrics
      interval: 30s
      path: /metrics
      scheme: http
      tlsConfig:
        insecureSkipVerify: false
      relabelings:
        - sourceLabels: [__meta_kubernetes_pod_name]
          targetLabel: pod

PodMonitor pour les pods sans Service

# podmonitor-batch-jobs.yaml
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: batch-jobs
  namespace: monitoring
spec:
  selector:
    matchLabels:
      type: batch-job
  podMetricsEndpoints:
    - port: metrics
      interval: 60s

Vérifier la découverte des cibles

# Port-forward vers Prometheus
kubectl port-forward -n monitoring \
  svc/kube-prometheus-prometheus 9090:9090

# Accéder à http://localhost:9090/targets
# Vérifier que vos ServiceMonitors apparaissent

Le guide d'installation Prometheus détaille ces configurations.

Comment configurer Alertmanager en production ?

Configuration des routes d'alertes

# alertmanager-config.yaml
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
  name: production-alerts
  namespace: monitoring
spec:
  route:
    groupBy: ['alertname', 'cluster', 'service']
    groupWait: 30s
    groupInterval: 5m
    repeatInterval: 4h
    receiver: 'default-receiver'
    routes:
      - matchers:
          - name: severity
            value: critical
        receiver: 'pagerduty-critical'
        continue: true
      - matchers:
          - name: severity
            value: warning
        receiver: 'slack-warnings'
  receivers:
    - name: 'default-receiver'
      slackConfigs:
        - apiURL:
            name: slack-webhook
            key: url
          channel: '#alerts-default'
    - name: 'pagerduty-critical'
      pagerdutyConfigs:
        - routingKey:
            name: pagerduty-key
            key: routing-key
          severity: critical
    - name: 'slack-warnings'
      slackConfigs:
        - apiURL:
            name: slack-webhook
            key: url
          channel: '#alerts-warnings'

Règles d'alerte personnalisées

# prometheusrule-custom.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: custom-alerts
  namespace: monitoring
  labels:
    release: kube-prometheus
spec:
  groups:
    - name: kubernetes-apps
      rules:
        - alert: PodCrashLooping
          expr: |
            rate(kube_pod_container_status_restarts_total[15m]) * 60 * 5 > 0
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping"
            description: "Pod has restarted {{ $value }} times in the last 15 minutes"
        
        - alert: PodNotReady
          expr: |
            kube_pod_status_ready{condition="true"} == 0
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is not ready"

Le debugging de pods CrashLoopBackOff complète ces alertes.

Comment optimiser Grafana pour la production ?

Dashboards essentiels

La stack inclut des dashboards préconfigurés. Dashboards prioritaires à activer :

1. Kubernetes / Compute Resources / Cluster : vue globale
2. Kubernetes / Compute Resources / Namespace (Pods) : détail par namespace
3. Node Exporter Full : métriques système détaillées
4. Prometheus Stats : santé de Prometheus lui-même

Configuration SSO et RBAC

# grafana-values.yaml
grafana:
  grafana.ini:
    server:
      root_url: https://grafana.example.com
    auth.generic_oauth:
      enabled: true
      name: Corporate SSO
      allow_sign_up: true
      client_id: ${OAUTH_CLIENT_ID}
      client_secret: ${OAUTH_CLIENT_SECRET}
      scopes: openid profile email
      auth_url: https://sso.example.com/authorize
      token_url: https://sso.example.com/token
      api_url: https://sso.example.com/userinfo
    users:
      auto_assign_org_role: Viewer

À retenir : Limitez l'accès Editor aux équipes SRE et Admin aux platform engineers.

Provisioning automatique des dashboards

# dashboards-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-dashboards-custom
  namespace: monitoring
  labels:
    grafana_dashboard: "1"
data:
  custom-overview.json: |
    {
      "dashboard": {
        "title": "Custom Overview",
        "panels": [...]
      }
    }

Comment diagnostiquer les problèmes de la stack kube-prometheus ?

Problèmes courants et solutions

Prometheus ne scrape pas les cibles :

# Vérifier les ServiceMonitors
kubectl get servicemonitor -n monitoring

# Vérifier les labels de sélection
kubectl describe servicemonitor myapp-metrics -n monitoring

# Logs Prometheus Operator
kubectl logs -n monitoring -l app.kubernetes.io/name=prometheus-operator

Alertmanager ne route pas les alertes :

# Vérifier la configuration
kubectl exec -n monitoring alertmanager-kube-prometheus-alertmanager-0 \
  -- amtool config show

# Tester une alerte
kubectl exec -n monitoring alertmanager-kube-prometheus-alertmanager-0 \
  -- amtool alert add test severity=warning

Le diagnostic réseau Kubernetes aide à résoudre les problèmes de connectivité.

Métriques de santé à surveiller

# Santé de Prometheus
up{job="prometheus"}

# Taux d'erreur de scrape
sum(rate(prometheus_target_scrape_sample_failed_total[5m])) by (job)

# Utilisation mémoire Prometheus
process_resident_memory_bytes{job="prometheus"}

# Latence des requêtes
histogram_quantile(0.99, rate(prometheus_http_request_duration_seconds_bucket[5m]))

L'architecture monitoring production détaille ces patterns.

Comment mettre à jour la stack kube-prometheus ?

Processus de mise à jour

# Vérifier les versions disponibles
helm search repo prometheus-community/kube-prometheus-stack --versions

# Backup des configurations
kubectl get prometheusrule -n monitoring -o yaml > backup-rules.yaml
kubectl get servicemonitor -n monitoring -o yaml > backup-servicemonitors.yaml

# Mise à jour avec diff
helm diff upgrade kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --version 66.0.0 \
  --values production-values.yaml

# Appliquer la mise à jour
helm upgrade kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --version 66.0.0 \
  --values production-values.yaml

Points de vigilance

• CRD updates : les CRDs doivent parfois être mises à jour manuellement
• Breaking changes : consulter le CHANGELOG entre versions
• Rétention des données : les données Prometheus sont préservées si le PVC est conservé

À retenir : Testez toujours les mises à jour sur un cluster de staging avant la production.

L'observabilité Kubernetes contextualise ces pratiques.

Synthèse : checklist production pour kube-prometheus

Avant mise en production, validez :

• [ ] Stockage persistant configuré avec rétention adaptée
• [ ] Replicas HA pour Prometheus (2+) et Alertmanager (3+)
• [ ] Network Policies restrictives appliquées
• [ ] Routes d'alertes testées end-to-end
• [ ] Dashboards personnalisés provisionnés
• [ ] SSO et RBAC Grafana configurés
• [ ] Backup des configurations automatisé
• [ ] Runbooks documentés pour chaque alerte critique

Maîtrisez le monitoring Kubernetes en production

Vous souhaitez approfondir vos compétences en monitoring et administration Kubernetes ?

L'ingénieur infrastructure préparant une formation LFS458 Administration Kubernetes bénéficie d'un programme complet couvrant l'observabilité production.

Formations SFEIR Institute recommandées :

• LFS458 Administration Kubernetes : 4 jours incluant monitoring et troubleshooting avancé
• LFD459 Kubernetes pour développeurs : 3 jours avec focus observabilité applicative
• Kubernetes les fondamentaux : 1 jour pour découvrir les concepts essentiels

Contactez nos conseillers pour obtenir des informations sur les prochaines sessions et modalités de financement.