Réglage des performances des événements Kubernetes avec exemples pratiques

Introduction

Les événements Kubernetes constituent l'enregistrement principal des raisons pour lesquelles quelque chose s'est produit dans votre cluster. Lorsqu'un pod échoue, qu'un déploiement est mis à l'échelle ou qu'un nœud devient indisponible, les événements capturent la raison provenant des contrôleurs, des planificateurs, des kubelets et du serveur d'API. Ils sont essentiels pour le débogage, l'audit et l'automatisation. Cependant, dans les clusters de grande taille ou très actifs, les événements peuvent devenir eux-mêmes un problème de performance : un volume élevé d'événements peut submerger le serveur d'API, ralentir kubectl get events, remplir le stockage etcd et masquer des avertissements critiques dans un flot de bruit.

Cet article est un guide pratique destiné aux opérateurs Kubernetes, aux ingénieurs DevOps et aux équipes de plateforme qui doivent ajuster la gestion des événements pour la performance et la fiabilité. Il se concentre sur l'identification de la latence et des goulots d'étranglement des événements, l'optimisation de la génération et de la rétention des événements, et la vérification que vos modifications réduisent la charge sans perdre une visibilité critique. Nous couvrirons l'inventaire des versions et de l'environnement, les chemins de configuration sûrs, la vérification et les diagnostics, les modes de défaillance et la récupération, ainsi qu'une liste de contrôle opérationnelle. Chaque section comprend des commandes concrètes, des sorties attendues et des critères de décision.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu des secrets, vérifier les résultats et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire des versions et de l'environnement

Avant de régler les événements Kubernetes, vous devez connaître la version de votre cluster, les sources d'événements et le taux d'événements actuel. Le comportement de la gestion des événements a changé selon les versions de Kubernetes, notamment concernant l'API Event et le groupe d'API plus récent events.k8s.io. Commencez par identifier ce avec quoi vous travaillez et mesurer la référence.

Identifier la version de Kubernetes et la prise en charge de l'API d'événements

Exécutez la commande suivante pour vérifier la version du serveur :

kubectl version --short

La sortie attendue ressemble à ceci :

Client Version: v1.29.2
Server Version: v1.28.5

Si la version de votre serveur est 1.19 ou ultérieure, l'API events.k8s.io/v1 est disponible. Cette API plus récente fournit des événements plus structurés et est utilisée par certains composants. Vérifiez si des événements sont créés dans ce groupe d'API :

kubectl events --all-namespaces --types=Warning

Vous pouvez également lister les ressources de l'API d'événements :

kubectl api-resources | grep events

Sortie attendue :

events                            events.k8s.io/v1                true         Event
events                            v1                              true         Event

Inventorier les sources et le taux d'événements

Déterminez quels contrôleurs et nœuds génèrent le plus d'événements. Utilisez kubectl get events avec le tri et les sélecteurs de champs pour identifier les sources bruyantes.

Listez tous les événements de la dernière heure (si la rétention de votre cluster le permet) :

kubectl events --all-namespaces

Comptez les événements par composant source :

kubectl events --all-namespaces -o json | jq -r '.items[].source.component' | sort | uniq -c | sort -nr

Exemple de sortie :

  834 kubelet
  156 deployment-controller
   89 scheduler
   34 replicaset-controller
   12 node-controller

Cela vous indique quels composants génèrent le plus d'événements. Dans cet exemple, kubelet est la principale source, ce qui indique souvent des redémarrages fréquents de pods ou des échecs de sondes.

Vérifiez le nombre d'événements par espace de noms :

kubectl events --all-namespaces -o json | jq -r '.items[].metadata.namespace' | sort | uniq -c | sort -nr

Exemple de sortie :

  456 default
  210 kube-system
   98 production-app
   23 monitoring

Des taux d'événements élevés dans un espace de noms peuvent indiquer une mauvaise configuration de l'application, comme des pods en boucle de crash.

Vérifier la taille d'etcd et la rétention des événements

Les événements sont stockés dans etcd et ont une durée de vie par défaut d'une heure (définie par --event-ttl sur le kube-apiserver). Si le volume d'événements est élevé, etcd peut croître de manière significative. Vérifiez la taille d'etcd (si vous y avez accès) ou surveillez-la via les métriques.

