Risoluzione Avanzata dei Problemi: Approfondimento su Log, Eventi e Metriche di Kubernetes

La risoluzione dei problemi in Kubernetes diventa più semplice quando separi tre domande: cosa ha detto il container, cosa ha fatto il control plane e cosa mostrano le metriche? Log, eventi e metriche rispondono a diverse parti dello stesso incidente.

Gli esempi seguenti mostrano come utilizzare tutti e tre insieme quando un pod si blocca, un'immagine non viene scaricata, un carico di lavoro non può essere schedulato o un servizio sembra sano ma risponde lentamente.

Log di Kubernetes: Le Fondamenta del Debugging

I log sono registrazioni dettagliate di ciò che un'applicazione o un processo di sistema sta facendo. In Kubernetes, i log sono generati dai container in esecuzione all'interno dei tuoi pod. Sono spesso il primo posto dove guardare quando un'applicazione non si comporta come previsto.

Accesso ai Log dei Container

Il comando kubectl logs è il tuo strumento principale per recuperare i log dai pod. È versatile e offre diverse opzioni utili.

• Ottenere log da un singolo container in un pod:

  kubectl logs <nome-pod>
  

  Se un pod ha un solo container, questo comando funziona direttamente.

• Ottenere log da un container specifico in un pod multi-container:

  kubectl logs <nome-pod> -c <nome-container>
  

• Visualizzare log da un'istanza precedente di un container bloccato: Se un container è stato riavviato a causa di un errore, puoi visualizzare i suoi log prima del riavvio usando il flag --previous:

  kubectl logs <nome-pod> --previous
  

• Seguire i log in tempo reale: Simile a tail -f, il flag -f (o --follow) ti permette di trasmettere in streaming le nuove voci di log man mano che vengono generate, il che è prezioso per il debug di problemi in tempo reale.

  kubectl logs -f <nome-pod> -c <nome-container>
  

• Filtrare i log per tempo: Puoi specificare quante righe dalla fine recuperare (--tail) o i log da una durata specifica (--since).

  kubectl logs <nome-pod> --tail=100 # Ultime 100 righe
  kubectl logs <nome-pod> --since=1h # Log dell'ultima ora
  

Soluzioni di Logging Centralizzato

Mentre kubectl logs è eccellente per il debug immediato, non è pratico per la gestione dei log su larga scala e a lungo termine. Per gli ambienti di produzione, le soluzioni di logging centralizzato sono essenziali. Queste soluzioni tipicamente coinvolgono:

• Agenti di Log: Esecuzione di un agente (es. Fluentd, Fluent Bit, Filebeat) su ogni nodo per raccogliere i log da tutti i pod.
• Archiviazione e Indicizzazione dei Log: Archiviazione dei log in un repository centrale (es. Elasticsearch, Loki, Splunk).
• Visualizzazione e Analisi dei Log: Fornitura di un'interfaccia per cercare, filtrare e visualizzare i log (es. Kibana, Grafana, UI di Splunk).

Best Practice per il Logging

• Logging Strutturato: Emetti i log in un formato strutturato (es. JSON) per renderli facilmente analizzabili e interrogabili dai sistemi di logging centralizzato.
• Livelli di Log Appropriati: Usa diversi livelli di log (DEBUG, INFO, WARN, ERROR, FATAL) per categorizzare i messaggi e controllare la verbosità.
• Evita Informazioni Sensibili: Non registrare dati sensibili (password, PII) direttamente.

Eventi di Kubernetes: Il Narratore del Cluster

Gli eventi di Kubernetes sono registrazioni di cambiamenti di stato e operazioni che si verificano all'interno del cluster. Forniscono informazioni cruciali su ciò che Kubernetes stesso sta facendo (o non riesce a fare) in risposta allo stato desiderato. Gli eventi sono preziosi per capire perché i pod non vengono schedulati, le immagini non vengono scaricate o i volumi non vengono montati.

Accesso agli Eventi di Kubernetes

