Informazioni sui log di GKE

Questa pagina fornisce una panoramica delle opzioni di logging disponibili in Google Kubernetes Engine (GKE).

Panoramica

I log GKE inviati a Cloud Logging vengono archiviati in un datastore dedicato permanente. I log sono archiviati in GKE, ma non vengono archiviati in modo permanente. Ad esempio, i log dei container GKE vengono rimossi quando viene rimosso il pod host, quando il disco su cui sono archiviati si esaurisce lo spazio disponibile o quando vengono sostituiti da log più recenti. I log di sistema vengono rimossi periodicamente per liberare spazio per i nuovi log. Gli eventi del cluster vengono rimossi dopo un'ora.

Agente logging GKE

Per i log dei container e di sistema, GKE esegue per impostazione predefinita il deployment di un agente di logging per nodo che legge i log dei container, aggiunge metadati utili e li archivia in Cloud Logging. L'agente Logging di GKE controlla i log dei container nelle seguenti origini:

  • Log di output ed errori standard dei processi containerizzati

  • Log di runtime di kubelet e container

  • Log per i componenti di sistema, come gli script di avvio delle VM

Per gli eventi, GKE utilizza un deployment nello spazio dei nomi kube-system che raccoglie automaticamente gli eventi e li invia a Logging.

Quali log vengono raccolti

Per impostazione predefinita, GKE raccoglie diversi tipi di log dal tuo cluster e li archivia in Cloud Logging:

  • Gli log di controllo includono il log delle attività di amministrazione, il log degli accessi ai dati e il log degli eventi. Per informazioni dettagliate sugli audit log per GKE, consulta la documentazione su Audit Logs per GKE. Impossibile disabilitare gli audit log per GKE.

  • I log di sistema includono i log delle seguenti origini:

    • Tutti i pod in esecuzione negli spazi dei nomi kube-system, istio-system, knative-serving, gke-system e config-management-system.

    • Servizi chiavi non containerizzati, tra cui runtime docker/containerd, kubelet, kubelet-monitor, node-problem-detector e kube-container-runtime-monitor.

    • L'output delle porte seriali del nodo, se i metadati dell'istanza VM serial-port-logging-enable sono impostati su true. A partire da GKE 1.16-13-gke.400, l'output della porta seriale per i nodi viene raccolto dall'agente Logging. Per disabilitare il logging dell'output della porta seriale, imposta --metadata serial-port-logging-enable=false durante la creazione del cluster. L'output della porta seriale è utile per risolvere problemi di arresti anomali, avvii non riusciti, di avvio o di arresto dei nodi GKE. La disattivazione di questi log potrebbe rendere più difficile la risoluzione dei problemi.

  • I log delle applicazioni includono tutti i log generati da container non di sistema in esecuzione sui nodi utente.

Facoltativamente, GKE può raccogliere altri tipi di log da determinati componenti del piano di controllo Kubernetes e archiviarli in Cloud Logging:

  • I log del server API includono tutti i log generati dal server API Kubernetes (kube-apiserver).

  • I log dello scheduler includono tutti i log generati dallo scheduler Kubernetes (kube-scheduler).

  • I log del gestore dei controller includono tutti i log generati dal gestore dei controller di Kubernetes (kube-controller-manager).

Per saperne di più su ciascuno di questi componenti del piano di controllo, consulta Architettura dei cluster GKE.

Raccolta dei log in corso

Quando crei un nuovo cluster GKE, l'integrazione con Cloud Logging è abilitata per impostazione predefinita.

I log di sistema e delle applicazioni vengono consegnati al router dei log in Cloud Logging.

Da qui, i log possono essere importati in Cloud Logging, esclusi o esportati in BigQuery, Pub/Sub o Cloud Storage.

A partire dalla versione di GKE 1.15.7, puoi configure un cluster Standard per acquisire solo i log di sistema e non raccogliere i log delle applicazioni. Sia per i cluster Autopilot che per quelli Standard, i filtri di esclusione consentono di ridurre il volume dei log inviati a Cloud Logging.

Velocità effettiva di logging

Quando il logging di sistema è abilitato, viene eseguito il deployment e la gestione automatici di un agente Cloud Logging dedicato. Viene eseguito su tutti i nodi GKE di un cluster per raccogliere i log, aggiunge metadati utili su container, pod e cluster, quindi invia i log a Cloud Logging utilizzando un agente basato su fluent.

Se alcuni nodi GKE richiedono una velocità effettiva di log superiore a quella predefinita e il tuo cluster GKE Standard utilizza la versione del piano di controllo 1.23.13-gke.1000 o successiva, puoi configurare GKE in modo che esegua il deployment di una configurazione alternativa dell'agente Logging progettata per massimizzare la velocità effettiva di logging.

Per ulteriori informazioni, consulta Regolare la velocità effettiva dei log.

Raccolta di log con fluentd o fluentbit personalizzati

L'agente Logging predefinito di GKE fornisce una soluzione gestita per eseguire il deployment e gestire gli agenti che inviano i log per i tuoi cluster a Cloud Logging. A seconda della versione del piano di controllo GKE, per raccogliere i log vengono utilizzati fluentd o fluentbit. A partire da GKE 1.17, i log vengono raccolti utilizzando un agente basato su fluentbit. I cluster GKE che usano versioni precedenti a GKE 1.17 usano un agente "flud-based". Se vuoi modificare il comportamento predefinito degli fluentdagenti, puoi eseguire un agente fluentd personalizzato.

I casi d'uso comuni includono:

  • rimuovendo i dati sensibili dai log.

  • raccolta di log aggiuntivi non scritti in STDOUT o STDERR

  • utilizzando impostazioni specifiche relative alle prestazioni

  • formattazione personalizzata dei log

