Observabilité Kubernetes : signaux clés et pièges à éviter

Kubernetes génère des centaines de métriques par pod, par node, par composant du control plane. Sans stratégie, vous collectez tout, stockez tout, et ne comprenez rien. Ce guide vous apprend à identifier les signaux clés qui révèlent les vrais problèmes (OOMKilled, pending pods, restarts excessifs, nodes not ready), à distinguer les 3 sources de métriques (kube-state-metrics, cAdvisor, kubelet), et à éviter les pièges qui font exploser votre cardinalité et vos coûts. À la fin, vous saurez configurer un monitoring Kubernetes efficace qui détecte les vrais problèmes sans noyer votre Prometheus.

TL;DR

Kubernetes expose des métriques à 4 couches : application, conteneur, node, control plane. Utilisez kube-state-metrics pour l’état des objets K8s (pods pending, replicas, OOMKilled), cAdvisor pour la consommation ressource des conteneurs, et les métriques kubelet pour la santé des nodes. Les labels K8s dynamiques (pod, revision, uid) explosent la cardinalité : filtrez-les dès le scraping. Surveillez 5 signaux critiques : OOMKilled, pod restarts, pending pods, node not ready, et CPU throttling.

Ce que vous allez apprendre

• Les 4 couches d’observabilité K8s : application, conteneur, node, control plane — et pourquoi vous devez couvrir chacune
• Les 3 sources de métriques : kube-state-metrics, cAdvisor, kubelet — leur rôle, ce qu’elles exposent, comment les scraper proprement
• Les 5 signaux clés : OOMKilled, pod restarts, pending pods, node not ready, CPU throttling — les métriques exactes et les requêtes PromQL
• Les logs Kubernetes : stdout/stderr des pods, logs du control plane, pièges de volumétrie
• Le piège de la cardinalité : pourquoi les labels K8s font exploser Prometheus et comment s’en protéger
• Les noisy neighbors : détecter et isoler les workloads qui surconsomment les ressources partagées
• Les alertes essentielles : 8 alertes production-ready pour un cluster K8s minimal
• Les anti-patterns : les erreurs classiques qui rendent votre monitoring inutile ou ruineux

Les 4 couches d’observabilité Kubernetes

Dans Kubernetes, les métriques viennent de 4 couches différentes. Chaque couche répond à des questions distinctes, et manquer l’une d’elles crée des angles morts.

Couche	Ce qu’elle mesure	Exemples de questions
Application	Le comportement métier de votre code	Combien de requêtes ? Quel taux d’erreur ? Quelle latence ?
Conteneur	La consommation ressource de chaque conteneur	Combien de CPU/mémoire utilisés ? Des OOM ? Du throttling ?
Node	La santé de la machine hôte	Disque plein ? Réseau saturé ? Kernel panics ?
Control plane	Le fonctionnement de Kubernetes lui-même	L’API server répond-il ? Le scheduler place-t-il les pods ? etcd est-il sain ?

Glissez pour voir

Application = votre responsabilité

Kubernetes ne connaît pas votre application. Les métriques RED (Request rate, Error rate, Duration) ou les métriques métier (commandes passées, utilisateurs connectés) doivent être exposées par votre code. Les couches conteneur/node/control plane sont fournies par l’infrastructure — la couche application, c’est à vous de l’instrumenter.

Les 3 sources de métriques Kubernetes

Kubernetes expose ses métriques via 3 composants distincts. Chacun a un rôle différent — les confondre mène à des dashboards redondants ou incomplets.

kube-state-metrics : l’état des objets K8s

kube-state-metrics (KSM) écoute l’API server Kubernetes et convertit l’état des objets (pods, deployments, nodes, etc.) en métriques Prometheus.

Ce qu’il expose	Ce qu’il ne fait pas
Nombre de pods pending, running, failed	Consommation CPU/mémoire des conteneurs
Nombre de replicas désiré vs actuel	Métriques du node hôte
Raison du dernier redémarrage (OOMKilled, Error, etc.)	Métriques de l’application
État des PVC (bound, pending)	Latence réseau
Labels et annotations des objets K8s	Logs

Glissez pour voir

Exemples de métriques :

