Un incident qui s’est produit hier laisse presque toujours moins de traces qu’attendu : les Events Kubernetes, souvent la première ressource consultée pour comprendre ce qui s’est passé, disparaissent par défaut au bout d’une heure, pas d’un jour ni d’une semaine. Chercher la preuve d’un événement de la veille dans kubectl get events revient à chercher une donnée déjà purgée.

Ce qu’un Event est réellement, et qui l’émet

Un Event n’est pas un log applicatif ni un enregistrement d’audit de requête API : c’est une notification structurée émise par le kubelet ou un contrôleur pour signaler un changement d’état (Scheduled, Pulled, Started, Failed, BackOff). Chaque Event est stocké dans etcd comme n’importe quelle ressource Kubernetes, ce qui explique pourquoi une politique de rétention agressive existe : sans elle, le volume d’Events générés en continu par un cluster actif finirait par saturer etcd.

# Les événements les plus récents en premier,
# la première commande de diagnostic après un incident
kubectl get events --sort-by='.lastTimestamp'

Le TTL par défaut : une heure, configurable côté serveur API

--event-ttl sur le serveur API fixe la durée de rétention des Events, une heure par défaut. Un Event Failed émis à 14h qui explique un incident survenu à 14h05 a de bonnes chances d’avoir déjà disparu à 15h30, quand quelqu’un commence enfin à investiguer après avoir remarqué un problème plus tard.

# Ajustable côté configuration de l'API server,
# rarement modifié par défaut malgré ce coût
--event-ttl=1h0m0s

Augmenter ce TTL a un coût réel en volume etcd, ce qui explique pourquoi la valeur par défaut reste courte plutôt que d’être étendue par précaution : chaque changement d’état de chaque pod, pour chaque conteneur, génère un Event, un volume qui grandit vite sur un cluster à forte activité de déploiement.

Pourquoi les Events ne remplacent jamais l’audit logging

Un Event répond à « que s’est-il passé à ce pod, du point de vue du kubelet ou d’un contrôleur ». L’audit logging répond à une question différente : « qui a appelé l’API, et avec quelle requête ». Les deux mécanismes coexistent sans se substituer l’un à l’autre : un Event ne dit jamais qui a déclenché le déploiement qui a créé le pod, et l’audit log ne dit jamais que le pod a échoué à démarrer trois fois avant de réussir.

Exporter les Events pour dépasser la fenêtre d’une heure

Un exportateur d’événements (comme kube-eventer ou une intégration native à la stack d’observabilité) capture chaque Event au moment de son émission et le transmet vers un système de logs externe (Loki, Elasticsearch), avant que le TTL ne le supprime d’etcd. Une fois exporté, l’Event survit indéfiniment, à la durée de rétention du système de logs cible, pas à celle d’etcd.

# Un exportateur capture chaque Event au moment de
# son émission, avant que le TTL ne l'efface d'etcd
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-event-exporter

Cette exportation transforme une mémoire d’une heure en historique consultable des semaines plus tard, un investissement qui vaut la peine dès qu’un post-mortem doit reconstituer précisément ce qui s’est passé sur un pod plusieurs jours après l’incident.

À retenir

Un Event Kubernetes disparaît par défaut après une heure, une politique de rétention volontairement courte pour limiter le volume stocké dans etcd, ce qui rend la preuve d’un incident survenu la veille souvent déjà purgée au moment où quelqu’un la cherche. Les Events et l’audit logging répondent à deux questions différentes (l’état d’un objet contre qui a appelé l’API) et ne se substituent jamais l’un à l’autre. Exporter les Events vers un système de logs externe avant leur expiration transforme cette mémoire courte en historique durable, un réflexe qui compte dès qu’un post-mortem doit remonter au-delà de la dernière heure, un des détails d’observabilité qui séparent un fiabilité et observabilité réellement exploitable d’un simple accès temporaire à l’information.