PerfectScale

Kubernetes Events: visualizzazione, filtri e troubleshooting

Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.

By Josh Palmer Jun 11, 202613 min read

Cosa sono i Kubernetes Events?

TL;DR: i Kubernetes Events sono risorse API effimere e in tempo reale, generate ogni volta che si verifica un cambio di stato, un errore o un'attività rilevante all'interno del cluster. Sono utili per il debug e per verificare lo stato di salute del cluster. Gli Events registrano dettagli come ciò che è accaduto, l'oggetto coinvolto, l'orario dell'evento e una breve descrizione leggibile.

Caratteristiche principali:

Tipi: in genere classificati come Normal (modifiche standard, ordinarie) o Warning (a indicare anomalie come back-off loop o problemi di scheduling).
Conservazione: gli Events sono effimeri. Per impostazione predefinita vengono memorizzati in etcd per un massimo di un'ora, prima di essere rimossi dal garbage collector.
Attributi principali: ogni evento include Last Seen, Type, Reason, Object (es. Pod/web-server) e un Message che descrive la transizione di stato.

Come visualizzare gli Events:

Utilizzi il comando integrato kubectl events per ispezionare e monitorare gli Events direttamente dal terminale:

Visualizzare tutti gli Events recenti nel namespace predefinito: kubectl events
Visualizzare gli Events in tutti i namespace: kubectl events --all-namespaces
Monitorare in tempo reale gli Events di una risorsa specifica: kubectl events --for pod/<pod-name> --watch
Visualizzare gli Events recenti in formato YAML: kubectl events -o yaml

Questo articolo fa parte di una serie dedicata al troubleshooting di Kubernetes.

In questo articolo:

Caratteristiche principali dei Kubernetes Events
Kubernetes Events vs. log vs. metriche
Come visualizzare i Kubernetes Events
Come filtrare i Kubernetes Events
Tipi e motivi più comuni dei Kubernetes Events
Troubleshooting con i Kubernetes Events
Best practice per l'uso dei Kubernetes Events

Caratteristiche principali dei Kubernetes Events

1. Tipi

I Kubernetes Events si classificano principalmente in due tipi: normal e warning:

Gli eventi normal indicano operazioni riuscite o attese, come la creazione di un pod o uno scheduling andato a buon fine da parte del control plane. Sono eventi informativi e aiutano a tracciare il regolare funzionamento delle risorse.
Gli eventi warning segnalano condizioni inattese o problematiche, come errori di scheduling o di pull dell'immagine. Sono fondamentali per individuare e risolvere rapidamente i problemi prima che si trasformino in interruzioni di servizio più ampie.

I due tipi di eventi assolvono a funzioni diverse, ma sono ugualmente importanti per l'osservabilità del cluster. Gli eventi normal consentono agli operator di confermare che le risorse si comportino come previsto, mentre gli eventi warning fungono da sistema di allerta precoce per errori o configurazioni sbagliate.

2. Conservazione

I Kubernetes Events vengono memorizzati nel datastore etcd del cluster, ma non sono conservati a tempo indeterminato. Per impostazione predefinita gli eventi restano disponibili per un'ora, anche se questo intervallo può essere configurato nelle impostazioni dell'API server.

Una finestra di conservazione così breve serve a ridurre al minimo l'impatto sulle prestazioni del cluster ed evitare che etcd venga sovraccaricato da dati transitori o ripetitivi. Tuttavia, significa anche che gli operator devono muoversi rapidamente per analizzare o esportare gli eventi a scopo di approfondimento.

Dato il tempo di conservazione limitato, affidarsi esclusivamente all'archivio interno al cluster per audit a lungo termine o analisi post-mortem è sconsigliato. Negli ambienti che richiedono uno storico più esteso, la buona prassi è esportare gli eventi verso un sistema esterno di logging o monitoring.

3. Attributi principali

Ogni Kubernetes Event contiene diversi attributi principali che forniscono contesto su ciò che è accaduto e dove. Gli attributi chiave includono:

L'oggetto coinvolto (come un Pod o un Node)
Il tipo di evento (Normal o Warning)
Un codice motivo che riassume la causa
Un messaggio leggibile
I timestamp della prima e dell'ultima occorrenza