Pour un cluster géré comme EKS ou GKE, utilisez la console de surveillance du fournisseur cloud. Pour un cluster autogéré, vous pouvez inspecter les métriques etcd :

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key endpoint status --write-out=table

Recherchez DB SIZE. S'il dépasse vos attentes de capacité et que les événements en sont une contribution majeure, envisagez de régler la durée de vie des événements ou l'agrégation.

Prérequis et accès nécessaires

Pour effectuer ces vérifications, vous avez besoin de :

• kubectl configuré avec des droits cluster-admin ou au moins un accès en lecture aux événements dans tous les espaces de noms.
• jq installé pour le traitement JSON (facultatif mais utile).
• Pour l'inspection d'etcd sur les clusters autogérés, un accès SSH aux nœuds du plan de contrôle et les certificats clients etcd.
• Dans les clusters gérés, l'accès aux tableaux de bord de surveillance et aux journaux du fournisseur cloud.

Chemin de configuration sûr

Les principaux leviers pour les performances des événements sont les drapeaux du kube-apiserver --event-ttl, --max-mutating-requests-inflight et --max-requests-inflight, ainsi que les paramètres d'agrégation des événements. Leur modification peut avoir un large rayon d'impact ; suivez donc une approche prudente et réversible.

Comprendre les paramètres par défaut

Le kube-apiserver possède plusieurs paramètres pertinents :

• --event-ttl : Durée de conservation des événements, par défaut 1h.
• --max-requests-inflight : Nombre maximal de requêtes non mutantes, par défaut 400.
• --max-mutating-requests-inflight : Nombre maximal de requêtes mutantes, par défaut 200.
• --audit-log-maxbackup : Pas directement lié mais affecte la charge de journalisation.

La création d'événements est une requête mutante. Si le serveur d'API est saturé par les écritures d'événements, d'autres requêtes mutantes (créations de pods, mises à jour) peuvent être retardées. Augmenter --max-mutating-requests-inflight peut accroître le débit mais augmente également l'utilisation de la mémoire et la charge sur etcd.

Régler la durée de vie des événements (TTL)

Si votre etcd est gonflé par les événements, réduire --event-ttl peut libérer de l'espace. Par exemple, pour définir une durée de vie de 15 minutes :

Modifiez le manifeste du kube-apiserver sur chaque nœud du plan de contrôle (généralement /etc/kubernetes/manifests/kube-apiserver.yaml) et ajoutez ou modifiez :

spec:
  containers:
  - command:
    - kube-apiserver
    - --event-ttl=15m

Ensuite, le kubelet redémarrera automatiquement l'apiserver. Vérifiez que le drapeau est actif :

kubectl get pod -n kube-system -l component=kube-apiserver -o yaml | grep event-ttl

Sortie attendue :

    - --event-ttl=15m

Impact : Les événements de plus de 15 minutes sont supprimés, ce qui réduit la taille d'etcd mais aussi les informations de débogage historiques. Choisissez une valeur adaptée à vos besoins.

Activer l'agrégation des événements

Kubernetes dispose d'un mécanisme d'agrégation des événements dans le kube-apiserver (non activé par défaut dans les anciennes versions, mais disponible en tant que feature gate). Dans les versions plus récentes (1.13+), l'agrégation des événements est activée par défaut. Elle regroupe les événements similaires pour réduire le bruit. Vous pouvez vérifier en consultant les journaux de l'apiserver pour les messages d'agrégation :

kubectl logs -n kube-system kube-apiserver-control-plane -c kube-apiserver | grep -i aggregate

Si vous devez ajuster les paramètres d'agrégation, ils sont codés en dur dans le code source et ne sont pas exposés via des drapeaux. Dans ce cas, concentrez-vous sur la réduction des événements à la source.

Réduire la génération d'événements à la source

Souvent, le meilleur réglage consiste à arrêter de générer des événements inutiles. Causes courantes :

• Pods avec des sondes défaillantes provoquant des redémarrages constants.
• Déploiements avec des échecs de mise à jour progressive.
• Nœuds avec des conditions fluctuantes.

Corrigez le problème sous-jacent et le volume d'événements diminuera. Utilisez kubectl describe pod <name> et kubectl logs <pod> --previous pour diagnostiquer.

Appliquer les modifications en toute sécurité

