Aide-mémoire : métriques Kubernetes indispensables à surveiller

Cet aide-mémoire rassemble les métriques Kubernetes essentielles monitoring que tout ingénieur infrastructure Kubernetes ou administrateur système Kubernetes certification CKS doit surveiller. Avec 75% des équipes utilisant Prometheus et Grafana pour le monitoring Kubernetes, maîtriser ces métriques est devenu une compétence incontournable.

TL;DR : Ce cheatsheet liste les métriques critiques par catégorie (cluster, nœuds, pods, réseau) avec les requêtes PromQL correspondantes et les seuils d'alerte recommandés.

Cette compétence est au cœur de la formation LFS458 Administration Kubernetes.

Quelles sont les métriques Kubernetes essentielles monitoring au niveau cluster ?

Les métriques cluster donnent une vue globale de la santé de votre infrastructure Kubernetes.

Métriques de santé du cluster

Métrique	Description	Seuil critique
`kube_node_status_condition`	État des nœuds	!= Ready
`apiserver_request_total`	Requêtes API server	> 5000/s
`etcd_server_has_leader`	Leadership etcd	= 0
`scheduler_pending_pods`	Pods en attente	> 10 pendant 5min

Requêtes PromQL essentielles

# Nombre de nœuds Ready
sum(kube_node_status_condition{condition="Ready",status="true"})

# Taux d'erreur API server
sum(rate(apiserver_request_total{code=~"5.."}[5m])) 
/ sum(rate(apiserver_request_total[5m])) * 100

# Latence des requêtes API (P99)
histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

Définition : Le Control Plane comprend l'API server, le scheduler, le controller-manager et etcd, composants critiques dont les métriques doivent être surveillées en priorité.

À retenir : Un cluster sain affiche un taux d'erreur API < 1% et une latence P99 < 1 seconde.

Consultez l'architecture de monitoring Kubernetes en production pour l'implémentation complète.

Comment surveiller les métriques Kubernetes essentielles monitoring des nœuds ?

Les métriques nœuds détectent les problèmes de capacité et de performance.

Tableau de référence rapide

Métrique	Source	Requête PromQL	Alerte si
CPU utilisé	node-exporter	`node_cpu_seconds_total`	> 85%
Mémoire utilisée	node-exporter	`node_memory_MemAvailable_bytes`	< 15%
Disque utilisé	node-exporter	`node_filesystem_avail_bytes`	< 10%
Network I/O	node-exporter	`node_network_receive_bytes_total`	Anomalie

Requêtes de monitoring nœuds