Questi attributi strutturati semplificano filtri, ricerche e correlazioni con altri dati di osservabilità. Comprenderli è fondamentale per un troubleshooting efficace. Ad esempio, i campi reason e message spesso offrono indizi immediati sulle cause alla radice, mentre i timestamp aiutano a ricostruire la sequenza degli eventi correlati. Il riferimento all'oggetto coinvolto consente di approfondire la risorsa interessata.

Kubernetes Events vs. log vs. metriche

Kubernetes Events, log e metriche assolvono a funzioni diverse nell'osservabilità del cluster:

Gli Events registrano cambi di stato di alto livello e azioni significative all'interno delle risorse Kubernetes, come lo scheduling o gli errori dei Pod.
I log forniscono registrazioni dettagliate e con timestamp dell'attività di applicazioni o sistemi, offrendo una visione approfondita di ciò che accade all'interno dei container o degli stessi componenti Kubernetes.
Le metriche sono misurazioni numeriche raccolte nel tempo, come l'utilizzo di CPU o il consumo di memoria, e servono a monitorare l'andamento e ad attivare alert.

Gli Events sono utili per tracciare il ciclo di vita delle risorse del cluster e individuare la causa di cambiamenti improvvisi; i log sono più indicati per il debug del comportamento applicativo e la diagnosi di problemi complessi; le metriche, invece, permettono agli operator di monitorare salute e prestazioni delle risorse su larga scala, supportando il capacity planning e l'autoscaling.

Come visualizzare i Kubernetes Events

Kubernetes mette a disposizione diversi modi per visualizzare gli eventi direttamente da riga di comando con kubectl. Il metodo più comune è il comando kubectl get events, che restituisce l'elenco degli eventi nel namespace corrente. L'output include dettagli come tipo di evento, motivo, oggetto coinvolto e messaggio.

Per visualizzare gli eventi in tutti i namespace, è possibile aggiungere il flag --all-namespaces.

kubectl get events

kubectl get events --all-namespaces

Poiché gli eventi sono sensibili al tempo, ordinarli per timestamp è spesso utile durante il troubleshooting. Kubernetes consente di ordinarli per data di creazione tramite l'opzione --sort-by. Questo aiuta a comprendere la sequenza delle azioni avvenute prima di un errore o di un problema di deployment.

kubectl get events --sort-by=.metadata.creationTimestamp

È inoltre possibile ispezionare gli eventi relativi a una risorsa specifica con il comando kubectl describe. Ad esempio, descrivendo un Pod si visualizzano i dettagli della risorsa insieme a una sezione Events dedicata in fondo. È uno dei modi più rapidi per individuare problemi come scheduling fallito, crash dei container o errori di pull dell'immagine.

kubectl describe pod my-pod

Negli ambienti di produzione, gli eventi vengono spesso integrati in piattaforme di osservabilità centralizzate come Elasticsearch, Loki o strumenti di monitoring cloud-native. Ciò consente una conservazione più lunga, ricerche avanzate e correlazioni con log e metriche, rendendo il troubleshooting più efficiente su larga scala.

Come filtrare i Kubernetes Events

Filtrare i Kubernetes Events aiuta gli operator a concentrarsi sulle informazioni più rilevanti durante il troubleshooting. Poiché i cluster possono generare grandi volumi di Events, filtrare per namespace, oggetto, tipo o motivo rende più semplice individuare rapidamente i problemi.

1. L'approccio più semplice è limitare i risultati a un namespace specifico.

kubectl get events -n production

2. I field selector offrono funzionalità di filtro più avanzate. È possibile filtrare gli Events per nome dell'oggetto coinvolto, tipo di risorsa, motivo o tipo di Event. Ad esempio, il comando seguente mostra solo gli Events di tipo Warning, tipicamente associati a errori o condizioni anomale.

kubectl get events --field-selector type=Warning

3. Per visualizzare gli eventi relativi a un pod specifico, è possibile filtrare per nome dell'oggetto.

kubectl get events --field-selector involvedObject.name=my-pod

Filtrare per motivo è utile anche quando si diagnosticano problemi ricorrenti. Ad esempio, gli operator possono cercare gli errori di scheduling all'interno del cluster.

kubectl get events --field-selector reason=FailedScheduling

4. I Kubernetes Events possono anche essere trasmessi in streaming in tempo reale tramite il flag --watch. È utilissimo durante i deployment o la gestione degli incidenti, perché mostra in continuo i nuovi Events man mano che si verificano.