Lors de la modification des drapeaux du kube-apiserver :

1. Sauvegardez le fichier manifeste original :

   cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml.bak

1. Effectuez la modification sur un seul nœud du plan de contrôle d'abord.
2. Observez le redémarrage du serveur d'API et la stabilité du cluster.
3. Vérifiez avec kubectl get nodes et kubectl get --raw='/readyz?verbose'.
4. Si tout est sain, appliquez aux autres nœuds du plan de contrôle un par un.

Vérification et diagnostics

Après avoir effectué un réglage, vérifiez que la gestion des événements s'améliore et que le cluster reste stable. Utilisez les métriques, les journaux et des commandes pratiques pour confirmer.

Surveiller la latence et les erreurs des requêtes du serveur d'API

Vérifiez les métriques du serveur d'API pour la durée des requêtes liées aux événements :

kubectl get --raw /metrics | grep apiserver_request_duration_seconds | grep events

Recherchez un p99 élevé ou des taux d'erreur croissants. Comparez avant et après votre modification.

Vous pouvez également utiliser kubectl top ou des tableaux de bord de surveillance (Prometheus/Grafana) pour visualiser.

Vérifier le taux et la latence des événements

Mesurez la rapidité avec laquelle vous pouvez lister les événements :

time kubectl get events --all-namespaces --sort-by=.lastTimestamp

Si cela se termine en quelques secondes, c'est acceptable. Si cela prend des dizaines de secondes, le serveur d'API peut être surchargé ou etcd lent.

Comptez les événements sur une période pour voir le taux :

watch -n 5 'kubectl get events --all-namespaces --no-headers | wc -l'

Observez l'évolution du nombre ; s'il augmente rapidement, les sources d'événements génèrent encore du bruit.

Vérifier la réduction de la taille d'etcd (si la durée de vie a changé)