• kube_pod_status_phase{phase="Pending"} — pods en attente de scheduling
• kube_pod_container_status_restarts_total — compteur de redémarrages
• kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} — OOM
• kube_deployment_status_replicas_unavailable — replicas manquants

Installation : déployez kube-state-metrics dans le namespace kube-system (Helm chart officiel) et configurez Prometheus pour scraper le service.

cAdvisor : la consommation ressource des conteneurs

cAdvisor (Container Advisor) est intégré au kubelet. Il mesure la consommation réelle de chaque conteneur : CPU, mémoire, réseau, I/O disque.

Ce qu’il expose	Ce qu’il ne fait pas
CPU utilisé par conteneur (container_cpu_usage_seconds_total)	État des objets K8s (replicas, pending)
Mémoire utilisée (container_memory_usage_bytes)	Raison des redémarrages
I/O disque (container_fs_reads_bytes_total)	Métriques du control plane
Réseau par pod (container_network_receive_bytes_total)	Métriques applicatives

Glissez pour voir

Exemples de métriques :

• container_cpu_usage_seconds_total — CPU utilisé (cumulatif)
• container_memory_working_set_bytes — mémoire effective (hors cache)
• container_cpu_cfs_throttled_seconds_total — temps passé en throttling CPU

working_set vs usage

container_memory_usage_bytes inclut le cache fichier, ce qui donne des valeurs gonflées. container_memory_working_set_bytes est souvent plus représentatif de la mémoire réellement utilisée par le processus. Utilisez working_set pour piloter le dimensionnement de vos requests/limits et anticiper les OOM.

Note : un OOMKilled survient quand le conteneur dépasse sa limite mémoire (cgroup). working_set est un bon proxy pour prévoir ce seuil, mais ce n’est pas “la base de décision” du kernel.

Métriques kubelet : la santé des nodes

Le kubelet expose ses propres métriques sur le fonctionnement du node : opérations de pod lifecycle, stockage, runtime.

Ce qu’il expose	Ce qu’il ne fait pas
Latence des opérations pod (start, stop, sync)	Consommation applicative
Erreurs du runtime (CRI)	État des objets K8s
Espace disque disponible pour les pods	Métriques du control plane
Nombre de pods par node	Logs applicatifs

Glissez pour voir

Exemples de métriques :

• kubelet_pod_start_duration_seconds — temps de démarrage des pods
• kubelet_volume_stats_available_bytes — espace disponible par PVC
• kubelet_running_pods — pods actifs sur le node

Scraping en production : auth, TLS et ServiceMonitors

Les endpoints kubelet (/metrics, /metrics/cadvisor) tournent sur le port 10250 qui est sécurisé (TLS + authentification). En production, évitez le “scrape brut” d’IP nodes sans durcissement.

Scraping kubelet en production

En production, scrapez le kubelet via les ServiceMonitors ou PodMonitors de votre stack (kube-prometheus-stack, Prometheus Operator). Ces ressources gèrent automatiquement :

• Le RBAC (ClusterRole + binding pour les tokens de service account)
• Les certificats TLS (trust du CA cluster ou skip verify en interne)
• La découverte des endpoints via l’API Kubernetes

Sur les clusters managés (EKS, GKE, AKS), l’accès direct au kubelet peut être restreint — utilisez les intégrations du provider.

Tableau comparatif des 3 sources

Source	Déployé par	Endpoint typique	Cas d’usage principal
kube-state-metrics	Vous (Helm/manifest)	kube-state-metrics:8080/metrics	États K8s : pending, OOMKilled, replicas
cAdvisor	Intégré au kubelet	<node>:10250/metrics/cadvisor	Conso ressource : CPU, mémoire, I/O
kubelet	Kubernetes	<node>:10250/metrics	Santé node : pod lifecycle, volumes

Glissez pour voir

Les 5 signaux clés à surveiller

Ces 5 signaux couvrent 80 % des problèmes opérationnels Kubernetes. Chacun a une métrique précise, une requête PromQL, et une alerte recommandée.

1. OOMKilled — le conteneur manque de mémoire

Symptôme : le pod redémarre sans explication évidente, l’application perd ses sessions ou ses transactions en cours.

Métrique : kube_pod_container_status_last_terminated_reason{reason="OOMKilled"}

Requête PromQL (pods OOMKilled récemment — corrélation avec restarts) :