kubectl get events --watch

Per workflow più avanzati, gli eventi vengono comunemente esportati verso piattaforme di monitoring e logging in cui è possibile applicare query complesse, dashboard e alert. Ciò consente ai team di automatizzare il rilevamento degli incidenti e correlare gli eventi con log e metriche per un'analisi più rapida della causa principale.

Tipi e motivi più comuni dei Kubernetes Events

Eventi normal

Gli eventi normal rappresentano operazioni attese o riuscite all'interno del cluster Kubernetes. Alcuni esempi: la creazione di un pod, il pull di un'immagine andato a buon fine o l'ingresso di nuovi nodi nel cluster. Questi eventi confermano che il control plane e le risorse stanno funzionando come previsto. Esaminando gli eventi normal, gli operator possono verificare che i workflow, come deployment o autoscaling, procedano senza errori e che il cluster operi senza intoppi.

Importanza: Nonostante il carattere informativo, gli eventi normal sono utili anche per il troubleshooting e per gli audit. Durante l'analisi di un problema, confermare la presenza o l'assenza di eventi normal aiuta a capire dove i processi possano essersi discostati dal percorso atteso. Ad esempio, l'assenza di un evento "Scheduled" durante la creazione di un pod può indicare un problema di scheduling, anche in assenza di warning.

Eventi warning

Gli eventi warning segnalano problemi o condizioni inattese nel cluster Kubernetes. Indicano questioni come scheduling fallito, errori di pull dell'immagine o violazioni dei vincoli di risorse. Vengono generati quando il control plane o i componenti sottostanti si trovano in situazioni che richiedono attenzione, ma non comportano necessariamente un guasto immediato della risorsa.

Importanza: Monitorare gli eventi warning è fondamentale per una gestione proattiva del cluster. Poiché evidenziano deviazioni dal funzionamento ordinario, spesso costituiscono il primo indicatore di configurazioni errate, carenze di risorse o problemi infrastrutturali.

Troubleshooting con i Kubernetes Events

1. Pod bloccato in Pending

Un pod che rimane nello stato Pending di solito significa che Kubernetes non riesce a collocarlo su un nodo o a completare uno dei passaggi di inizializzazione richiesti prima dell'avvio. Gli Events sono spesso il modo più rapido per individuare la causa principale, perché forniscono feedback diretto dallo scheduler e dal kubelet. Tra i motivi più comuni: risorse CPU o memoria insufficienti, PersistentVolumeClaim mancanti, taint dei nodi o regole di affinity non soddisfatte.

Gli operator possono ispezionare gli eventi relativi al pod con il seguente comando:

kubectl describe pod my-pod

Nella sezione Events, Kubernetes può mostrare messaggi come FailedScheduling con dettagli sul motivo per cui non è stato trovato un Node adatto. Ad esempio, un evento può indicare che i nodi non hanno risorse disponibili o che i taint impediscono lo scheduling. Questi messaggi permettono di restringere rapidamente l'indagine, senza dover analizzare in profondità i log dello scheduler.

Un altro approccio utile è filtrare gli Events di scheduling a livello di cluster:

kubectl get events --field-selector reason=FailedScheduling

Esaminando questi eventi, gli operator possono capire se il problema riguarda un singolo workload o coinvolge più pod nel cluster. Risolvere un Pod in Pending spesso richiede di scalare le risorse del cluster, modificare le resource request, sistemare le dipendenze di storage o aggiornare i vincoli di scheduling.

2. ImagePullBackOff o ErrImagePull

Gli eventi ImagePullBackOff ed ErrImagePull si verificano quando Kubernetes non riesce a scaricare un'immagine container da un registry. Le cause più comuni sono nomi di immagine errati, tag mancanti, errori di autenticazione o problemi di connettività di rete. Gli eventi forniscono messaggi dettagliati sul motivo del pull fallito, risultando essenziali per la diagnosi dei problemi di deployment.

Il modo più rapido per indagare è descrivere il Pod coinvolto:

kubectl describe pod my-pod

La sezione Events include spesso messaggi come Failed to pull image o Back-off pulling image. Possono evidenziare errori come riferimenti di immagine non validi, accesso al registry negato o credenziali mancanti. Se il registry richiede autenticazione, Kubernetes può anche segnalare che l'image pull secret configurato non è valido o non è disponibile.