Si vous avez réduit la durée de vie, attendez que les anciens événements expirent (selon l'ancienne durée) puis vérifiez à nouveau la taille d'etcd avec la commande de statut du point de terminaison. Attendez-vous à une diminution si les événements représentaient une part significative.

Tester la création d'événements sous charge

Générez un événement de test pour vous assurer que l'API accepte rapidement la création d'événements :

kubectl create event test-event --namespace=default --type=Normal --reason=TestReason --message="Testing event latency"

Listez-le immédiatement :

kubectl get event test-event -n default

Vérifiez qu'il apparaît en moins d'une seconde. Si ce n'est pas le cas, examinez les performances du serveur d'API.

Diagnostiquer les problèmes de sources d'événements

Pour les sources bruyantes, examinez des pods ou nœuds spécifiques :

kubectl describe pod <noisy-pod> -n <namespace>

Recherchez des événements répétés comme BackOff, FailedScheduling ou ProbeWarning. Utilisez kubectl logs <pod> --previous pour voir les raisons des plantages.

Modes de défaillance et récupération

Le réglage de la gestion des événements peut entraîner de nouvelles défaillances. Sachez ce qu'il faut surveiller et comment récupérer rapidement.

Défaillance : serveur d'API instable ou ne répondant plus après modification des drapeaux

Si la modification de --max-mutating-requests-inflight ou d'autres drapeaux provoque une boucle de crash ou une non-réponse du serveur d'API :

• Revenez au manifeste de sauvegarde.
• Si le serveur d'API est complètement hors service, accédez directement au nœud du plan de contrôle.
• Restaurez le fichier de sauvegarde :

  cp /root/kube-apiserver.yaml.bak /etc/kubernetes/manifests/kube-apiserver.yaml

• Le kubelet redémarrera le serveur d'API avec les paramètres d'origine.
• Vérifiez la santé du cluster.

Défaillance : les événements disparaissent trop rapidement (durée de vie trop courte)

Si vous définissez --event-ttl trop bas, vous risquez de perdre des événements nécessaires au débogage. Un utilisateur signale qu'il ne peut pas voir les événements d'une défaillance survenue il y a 20 minutes. Récupération :

• Augmentez la durée de vie à une période plus longue, par exemple 1 heure.
• Appliquez la modification comme décrit et vérifiez.
• Envisagez de mettre en place une exportation externe des événements (par exemple vers Elasticsearch ou Loki) pour une rétention à long terme au lieu de les stocker dans etcd.

Défaillance : augmentation de l'utilisation de la mémoire sur le serveur d'API

L'augmentation des limites de requêtes en vol peut accroître la consommation de mémoire. Surveillez la mémoire du serveur d'API avec kubectl top pod -n kube-system. Si elle approche des limites, réduisez les valeurs ou ajoutez plus de ressources aux nœuds du plan de contrôle.

Défaillance : l'agrégation des événements masque des événements importants

Si l'agrégation est trop agressive (anciennes versions), des événements critiques peuvent être fusionnés et difficiles à trouver. Dans ce cas, vous devrez peut-être désactiver l'agrégation (non recommandé) ou ajuster votre surveillance des événements pour capturer tous les événements avant agrégation à l'aide d'un exportateur d'événements comme event-exporter de Kubernetes ou d'outils tiers.

Vérification de la récupération

Vérifiez toujours la récupération :

kubectl get --raw='/readyz?verbose'

Doit afficher ok pour tous les contrôles.

Vérifiez la création d'événements :

kubectl create event recovery-test --namespace=default --type=Normal --reason=RecoveryCheck --message="Recovery verified"

Et assurez-vous qu'il apparaît.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant, pendant et après le réglage des événements Kubernetes pour garantir des opérations sûres.

Liste de contrôle avant modification

• [ ] Confirmer la version de Kubernetes et la disponibilité de l'API d'événements.
• [ ] Mesurer le taux d'événements actuel et la répartition des sources.
• [ ] Vérifier la taille d'etcd et la contribution des événements.
• [ ] Sauvegarder le manifeste du kube-apiserver sur tous les nœuds du plan de contrôle.
• [ ] Documenter les valeurs actuelles des drapeaux :

  kubectl get pod -n kube-system -l component=kube-apiserver -o json | jq '.items[].spec.containers[].command'

• [ ] Assurer un accès direct aux nœuds du plan de contrôle pour la récupération d'urgence.

Liste de contrôle d'exécution des modifications

• [ ] Appliquer la modification à un nœud du plan de contrôle à la fois.
• [ ] Attendre le redémarrage du serveur d'API et sa disponibilité.
• [ ] Exécuter kubectl get --raw='/readyz?verbose' pour vérifier la santé du serveur d'API.
• [ ] Observer les performances de listage des événements.
• [ ] Surveiller l'utilisation des ressources du serveur d'API (CPU, mémoire).

Liste de contrôle de vérification après modification

• [ ] Comparer le taux d'événements avant et après.
• [ ] Confirmer que la latence des événements est acceptable (par exemple, créer et lister un événement de test).
• [ ] Vérifier la tendance de la taille d'etcd si la durée de vie a changé.
• [ ] Vérifier que les événements essentiels (par exemple, échecs de pods) sont toujours visibles.
• [ ] Déployer sur les nœuds restants du plan de contrôle si tout est stable.

Opérations continues

• [ ] Mettre en place des alertes de surveillance pour la latence des requêtes du serveur d'API et les taux d'erreur.
• [ ] Implémenter l'exportation des événements si une rétention à long terme est requise.
• [ ] Examiner périodiquement les principales sources d'événements et corriger les causes racines.
• [ ] Documenter toutes les modifications de réglage dans un runbook.

Conclusion

Le réglage des performances des événements Kubernetes consiste à équilibrer la visibilité et l'utilisation des ressources. En mesurant les taux d'événements, en identifiant les sources bruyantes et en ajustant soigneusement les paramètres du serveur d'API tels que la durée de vie des événements, vous pouvez réduire la charge sur etcd et la pression sur l'API sans perdre des données opérationnelles critiques. Suivez toujours une approche systématique : inventaire, configuration sûre, vérification et planification de la récupération.

Comme prochaine étape, commencez par les contrôles non invasifs : identifiez la version de votre cluster, mesurez les sources d'événements avec les commandes jq fournies et évaluez si le volume d'événements cause des problèmes. Ensuite, envisagez d'appliquer la modification la moins risquée, comme corriger un pod bruyant ou ajuster la durée de vie des événements, et vérifiez l'impact avec des métriques concrètes. N'oubliez pas de documenter votre référence et votre chemin de récupération afin que tout réglage reste sûr et réversible.