Informazioni sui log di GKE

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

Panoramica

I log di GKE inviati a Cloud Logging vengono archiviati in un datastore dedicato e permanente. I log sono archiviati da GKE, ma non 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 esaurisce lo spazio disponibile o quando vengono sostituiti con log più recenti. I log di sistema vengono periodicamente rimossi per liberare spazio per nuovi log. Gli eventi del cluster vengono rimossi dopo un'ora.

Agente Logging GKE

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

  • Log di output ed errori standard di processi containerizzati

  • log di runtime di kubelet e container

  • Log per i componenti di sistema, ad esempio 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 cluster e li archivia in Cloud Logging:

  • Gli audit log includono il log delle attività di amministrazione, il log di accesso ai dati e il log eventi. Per informazioni dettagliate sugli audit log per GKE, consulta la documentazione sugli audit log 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 i problemi di arresti anomali, avvii non riusciti, problemi 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 degli utenti.

Facoltativamente, GKE può raccogliere tipi aggiuntivi 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 controller del controller includono tutti i log generati dal gestore del controller 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

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

I log di sistema e delle applicazioni vengono inviati 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 1.15.7 di GKE, puoi configure un cluster Standard per acquisire solo i log di sistema e non per 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 automaticamente il deployment e la gestione di un agente Cloud Logging dedicato. Viene eseguito su tutti i nodi GKE di un cluster per raccogliere i log, aggiunge metadati utili sul container, sul pod e sul cluster e invia i log a Cloud Logging utilizzando un agente basato su fluentbit.

Se i nodi GKE richiedono una velocità effettiva di log superiore a quella predefinita e il tuo cluster GKE Standard utilizza il piano di controllo versione 1.23.13-gke.1000 o successiva, puoi configurare GKE per 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 fluente o fluentbit personalizzato

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, viene utilizzato fluentd o fluentbit. A partire da GKE 1.17, i log vengono raccolti utilizzando un agente basato su fluentbit. I cluster GKE che utilizzano versioni precedenti a GKE 1.17 utilizzano un agente fluente. 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

  • usando specifiche impostazioni relative al rendimento

  • formattazione dei log personalizzata

Raccolta dei log auditd di Linux per i nodi GKE

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, ad esempio messaggi di errore, tentativi di accesso ed esecuzioni binarie. Puoi utilizzare queste informazioni per eseguire il debug dei problemi 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 del cluster Kubernetes e delle operazioni sui cluster GKE, consulta Audit logging.

Controllo dell'accesso a Logging

Ci sono due aspetti del controllo dell'accesso al logging: l'accesso alle applicazioni e l'accesso degli utenti. Cloud Logging fornisce ruoli IAM (Identity and Access Management) che puoi utilizzare per concedere l'accesso appropriato.

Accesso alle applicazioni

Le applicazioni devono avere le autorizzazioni per scrivere log in Cloud Logging, che viene concesso assegnando il ruolo IAM roles/logging.logWriter all'account di servizio associato al pool di nodi sottostante.

Accesso in visualizzazione utente

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

Per ulteriori informazioni sulle autorizzazioni e i ruoli, consulta la guida Controllo dell'accesso. Puoi anche consultare le best practice per Cloud Audit Logs, applicabili anche a Cloud Logging in generale.

Accesso amministrativo dell'utente

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, comunemente 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 al controllo dell'accesso per Cloud Logging.

best practice

  • Logging strutturato: l'agente di logging integrato con GKE leggerà i documenti JSON serializzati su stringhe a riga singola e scritti nell'output standard o in un errore standard e li invierà all'osservabilità di Google Cloud come voci di log strutturate.
    • Per ulteriori dettagli sull'utilizzo di un agente Logging integrato, consulta Logging strutturato.
    • Puoi utilizzare Filtri di log avanzati per filtrare i log in base ai campi del documento JSON.
    • I 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 sono a livello INFO, mentre i log scritti nell'errore standard sono 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 proprio formato e la propria struttura. Per ulteriori informazioni, consulta Panoramica del routing e dell'archiviazione.
  • Avvisi: quando Logging registra comportamenti imprevisti, puoi utilizzare metriche basate su log per configurare criteri di avviso. Per un esempio, consulta Creare un criterio di avviso su una metrica dei contatori. Per informazioni dettagliate sulle metriche basate su log, consulta Panoramica delle metriche basate su log.
  • Report sugli errori: per raccogliere gli errori delle applicazioni in esecuzione sui tuoi cluster, puoi utilizzare Error Reporting.

Log del piano di controllo

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

Requisiti

L'invio a Cloud Logging dei log emessi dai componenti del piano di controllo Kubernetes richiede la versione 1.22.0 o successiva del piano di controllo GKE e 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 utilizzano la quota "Richieste di scrittura al minuto" dell'API Cloud Logging. Prima di abilitare i log del piano di controllo, controlla l'utilizzo picco recente di quella quota. Se nello stesso progetto sono presenti molti cluster o stai già per raggiungere il limite quota, puoi richiedere un aumento del limite della 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, archiviarli in un bucket di log separato con accesso limitato consente di eliminare i log senza influire sui log di altri componenti o servizi.