increase(kube_pod_container_status_restarts_total[15m]) > 0
and on (namespace, pod, container)
kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1

Pourquoi corréler avec les restarts ?

La métrique last_terminated_reason indique la raison du dernier arrêt. Si le conteneur a été OOMKilled il y a 3 jours et tourne depuis, la métrique reste à 1 mais ce n’est plus un événement récent. En corrélant avec increase(restarts), on alerte uniquement sur les OOM récents.

Alerte :

- alert: ContainerOOMKilled
  expr: |
    increase(kube_pod_container_status_restarts_total[15m]) > 0
    and on (namespace, pod, container)
    kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1
  for: 0m
  labels:
    severity: warning
  annotations:
    summary: "Container {{ $labels.container }} in pod {{ $labels.pod }} was OOMKilled (recent)"

Actions :

1. Vérifier les requests/limits mémoire actuels vs consommation réelle
2. Investiguer les fuites mémoire (profiling, heap dumps)
3. Vérifier la configuration du GC (Java, Go, Node.js)
4. Augmenter les limits seulement si la consommation est légitime

OOMKilled ≠ scale-up automatique

OOMKilled signifie que le conteneur a dépassé sa limite mémoire. Le réflexe “augmenter les limits” est souvent correct, mais vérifiez d’abord s’il n’y a pas une fuite mémoire — sinon vous ne faites que retarder le problème.

2. Pod restarts — le cycle crash-restart

Symptôme : un pod redémarre en boucle (CrashLoopBackOff), l’application est instable.

Métrique : kube_pod_container_status_restarts_total

Requête PromQL (pods avec > 0 restart sur 15 min) :

rate(kube_pod_container_status_restarts_total[15m]) > 0

Alerte :

- alert: PodCrashLooping
  expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Pod {{ $labels.pod }} is crash looping"

Actions : examiner les logs (kubectl logs --previous), vérifier les probes (liveness/readiness mal configurées), examiner les exit codes.

3. Pending pods — le scheduler ne peut pas placer

Symptôme : les pods restent en Pending, les déploiements n’avancent pas, l’autoscaler ne scale pas.

Métrique : kube_pod_status_phase{phase="Pending"}

Requête PromQL (pods pending depuis > 5 min) :

sum by (namespace, pod) (kube_pod_status_phase{phase="Pending"}) > 0

Pending ≠ toujours scheduler bloqué

Un pod Pending peut être “normal” pendant un rollout (pull d’images, init containers, montage de volumes). L’alerte avec for: 5m filtre les pending transitoires.

Pour distinguer les vraies causes, examinez les Events du pod :

• FailedScheduling — ressources insuffisantes ou contraintes (affinity, taints)
• FailedMount — PVC non bound ou problème de stockage
• ImagePullBackOff — image introuvable ou auth échouée

kubectl describe pod <pod-name> -n <namespace> | grep -A10 Events

Alerte :

- alert: PodPendingTooLong
  expr: sum by (namespace, pod) (kube_pod_status_phase{phase="Pending"}) > 0
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Pod {{ $labels.pod }} is pending for more than 5 minutes"
    runbook_url: "https://example.com/runbooks/pod-pending"

Actions : examiner les events (kubectl describe pod), vérifier les ressources disponibles (CPU/mémoire du cluster), les contraintes (nodeSelector, affinity, taints/tolerations), les PVC (pending storage).

4. Node not ready — le node est défaillant

Symptôme : les pods sur ce node sont évacués, ils basculent sur d’autres nodes, la capacité du cluster diminue.

Métrique : kube_node_status_condition{condition="Ready",status="true"}

Requête PromQL (nodes not ready — version robuste avec agrégation) :

sum by (node) (kube_node_status_condition{condition="Ready",status="true"}) == 0

Pourquoi sum by (node) ?

Selon la façon dont les séries sont exposées, une série peut être absente plutôt que 0. En forçant l’agrégation avec sum by (node), vous obtenez bien 0 si la condition “Ready=true” n’est pas présente.

Alerte :

- alert: NodeNotReady
  expr: sum by (node) (kube_node_status_condition{condition="Ready",status="true"}) == 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "Node {{ $labels.node }} is not ready"

Actions : vérifier la connectivité réseau du node, l’état du kubelet (systemctl status kubelet), les ressources système (disque, mémoire), les logs kubelet (journalctl -u kubelet -f).