Raccolta di log auditd di Linux per i nodi GKE in corso...

Puoi abilitare audit log del sistema operativo dettagliati sui nodi GKE che eseguono Container-Optimized OS. I log del sistema operativo sui nodi forniscono informazioni preziose sullo stato del cluster e dei carichi di lavoro, come messaggi di errore, tentativi di accesso ed esecuzioni binarie. Puoi utilizzare queste informazioni per eseguire il debug o esaminare gli incidenti di sicurezza.

Per saperne di più, consulta Abilitazione degli audit log di Linux sui nodi GKE.

Audit log di GKE

Per informazioni dettagliate sulle voci di log che si applicano ai tipi di risorse Cluster Kubernetes e Operazioni cluster GKE, consulta Audit logging.

Controllo dell'accesso al logging

Controllo dell'accesso ai log presenta due aspetti: accesso alle applicazioni e accesso utente. Cloud Logging fornisce ruoli IAM (Identity and Access Management) che puoi utilizzare per concedere l'accesso appropriato.

Accesso alle applicazioni

Le applicazioni devono disporre delle autorizzazioni per scrivere i log in Cloud Logging, che vengono concesse assegnando il ruolo IAM roles/logging.logWriter all'account di servizio collegato al pool di nodi sottostante.

Accesso in visualizzazione utente

Per visualizzare i log nel tuo progetto, devi avere il ruolo roles/logging.viewer. Se devi accedere ai log di accesso ai dati, devi disporre dell'autorizzazione IAM logging.privateLogViewer.

Per ulteriori informazioni su autorizzazioni e ruoli, consulta la guida Controllo dell'accesso. Puoi inoltre consultare le best practice per Cloud Audit Logs, che si applicano anche a Cloud Logging in generale.

Accesso amministratore utenti

I ruoli IAM roles/logging.configWriter e roles/logging.admin forniscono le funzionalità amministrative. Il ruolo roles/logging.configWriter è necessario per creare un sink di logging, di solito utilizzato per indirizzare i log a un progetto specifico o centralizzato. Ad esempio, potresti voler utilizzare un sink di logging insieme a un filtro di logging per indirizzare tutti i log per uno spazio dei nomi a un bucket di logging centralizzato.

Per saperne di più, consulta la guida sul controllo dell'accesso per Cloud Logging.

Best practice

  • Logging strutturato:l'agente di logging integrato con GKE leggerà i documenti JSON serializzati su stringhe su una sola riga e scritti su output standard o errore standard e li invia a Google Cloud Observability come voci di log strutturati.
    • Consulta Logging strutturato per ulteriori dettagli su come lavorare con un agente Logging integrato.
    • Puoi utilizzare Filtri di log avanzati per filtrare i log in base ai campi del documento JSON.
    • Nei log generati con glog verranno analizzati i campi comuni, ad esempio severity, pid, source_file, source_line. Tuttavia, il payload del messaggio non è analizzato e viene visualizzato testualmente nel messaggio di log risultante in Google Cloud Observability.
  • Gravità: per impostazione predefinita, i log scritti nell'output standard si trovano a livello INFO, mentre i log scritti con l'errore standard si trovano a livello ERROR. I log strutturati possono includere un campo severity, che definisce la gravità del log.
  • Esportazione in BigQuery: per ulteriori analisi, puoi esportare i log in servizi esterni, come BigQuery o Pub/Sub. I log esportati in BigQuery mantengono il formato e la struttura. Per ulteriori informazioni, consulta Panoramica su routing e archiviazione.
  • Avvisi: quando Logging registra comportamenti imprevisti, puoi utilizzare le metriche basate su log per configurare i criteri di avviso. Ad esempio, consulta Creare un criterio di avviso su una metrica del contatore. Per informazioni dettagliate sulle metriche basate su log, consulta Panoramica delle metriche basate su log.
  • Error Reporting: per raccogliere gli errori dalle applicazioni in esecuzione sui tuoi cluster, puoi utilizzare Error Reporting.

Log del piano di controllo

Puoi configurare un cluster GKE per inviare a Cloud Logging i log emessi dal server API Kubernetes, dallo scheduler e dal gestore del controller.

Requisiti

L'invio a Cloud Logging dei log emessi dai componenti del piano di controllo Kubernetes richiede il piano di controllo GKE versione 1.22.0 o successiva e richiede l'abilitazione della raccolta dei log di sistema.

Configurazione della raccolta dei log del piano di controllo

Consulta le istruzioni per configurare il supporto del logging per un nuovo cluster o per un cluster esistente.

Prezzi

I log del piano di controllo GKE vengono esportati in Cloud Logging. Si applicano i prezzi di Cloud Logging.

Quota

I log del piano di controllo consumano la quota "Richieste di scrittura al minuto" dell'API Cloud Logging. Prima di abilitare i log del piano di controllo, controlla l'utilizzo massimo recente di quella quota. Se hai molti cluster nello stesso progetto o stai già per raggiungere il limite della quota, puoi richiedere un aumento del limite di quota prima di abilitare i log del piano di controllo.

Controlli di accesso

Se vuoi limitare l'accesso all'interno della tua organizzazione ai log del piano di controllo Kubernetes, puoi creare un bucket di log separato con controlli dell'accesso più limitati.

Archiviandoli in un bucket di log separato con accesso limitato, i log del piano di controllo nel bucket di log non saranno automaticamente accessibili a chiunque abbia accesso roles/logging.viewer al progetto. Inoltre, se decidi di eliminare determinati log del piano di controllo per motivi di privacy o sicurezza, archiviandoli in un bucket di log separato con accesso limitato puoi eliminare i log senza influire su quelli di altri componenti o servizi.