• Eventi a livello di cluster:

  kubectl get events
  

  Questo comando mostra tutti gli eventi recenti nel namespace corrente. Puoi aggiungere --all-namespaces per vedere gli eventi in tutto il cluster.

  Un output tipico di un evento appare così:

  LAST SEEN   TYPE      REASON      OBJECT                         MESSAGE
  3m21s       Normal    Scheduled   pod/my-app-789c6f66-abcde      Assegnato con successo default/my-app-789c6f66-abcde a node01
  3m20s       Normal    Pulling     pod/my-app-789c6f66-abcde      Scaricamento immagine "example/my-app:1.2.3"
  2m58s       Warning   BackOff     pod/my-app-789c6f66-abcde      Back-off riavvio del container fallito app
  

• Eventi per un singolo oggetto:

  kubectl describe pod <nome-pod>
  

  La sezione Events in fondo è spesso il modo più veloce per vedere problemi di scheduling, scaricamento, montaggio e riavvio per un singolo pod.

• Ordinare gli eventi per tempo di creazione:

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

Cosa Ti Dicono Solitamente gli Eventi

Gli eventi sono record di breve durata, quindi sono ottimali per guasti recenti. Cerca queste ragioni comuni:

• FailedScheduling: Lo scheduler non ha potuto posizionare il pod. Controlla i selettori di nodo, le taint, le toleration, le richieste di risorse e la capacità disponibile.
• ImagePullBackOff o ErrImagePull: Kubernetes non ha potuto scaricare l'immagine. Controlla il nome dell'immagine, il tag, l'accesso al registro e il segreto per il pull dell'immagine.
• FailedMount: Un volume non ha potuto montare. Controlla il binding del PVC, la storage class, i permessi del nodo e lo stato del driver CSI.
• BackOff: Un container continua a fallire. Abbina l'evento con kubectl logs --previous.

Metriche di Kubernetes: La Vista delle Risorse

Le metriche ti dicono se il cluster ha abbastanza CPU, memoria e capacità per il carico di lavoro. Ti aiutano anche a separare i bug dell'applicazione dalla pressione delle risorse.

Controlli Rapidi con metrics-server

Se metrics-server è installato, usa kubectl top:

kubectl top nodes
kubectl top pods
kubectl top pod <nome-pod> --containers

Un uso elevato di memoria del pod vicino al limite del container spesso coincide con riavvii OOMKilled. Una CPU elevata del nodo può spiegare la latenza anche quando i log del pod sembrano puliti.

Metriche più Approfondite con Prometheus

In produzione, Prometheus e Grafana solitamente forniscono la vista storica che manca a kubectl top. Segnali utili includono:

• Riavvii dei container nel tempo.
• Limitazione della CPU per container con limiti di CPU bassi.
• Working set della memoria confrontato con i limiti.
• Pod in attesa per namespace.
• Latenza delle richieste al server API e tasso di errore.
• Pressione del disco del nodo, pressione della memoria e saturazione della rete.

Correlare Log, Eventi e Metriche

Usa una finestra temporale e passa dal sintomo alla causa:

1. Controlla lo stato del pod:

   kubectl get pod <nome-pod> -o wide
   kubectl describe pod <nome-pod>
   

2. Leggi i log correnti e precedenti:

   kubectl logs <nome-pod> -c <nome-container>
   kubectl logs <nome-pod> -c <nome-container> --previous
   

3. Controlla gli eventi recenti del namespace:

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

4. Confronta l'utilizzo delle risorse:

   kubectl top pod <nome-pod> --containers
   kubectl top node
   

Ad esempio, un pod con CrashLoopBackOff, log precedenti che terminano con un errore di memoria insufficiente e metriche che mostrano la memoria vicina al limite indicano un problema di limite di memoria o di memoria dell'applicazione. Un pod bloccato in Pending con eventi FailedScheduling e bassa capacità del nodo indica pressione di scheduling, non un bug del container.

Conclusione

Non eseguire il debug di Kubernetes basandoti su un solo segnale. I log spiegano il comportamento dell'applicazione, gli eventi spiegano le decisioni del control plane e le metriche spiegano la pressione delle risorse. Quando li allinei per tempo e nome dell'oggetto, le cause profonde diventano molto più facili da separare dai sintomi.