# CPU par nœud (%)
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Mémoire disponible (%)
(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

# Pression disque
node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100

# Pods par nœud vs capacité
sum by(node) (kube_pod_info) / on(node) kube_node_status_allocatable{resource="pods"} * 100

Selon le rapport CNCF Annual Survey 2025, 82% des organisations exécutent Kubernetes en production, rendant le monitoring des nœuds critique.

Définition : La pression mémoire (MemoryPressure) est une condition indiquant que le nœud manque de mémoire disponible et pourrait bientôt évincer des pods.

Quelles métriques surveiller au niveau des pods et conteneurs ?

Les métriques pods détectent les problèmes applicatifs avant qu'ils n'impactent les utilisateurs.

Métriques de ressources conteneurs

# Mémoire utilisée par pod
sum by(pod, namespace) (container_memory_usage_bytes{container!=""})

# CPU utilisé par pod
sum by(pod, namespace) (rate(container_cpu_usage_seconds_total{container!=""}[5m]))

# Ratio mémoire utilisée / limite
container_memory_usage_bytes / container_spec_memory_limit_bytes

# Redémarrages de conteneurs
sum by(pod) (kube_pod_container_status_restarts_total)

Seuils d'alerte recommandés

Métrique	Warning	Critical
Mémoire / Limite	> 80%	> 90%
CPU / Limite	> 70%	> 85%
Redémarrages/heure	> 3	> 10
Pods non Ready	> 0 pendant 5min	> 0 pendant 15min

À retenir : Surveillez le ratio utilisation/limite pour prévenir les OOMKilled avant qu'ils ne surviennent.

Le cheatsheet commandes kubectl debugging complète ces métriques avec les commandes manuelles.

Comment monitorer les métriques réseau Kubernetes ?

Les problèmes réseau sont parmi les plus difficiles à diagnostiquer sans métriques appropriées.

Métriques réseau essentielles

# Bande passante reçue par pod
sum by(pod) (rate(container_network_receive_bytes_total[5m]))

# Bande passante transmise par pod
sum by(pod) (rate(container_network_transmit_bytes_total[5m]))

# Erreurs réseau
sum by(pod) (rate(container_network_receive_errors_total[5m]))

# Paquets dropped
sum by(pod) (rate(container_network_receive_packets_dropped_total[5m]))

Indicateurs de service mesh (Istio)

Métrique	Description	Objectif
`istio_requests_total`	Nombre de requêtes	Baseline
`istio_request_duration_milliseconds`	Latence	P99 < 500ms
`istio_tcp_connections_opened_total`	Connexions TCP	Monitoring

L'observabilité Kubernetes couvre l'intégration métriques, logs et traces.

Quelles métriques d'application surveiller ?

Les métriques applicatives (Golden Signals) sont les indicateurs ultimes de la santé du service.

Les 4 Golden Signals

Signal	Définition	Métrique type
Latency	Temps de réponse	`http_request_duration_seconds`
Traffic	Volume de requêtes	`http_requests_total`
Errors	Taux d'erreur	`http_requests_total{status=~"5.."}`
Saturation	Utilisation ressources	`container_memory_usage_bytes`

Exemple de requêtes

# Taux d'erreur HTTP (%)
sum(rate(http_requests_total{status=~"5.."}[5m])) 
/ sum(rate(http_requests_total[5m])) * 100

# Latence P95
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

# Requêtes par seconde
sum(rate(http_requests_total[5m]))

Définition : Les Golden Signals, définis par Google SRE, sont les quatre métriques fondamentales pour évaluer la santé d'un système distribué.

À retenir : Un SLO typique vise < 1% d'erreurs et une latence P95 < 200ms.

Comment configurer les alertes critiques ?

Des alertes bien configurées transforment les métriques en actions.

Règles d'alerte Prometheus

groups:
- name: kubernetes-critical
  rules:
  - alert: KubernetesNodeNotReady
    expr: kube_node_status_condition{condition="Ready",status="true"} == 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Node {{ $labels.node }} not ready"

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

  - alert: KubernetesContainerOomKilled
    expr: kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} > 0
    for: 0m
    labels:
      severity: critical

La checklist observabilité Kubernetes en production détaille la configuration complète.

Référence rapide : commandes kubectl monitoring

Complétez Prometheus avec ces commandes kubectl pour le debugging en temps réel.

# Top pods par CPU
kubectl top pods -A --sort-by=cpu | head -20

# Top pods par mémoire
kubectl top pods -A --sort-by=memory | head -20

# Ressources par nœud
kubectl top nodes

# Événements récents du cluster
kubectl get events -A --sort-by='.lastTimestamp' | tail -30

# Pods non Running
kubectl get pods -A --field-selector=status.phase!=Running

Consultez la page administrateur système Kubernetes pour le parcours complet.

Passez à l'action : maîtrisez le monitoring Kubernetes

Le monitoring est une compétence clé des examens CKA et CKS. Selon la Linux Foundation, l'examen CKS exige un score de 67% sur 2 heures et nécessite un CKA valide.

Comme l'affirme Chris Aniszczyk, CTO de la CNCF : "Kubernetes is no longer experimental but foundational. Soon, it will be essential to AI as well."

La formation LFS458 Administration Kubernetes couvre le monitoring en production sur 4 jours. Pour la sécurité avancée, consultez la formation LFS460 Sécurité Kubernetes.

Ressources complémentaires :

Contactez nos conseillers pour définir votre parcours de certification.

Points clés