5. CPU throttling — le conteneur est limité

Symptôme : l’application est lente, la latence p99 augmente, mais l’utilisation CPU semble “normale”.

Métrique : container_cpu_cfs_throttled_seconds_total

Requête PromQL (% de temps passé en throttling — approximation opérationnelle) :

rate(container_cpu_cfs_throttled_seconds_total[5m])
  / (rate(container_cpu_usage_seconds_total[5m]) + 0.001) > 0.2

Ratio throttling : approximation opérationnelle

Ce ratio “temps throttled / temps CPU utilisé” est une approximation. Si disponibles dans votre setup, les métriques “périodes throttled / périodes totales” (container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total) sont plus stables. Le ratio ci-dessus reste un bon signal de détection.

Alerte :

- alert: ContainerCPUThrottling
  expr: |
    rate(container_cpu_cfs_throttled_seconds_total[5m])
      / (rate(container_cpu_usage_seconds_total[5m]) + 0.001) > 0.2
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Container {{ $labels.container }} is being CPU throttled"

Actions :

1. Vérifier les CPU limits actuels vs consommation réelle
2. Augmenter les limits CPU si le throttling est constant
3. Pour les workloads sensibles à la latence : envisager “requests only”

CPU limits : à utiliser avec discernement

Les CPU limits s’appuient sur le CFS quota du kernel Linux. Elles peuvent induire du throttling même quand le node a du CPU disponible. Certaines équipes choisissent de définir des requests CPU (pour le scheduling) mais pas de limits, pour des workloads sensibles à la latence.

En multi-tenant strict, les limits restent utiles pour éviter qu’un workload ne monopolise les ressources. C’est un trade-off à évaluer selon votre contexte.

Logs Kubernetes

Logs des pods : stdout/stderr

Dans Kubernetes, les logs applicatifs sont les flux stdout et stderr des conteneurs. Le kubelet les capture et les stocke sur le node.

Collecte : déployez un DaemonSet de collecteurs (Fluent Bit, Promtail, Vector) qui lit les fichiers /var/log/pods/ sur chaque node et les envoie vers Loki, Elasticsearch, ou votre backend de logs.

Pièges courants :

Piège	Conséquence	Solution
Logs trop volumineux	Stockage qui explose, coûts élevés	Filtrer à la source, échantillonner, définir des rétentions courtes
Logs non structurés	Recherche impossible, parsing fragile	Logger en JSON, définir un schéma standard
Pas de labels K8s	Impossible de corréler avec les métriques/traces	Enrichir avec pod, namespace, container au moment de la collecte

Glissez pour voir

Logs du control plane

Les composants du control plane (API server, scheduler, controller manager, etcd) écrivent leurs logs vers stdout — visibles via kubectl logs dans le namespace kube-system ou via journald sur les nodes master.

Composant	Logs utiles	Cas d’usage
kube-apiserver	Requêtes lentes, erreurs d’authentification, rate limiting	Debug RBAC, audit, perf API
kube-scheduler	Échecs de placement, raisons de pending	Comprendre pourquoi un pod ne se schedule pas
kube-controller-manager	Erreurs de reconciliation	Debug deployments, replicasets, jobs
etcd	Latences, compactions, élections leader	Diagnostic cluster instable

Glissez pour voir

Control plane géré vs self-hosted

Sur les clusters managés (EKS, GKE, AKS), vous n’avez souvent pas accès aux logs du control plane — ou seulement via un export vers votre observabilité (Cloud Logging, CloudWatch). Sur les clusters self-hosted, configurez la collecte explicitement.

Le piège de la cardinalité

Kubernetes génère des labels dynamiques : pod, container, uid, revision, node. Ces labels changent à chaque déploiement, chaque restart, chaque scale. Le résultat : votre cardinalité explose.

Le problème

Prometheus stocke chaque combinaison unique de metric + labels comme une time series. Le nombre de séries = produit du nombre de valeurs de chaque label.

Exemple catastrophique :

container_cpu_usage_seconds_total{
  namespace="production",
  pod="payment-api-abc123",
  container="payment",
  node="node-1"
}

Avec 50 pods × 20 conteneurs × 10 nodes × rolling updates fréquents, vous atteignez rapidement des millions de séries — et Prometheus s’effondre.