Gli operator dovrebbero verificare nome e tag dell'immagine nella specifica del pod, confermare l'accessibilità al registry e assicurarsi che i secret richiesti siano presenti nel namespace corretto. Una volta corretto il problema, Kubernetes riprova automaticamente il pull dell'immagine e avvia correttamente il container.

3. CrashLoopBackOff

Un evento CrashLoopBackOff indica che un container si avvia correttamente ma va ripetutamente in crash poco dopo. Kubernetes tenta continuamente di riavviarlo, aumentando il ritardo tra i tentativi a ogni nuovo fallimento. La causa è di solito riconducibile a errori applicativi, configurazioni non valide, dipendenze mancanti o health check falliti.

Gli Events aiutano a identificare il pattern di riavvio e i guasti associati:

kubectl describe pod my-pod

L'output può mostrare eventi come Back-off restarting failed container. Mentre gli eventi rivelano il comportamento dei riavvii, i log del container di solito forniscono la causa dettagliata del crash.

Gli operator combinano spesso l'analisi degli Event con l'ispezione dei log:

kubectl logs my-pod

Riavvii frequenti possono indicare anche probe di liveness fallite o problemi di esaurimento delle risorse come gli OOM kill. In questi casi è importante rivedere la configurazione delle probe e i resource limit del container.

4. FailedScheduling

Gli eventi FailedScheduling si verificano quando lo scheduler di Kubernetes non riesce ad assegnare un pod a nessuno dei nodi disponibili. Sono tra gli eventi warning più frequenti nei cluster di produzione e in genere indicano carenze di risorse o regole di scheduling restrittive. Lo scheduler genera messaggi dettagliati sul motivo del fallimento del posizionamento.

Gli operator possono visualizzare gli eventi relativi allo scheduling con:

kubectl get events --field-selector reason=FailedScheduling

I messaggi tipici comprendono CPU o memoria insufficiente, mancata corrispondenza delle node affinity, conflitti di taint o restrizioni di topologia dei volumi. Ad esempio, un evento può segnalare che nessun nodo soddisfa le resource request del pod o che tutti i nodi sono contrassegnati con taint che il pod non può tollerare.

Comprendere il messaggio dell'evento è cruciale, perché FailedScheduling è un sintomo, non la causa principale. La risoluzione può richiedere di aumentare la capacità del cluster, modificare le resource request, aggiornare le regole di affinity o configurare correttamente le toleration. Poiché i problemi di scheduling possono interessare contemporaneamente molti workloads, monitorare questi Events aiuta gli operator a rilevare per tempo problemi di capacità o configurazione a livello di cluster.

Best practice per l'uso dei Kubernetes Events

Di seguito alcune pratiche utili da tenere presenti quando si lavora con gli eventi in Kubernetes.

1. Consulti gli Events fin dalle prime fasi del troubleshooting

I Kubernetes Events dovrebbero essere uno dei primi punti da consultare per diagnosticare problemi di cluster o applicativi. Offrono visibilità sui recenti cambi di stato, sui guasti e sulle azioni del control plane.

Comandi come kubectl describe o kubectl get events --sort-by=.metadata.creationTimestamp permettono di portare alla luce fallimenti di scheduling, riavvii di container o problemi di pull delle immagini. Esaminare gli eventi fin da subito aiuta a capire se il problema deriva dall'infrastruttura Kubernetes, dalla configurazione dei workloads o dall'applicazione stessa.

Poiché gli Events sono cronologici, permettono di ricostruire la sequenza di azioni che ha portato al guasto. È utile durante deployment, rollout o gestione degli incidenti.

2. Combini gli Events con log e metriche

Gli Events offrono contesto, ma danno il meglio quando vengono usati insieme a log e metriche. Gli Events spiegano cosa è accaduto a livello di risorsa Kubernetes, mentre i log rivelano il comportamento dettagliato di applicazioni o componenti. Le metriche aggiungono dati su prestazioni e utilizzo delle risorse nel tempo.

Ad esempio, un evento CrashLoopBackOff può indicare riavvii ripetuti del container, ma di solito servono i log applicativi per capire perché il container sia andato in crash. Le metriche possono rivelare l'esaurimento della memoria o il throttling della CPU che hanno contribuito al guasto. Correlare questi segnali consente di passare dal rilevamento del sintomo all'analisi della causa principale.

