## 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 : ```bash 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 : ```bash kubectl get events --all-namespaces --field-selector type!=Normal ``` Vous pouvez également lister les ressources de l'API d'événements : ```bash 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) : ```bash kubectl get events --all-namespaces --sort-by=.metadata.creationTimestamp ``` Comptez les événements par composant source : ```bash kubectl get 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 : ```bash kubectl get 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 : ```bash 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 : ```yaml spec: containers: - command: - kube-apiserver - --event-ttl=15m ``` Ensuite, le kubelet redémarrera automatiquement l'apiserver. Vérifiez que le drapeau est actif : ```bash 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 : ```bash 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 ` et `kubectl logs --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 : ```bash cp /etc/kubernetes/manifests/kube-apiserver.yaml /root/kube-apiserver.yaml.bak ``` 2. Effectuez la modification sur un seul nœud du plan de contrôle d'abord. 3. Observez le redémarrage du serveur d'API et la stabilité du cluster. 4. Vérifiez avec `kubectl get nodes` et `kubectl get --raw='/readyz?verbose'`. 5. 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash kubectl create event test-event --namespace=default --type=Normal --reason=TestReason --message="Testing event latency" ``` Listez-le immédiatement : ```bash 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 : ```bash kubectl describe pod -n ``` Recherchez des événements répétés comme `BackOff`, `FailedScheduling` ou `ProbeWarning`. Utilisez `kubectl logs --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 : ```bash 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 : ```bash kubectl get --raw='/readyz?verbose' ``` Doit afficher `ok` pour tous les contrôles. Vérifiez la création d'événements : ```bash 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 : ```bash 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.