Les labels dangereux

Label	Cardinalité typique	Risque
pod	Illimitée (change à chaque restart)	🔴 Très élevé
uid	Illimitée (unique par objet)	🔴 Très élevé
container_id	Illimitée	🔴 Très élevé
id	Illimitée (cgroup id)	🔴 Très élevé
name	Potentiellement illimitée	🔴 Très élevé
image	Haute (change à chaque tag)	🟠 Moyen-élevé
revision	Potentiellement élevée	🟠 Moyen
node	Nombre de nodes (souvent < 100)	🟢 Faible
namespace	Nombre de namespaces (souvent < 50)	🟢 Faible

Glissez pour voir

Comment s’en protéger

Principe : on filtre d’abord les labels à très forte cardinalité, on drop des métriques seulement quand on sait qu’on ne les utilise pas (après audit des dashboards, alerts, recording rules).

1. Filtrez les labels explosifs au scraping (metric_relabel_configs) :

scrape_configs:
  - job_name: 'cadvisor'
    metric_relabel_configs:
      # Supprimer les labels à cardinalité illimitée
      - action: labeldrop
        regex: 'id|name|image|container_id|uid'

Ne droppez pas vos métriques essentielles

Évitez de drop des métriques entières avant d’avoir audité leur usage. Un action: drop sur container_cpu.* vous ferait perdre exactement les métriques dont vous avez besoin pour les alertes.

Commencez par labeldrop sur les labels explosifs, puis affinez.

2. Utilisez des labels bornés :

• deployment, statefulset au lieu de pod
• namespace, service au lieu de container_id
• Normalisez les chemins : /users/12345 → /users/:id

3. Surveillez votre cardinalité :

# Top 10 métriques par nombre de séries
topk(10, count by (__name__) ({__name__!=""}))

# Séries par label pour une métrique
count by (pod) (container_cpu_usage_seconds_total)

4. Alerte sur la croissance :

- alert: HighCardinalityMetric
  expr: count by (__name__) ({__name__=~"container_.*"}) > 100000
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Metric {{ $labels.__name__ }} has very high cardinality"

Noisy neighbors : détecter les workloads qui surconsomment

Dans un cluster multi-tenant, un workload peut consommer toutes les ressources d’un node et dégrader les performances des autres pods — c’est le “noisy neighbor problem”.

Symptômes

• Latence p99 qui augmente sur des pods “innocents”
• CPU throttling sur des pods qui ne devraient pas en avoir
• Evictions de pods pour pression mémoire
• Pods qui ne se schedulent plus (resources exhausted)

Métriques de détection

CPU par namespace (qui consomme le plus ?) :

sum by (namespace) (
  rate(container_cpu_usage_seconds_total{container!="POD"}[5m])
) / ignoring(namespace) group_left
sum(
  rate(container_cpu_usage_seconds_total{container!="POD"}[5m])
)

Mémoire par namespace :

sum by (namespace) (container_memory_working_set_bytes{container!="POD"})

Pods sans limits (candidats au noisy neighbor) :

kube_pod_container_resource_limits{resource="cpu"} == 0

Protection

Méthode	Description	Quand l’utiliser
Resource Quotas	Limites par namespace (CPU/mémoire totaux)	Multi-tenant
Limit Ranges	Defaults et limites par pod/conteneur	Empêcher les pods sans limits
Priority Classes	Éviction ordonnée en cas de pression	Protéger les workloads critiques
Pod Disruption Budgets	Garantir un minimum de réplicas	Haute disponibilité

Glissez pour voir

8 alertes essentielles pour un cluster K8s

Voici un set minimal d’alertes production-ready, couvrant les signaux critiques sans bruit excessif :