Le piattaforme di osservabilità spesso integrano Events, log e metriche in un'unica dashboard. Ciò consente ai team di tracciare i problemi attraverso più livelli dello stack.

3. Esporti gli Events per conservarli più a lungo

I Kubernetes Events sono temporanei per progettazione e in genere vengono conservati in etcd solo per un breve periodo. Per questo motivo, le informazioni diagnostiche possono scomparire rapidamente dopo un incidente. Esportare gli Events verso un sistema esterno garantisce che lo storico resti disponibile per analisi e audit.

Ad esempio, molte organizzazioni inoltrano gli Events verso piattaforme di osservabilità centralizzate come Elasticsearch, Loki, Splunk o servizi di monitoring cloud-native. Questi sistemi offrono conservazione più lunga, query avanzate, dashboard e correlazione con log e metriche.

Mantenere uno storico degli eventi è utile per le indagini post-mortem e per individuare pattern operativi ricorrenti.

4. Imposti alert solo sugli Events ad alto valore segnaletico

Non tutti i Kubernetes Events richiedono un alert. I cluster di grandi dimensioni generano grandi volumi di eventi informativi e impostare alert su ogni evento può creare rumore e portare ad alert fatigue. Meglio concentrare gli alert sugli eventi warning ad alto valore segnaletico, che indicano problemi operativi o rischi per il servizio.

Alcuni esempi: FailedScheduling ripetuti, CrashLoopBackOff, ImagePullBackOff o eventi Warning legati ai nodi. Filtrare gli alert in base a tipo, motivo, frequenza o risorse interessate aiuta a ridurre le notifiche inutili.

Un alerting efficace dovrebbe privilegiare i segnali azionabili rispetto al volume grezzo degli eventi.

5. Eviti di dipendere dal testo esatto dei messaggi

I messaggi dei Kubernetes Events sono pensati per essere leggibili dalle persone e possono cambiare tra versioni o implementazioni di Kubernetes. Dipendere dal testo esatto del messaggio in script, automazioni o regole di monitoring crea workflow fragili, destinati a rompersi dopo aggiornamenti o cambi di piattaforma.

Invece di confrontare il messaggio completo, faccia affidamento su campi strutturati come reason, type, oggetto coinvolto o label. Sono più stabili e pensati per il filtraggio programmatico e l'automazione. Ad esempio, intercettare il motivo FailedScheduling è più affidabile che cercare una specifica stringa di errore dello scheduler.

Oltre gli Events: rilevare e risolvere i problemi Kubernetes con PerfectScale

I Kubernetes Events indicano cosa è andato storto, ma agire di conseguenza su un ambiente di grandi dimensioni significa comunque un costante triage manuale. PerfectScale by DoiT colma questo divario rilevando e rimediando in modo autonomo ai problemi di resilienza e prestazioni che gli Events portano alla luce — come OOM kill, throttling della CPU, eviction e riavvii ripetuti dei pod — applicando al contempo un right-sizing continuo dei workloads, per mantenere i cluster stabili e garantire fino al 99,99% di disponibilità.

Funzionalità chiave di PerfectScale:

Remediation automatica dei problemi: individua e risolve all'istante i rischi di resilienza come OOM kill, throttling della CPU, eviction e riavvii dei pod, massimizzando l'uptime ed eliminando la latenza.
Prevenzione degli errori di configurazione: intercetta configurazioni sbagliate come request o limit di CPU e memoria mancanti, sospetti memory leak e workloads che raggiungono il numero massimo di repliche, prima che generino incidenti.
Hardening dell'infrastruttura: offre una visibilità d'insieme sui nodi per individuare in modo proattivo problemi come l'over-commitment dei nodi e node affinity o taint non corretti che portano a eviction e fallimenti di scheduling.
Prioritizzazione basata sull'impatto: classifica i problemi in tempo reale e allinea l'alerting ai suoi SLA e SLO, così i team possono concentrarsi sulle questioni che incidono maggiormente sulla continuità del servizio.
Alerting e ticketing integrati: invia notifiche istantanee tramite Slack, MS Teams o Datadog e permette di trasformare qualsiasi problema in un ticket con un solo clic.

Scopra come PerfectScale potenzia in modo autonomo la resilienza e le prestazioni di Kubernetes.