groups:
  - name: kubernetes-essential
    rules:
      # 1. Pod OOMKilled (événement récent)
      - alert: ContainerOOMKilled
        expr: |
          increase(kube_pod_container_status_restarts_total[15m]) > 0
          and on (namespace, pod, container)
          kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1
        for: 0m
        labels:
          severity: warning
        annotations:
          summary: "Container {{ $labels.container }} was OOMKilled (recent)"
          runbook_url: "https://example.com/runbooks/oomkilled"

      # 2. Pod crash looping
      - alert: PodCrashLooping
        expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Pod {{ $labels.pod }} is crash looping"
          runbook_url: "https://example.com/runbooks/crashloop"

      # 3. Pod pending
      - alert: PodPendingTooLong
        expr: sum by (namespace, pod) (kube_pod_status_phase{phase="Pending"}) > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Pod {{ $labels.pod }} is pending"
          runbook_url: "https://example.com/runbooks/pod-pending"

      # 4. Node not ready (version robuste)
      - alert: NodeNotReady
        expr: sum by (node) (kube_node_status_condition{condition="Ready",status="true"}) == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Node {{ $labels.node }} is not ready"
          runbook_url: "https://example.com/runbooks/node-not-ready"

      # 5. CPU throttling
      - alert: ContainerCPUThrottling
        expr: |
          rate(container_cpu_cfs_throttled_seconds_total[5m])
            / (rate(container_cpu_usage_seconds_total[5m]) + 0.001) > 0.2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Container {{ $labels.container }} is CPU throttled"
          runbook_url: "https://example.com/runbooks/cpu-throttling"

      # 6. Mémoire proche de la limite
      - alert: ContainerMemoryNearLimit
        expr: |
          container_memory_working_set_bytes
            / container_spec_memory_limit_bytes > 0.9
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Container {{ $labels.container }} memory at 90%+ of limit"
          runbook_url: "https://example.com/runbooks/memory-near-limit"

      # 7. Deployment replicas mismatch
      - alert: DeploymentReplicasMismatch
        expr: |
          kube_deployment_spec_replicas
            != kube_deployment_status_replicas_available
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Deployment {{ $labels.deployment }} replicas mismatch"
          runbook_url: "https://example.com/runbooks/replicas-mismatch"

      # 8. PVC pending
      - alert: PersistentVolumeClaimPending
        expr: kube_persistentvolumeclaim_status_phase{phase="Pending"} == 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "PVC {{ $labels.persistentvolumeclaim }} is pending"
          runbook_url: "https://example.com/runbooks/pvc-pending"

Anti-patterns : ce qu’il ne faut pas faire

Anti-pattern	Pourquoi c’est un problème	Solution
Scraper pod comme label	Cardinalité explose à chaque deploy	Agréger par deployment, service
Collecter toutes les métriques cAdvisor	Centaines de séries par conteneur	Filtrer au scraping (labeldrop sur labels explosifs)
Pas de kube-state-metrics	Impossible de voir pending, OOMKilled, replicas	Déployer KSM dès le premier jour
Alertes sur les métriques containers seules	Manque le contexte K8s (rollout, scaling)	Combiner avec kube-state-metrics
Logs sans labels K8s	Impossible de corréler avec metrics/traces	Enrichir avec namespace, pod, container
Ignorer le control plane	Problèmes API server, scheduler invisibles	Collecter les métriques du control plane
Pas de resource quotas	Un namespace peut tuer le cluster	Resource quotas en multi-tenant
Limits CPU trop basses	Throttling artificiel, latence dégradée	Évaluer requests-only pour workloads sensibles
Dashboards par pod	200 pods = dashboard illisible	Agréger par deployment, namespace, service
Rétention logs illimitée	Coûts qui explosent	Rétention courte (7-30 jours), tier froid

Glissez pour voir

Workflow : déployer l’observabilité sur un cluster K8s

1. Déployez kube-state-metrics

   Helm chart officiel ou manifest. Vérifiez que le service est scrapé par Prometheus. Vous devriez voir les métriques kube_*.

2. Configurez le scraping cAdvisor / kubelet avec ServiceMonitors

   Utilisez les ServiceMonitors/PodMonitors de votre stack (kube-prometheus-stack). Configurez le RBAC et les certificats TLS. Ajoutez des metric_relabel_configs pour filtrer les labels dangereux (id, name, container_id, uid).

3. Déployez un collecteur de logs

   Fluent Bit, Promtail, ou Vector en DaemonSet. Configurez l’enrichissement avec les labels K8s (namespace, pod, container) et l’envoi vers Loki ou votre backend.

4. Créez les dashboards de base

   Un dashboard “Cluster overview” (nodes, pods pending, restarts). Un dashboard “Namespace” (CPU/mémoire par deployment, top consumers). Un dashboard “Pod debugging” (logs + métriques pour investigation).

5. Déployez les 8 alertes essentielles

   PrometheusRule avec les alertes OOMKilled, crash loop, pending, node not ready, throttling, memory near limit, replicas mismatch, PVC pending. Ajoutez les annotations runbook_url vers vos runbooks.

6. Configurez les resource quotas (clusters multi-tenant)

   Limites par namespace pour CPU et mémoire. Limit ranges pour les defaults pod.

7. Surveillez votre cardinalité

   Dashboard dédié : top métriques par séries, croissance au fil du temps. Alerte si une métrique dépasse un seuil.

8. Itérez sur les filtres et agrégations

   Chaque semaine, identifiez les métriques inutilisées et les labels redondants. Affinez vos recording rules pour pré-agréger.

Pièges courants

Piège	Conséquence	Solution
Scraper toutes les métriques K8s	Prometheus OOM, requêtes lentes	Filtrer dès le scraping
Ignorer le throttling CPU	Latence dégradée sans explication	Alerter sur container_cpu_cfs_throttled
Dashboards avec 500 séries	Grafana timeout, impossible à lire	Agréger, filtrer, utiliser des variables
Logs en mode debug en prod	Volumétrie ×10, coûts ×10	Niveau info ou warn en prod
Pas de rétention différenciée	Tout garder = coûts exponentiels	Hot/warm/cold tiers, rétention par criticité

Glissez pour voir

À retenir

1. Kubernetes expose des métriques à 4 couches : application (vous l’instrumentez), conteneur (cAdvisor), node (kubelet), control plane (API server, scheduler, etcd)

2. Les 3 sources principales : kube-state-metrics pour l’état K8s (pending, OOMKilled, replicas), cAdvisor pour la consommation ressource (CPU, mémoire, I/O), kubelet pour la santé node

3. Les 5 signaux clés : OOMKilled (mémoire dépassée), pod restarts (crash loop), pending pods (scheduler bloqué), node not ready (node défaillant), CPU throttling (limits trop basses ou CFS quota)

4. La cardinalité explose avec les labels dynamiques (pod, uid, container_id). Filtrez dès le scraping avec labeldrop, agrégez par deployment ou service, surveillez avec des requêtes PromQL dédiées

5. Les noisy neighbors se détectent via comparaison de consommation par namespace/deployment. Protégez-vous avec resource quotas et limit ranges

6. Les logs K8s sont stdout/stderr des pods. Enrichissez-les avec les labels K8s à la collecte, limitez la volumétrie avec des rétentions courtes

7. Pour le control plane (clusters self-hosted), collectez les métriques de l’API server, scheduler, controller manager, etcd. Sur les clusters managés, utilisez l’intégration du provider

8. Commencez avec 8 alertes essentielles : OOMKilled (événementiel), crash loop, pending, node not ready, throttling, memory near limit, replicas mismatch, PVC pending

Sources

• Kubernetes — Monitoring overview : kubernetes.io/docs/tasks/debug/monitoring — la référence officielle sur le monitoring K8s
• Kubernetes — System components metrics : kubernetes.io/docs/concepts/cluster-administration/system-metrics — documentation des endpoints kubelet, cAdvisor, et métriques du control plane
• kube-state-metrics — GitHub : github.com/kubernetes/kube-state-metrics — documentation et liste exhaustive des métriques exposées
• Robust Perception — Cardinality is key : robustperception.io/cardinality-is-key — Brian Brazil sur la cardinalité Prometheus
• Kubernetes — kubelet reference : kubernetes.io/docs/reference/command-line-tools-reference/kubelet — référence kubelet incluant les aspects CFS quota et throttling

Prochaines étapes

Dashboards utiles Concevoir des dashboards RED/USE qui exploitent les métriques K8s sans exploser en cardinalité

Alerting efficace Configurer Alertmanager pour router vos alertes K8s vers les bonnes équipes

Runbooks et incidents Écrire des runbooks pour les alertes K8s : OOMKilled, pending, crash loop

Gouvernance Contrôler la cardinalité, la rétention et les coûts de votre observabilité K8s

Corrélation des signaux Relier logs, métriques et traces pour diagnostiquer rapidement les incidents K8s

×

📖 Voir la documentation →