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. Sebbene GKE memorizzi i log, questi non vengono archiviati in modo permanente. Ad esempio, i log dei container GKE vengono rimossi quando viene rimosso il pod host, quando lo spazio sul disco su cui sono archiviati si esaurisce 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 il deployment, per impostazione predefinita, 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 standard ed errori standard provenienti dai processi containerizzati

  • Log di kubelet e del runtime del 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 tuo 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 degli eventi. Per informazioni dettagliate sugli audit log per GKE, consulta la documentazione relativa agli audit log per GKE. Gli audit log per GKE non possono essere disattivati.

  • Log di sistema, inclusi i log elencati in Log disponibili.

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

    Le seguenti limitazioni potrebbero impedire l'invio dei log delle applicazioni a Cloud Logging:

    • Per i log JSON, le chiavi JSON duplicate non sono supportate.
    • stream è una chiave riservata nella pipeline di logging di GKE. Una chiave stream nel log JSON dell'applicazione potrebbe causare un comportamento imprevisto e l'eliminazione dei log.
    • Cloud Logging ha un limite di dimensioni per LogEntry. Qualsiasi LogEntry che supera il limite di dimensioni viene ignorata per i log jsonPayload e troncata per i log textPayload.

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

  • 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 Kubernetes (kube-controller-manager).

Per scoprire di più su ciascuno di questi componenti del control plane, 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.

Puoi anche configurare un cluster Standard in modo che acquisisca solo i log di sistema e non raccolga 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 su container, pod e cluster, quindi invia i log a Cloud Logging utilizzando un agente basato su fluentbit.

Se i nodi GKE richiedono un throughput di log superiore a quello predefinito e il tuo cluster GKE Standard utilizza la versione del control plane 1.23.13-gke.1000 o successiva, puoi configurare GKE in modo da eseguire il deployment di una configurazione alternativa dell'agente Logging progettata per massimizzare il throughput di logging.

Per saperne di più, consulta Regola il throughput dei log.

Raccolta di log con fluentd o fluentbit personalizzati

L'agente Logging predefinito di GKE esegue il deployment e la gestione degli agenti che inviano i log dei tuoi cluster a Cloud Logging. I log vengono raccolti utilizzando un agente basato su fluentbit.

Sebbene non sia possibile personalizzare direttamente la configurazione di questo agente gestito, puoi eseguire il deployment di fluentd o fluentbit DaemonSet personalizzati per raccogliere i log delle applicazioni.

Per saperne di più sulle configurazioni di logging disponibili, consulta la sezione Log disponibili di questa pagina.

Raccolta dei log di Linux auditd per i nodi GKE

Puoi attivare gli 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 workload, ad esempio messaggi di errore, tentativi di accesso ed esecuzioni di file binari. Puoi utilizzare queste informazioni per eseguire il debug dei problemi o esaminare gli incidenti di sicurezza.

Per saperne di più, consulta Abilitazione dei log auditd 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 degli accessi di Logging

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

Accesso alle applicazioni

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

Accesso in visualizzazione utente

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

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

Accesso amministrativo 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 log, che viene di uso comune 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 di uno spazio dei nomi a un bucket di logging centralizzato.

Per saperne di più, consulta la guida al controllo degli accessi per Cloud Logging.

Best practice

  • Logging strutturato: l'agente Logging integrato con GKE leggerà i documenti JSON serializzati in stringhe di una sola riga e scritti nell'output standard o nell'errore standard e li invierà a Google Cloud Observability come voci di log strutturate.
    • Per maggiori dettagli sull'utilizzo di un agente Logging integrato, consulta Logging strutturato.
    • Puoi utilizzare i filtri dei log avanzati per filtrare i log in base ai campi del documento JSON.
    • I log generati con glog avranno i campi comuni analizzati, ad esempio severity, pid, source_file, source_line. Tuttavia, il payload del messaggio stesso non viene analizzato e viene visualizzato letteralmente nel messaggio di log risultante in Google Cloud Observability.
  • Gravità: per impostazione predefinita, i log scritti nell'output standard sono al livello INFO e i log scritti nell'errore standard sono al 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 saperne di più, consulta la panoramica su routing e archiviazione.

  • Avvisi: quando Logging registra un comportamento imprevisto, puoi utilizzare le metriche basate su log per configurare le policy di avviso. Per un esempio, consulta Crea una criterio di avviso su una metrica contatore. Per informazioni dettagliate sulle metriche basate su log, consulta Panoramica delle metriche basate su log.

  • Reporting degli errori: per raccogliere gli errori dalle applicazioni in esecuzione sui tuoi cluster, puoi utilizzare Error Reporting.

Log disponibili

Se scegli di inviare i log a Cloud Logging, devi inviare i log di sistema e, facoltativamente, puoi inviare i log da altre origini.

La tabella seguente indica i valori supportati per il flag --logging per i comandi create e update.

Sorgente log Valore --logging Log raccolti
Nessuno NONE Nessun log inviato a Cloud Logging; nessun agente di raccolta dei log installato nel cluster. Questo valore non è supportato per i cluster Autopilot.
Sistema SYSTEM Raccoglie i log da:
  • Tutti i pod in esecuzione negli spazi dei nomi kube-system, istio-system, knative-serving, gke-system e config-management-system.
  • Servizi non containerizzati, tra cui il 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.

Raccoglie anche gli eventi Kubernetes. Questo valore è obbligatorio per tutti i tipi di cluster.

Workload WORKLOAD Tutti i log generati dai container non di sistema in esecuzione sui nodi utente. Questo valore è attivo per impostazione predefinita, ma è facoltativo per tutti i tipi di cluster.
Server API API_SERVER Tutti i log generati da kube-apiserver. Questo valore è facoltativo per tutti i tipi di cluster.
Scheduler SCHEDULER Tutti i log generati da kube-scheduler. Questo valore è facoltativo per tutti i tipi di cluster.
Controller manager CONTROLLER_MANAGER Tutti i log generati da kube-controller-manager. Questo valore è facoltativo per tutti i tipi di cluster.
Horizontal Pod Autoscaler KCP_HPA

Esporta i log delle decisioni di suggerimento atomici e finali per ogni oggetto HPA nel cluster GKE.

Per maggiori dettagli, consulta Visualizza gli eventi del gestore della scalabilità automatica orizzontale dei pod.
Vertical Pod Autoscaler (anteprima) KCP_VPA

Esporta i log delle decisioni per ogni oggetto VPA nel cluster GKE.

Per saperne di più, consulta Visualizza gli eventi di Vertical Pod Autoscaler.
Connessioni di rete del control plane KCP_CONNECTION

Disponibile solo con GKE control plane authority

Log delle connessioni di rete in entrata per le istanze del control plane GKE. Per maggiori dettagli, consulta Verifica le connessioni di Google al control plane del cluster.
Eventi SSH del control plane KCP_SSHD

Disponibile solo con GKE control plane authority

Genera log per tutti gli eventi SSH, come l'accettazione della chiave pubblica e la chiusura della sessione, che si verificano quando il personale Google si connette alle istanze del control plane del cluster durante le richieste di assistenza o per altri accessi amministrativi.

Per maggiori dettagli, consulta Verifica le connessioni di Google al control plane del cluster.

Prezzi

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

Ti vengono addebitati i costi di archiviazione maturati quando esporti i log in un altro servizio Google Cloud , ad esempio BigQuery. Per i costi associati a Cloud Logging, consulta Prezzi.

Quota

I log del control plane consumano le quote di importazione per regione dell'API Cloud Logging. Prima di abilitare i log del control plane, controlla il picco di utilizzo recente di queste quote. Se hai molti cluster nello stesso progetto o stai già raggiungendo il limite della quota, puoi richiedere un aumento della quota prima di abilitare i log del control plane.

Se superi la quota regionale, le tue richieste di scrittura all'API Cloud Logging potrebbero essere rifiutate con un messaggio di errore "risorsa esaurita". Il superamento di questa quota influisce sull'osservabilità e sulla risoluzione dei problemi, ma non limita le operazioni del control plane GKE né influisce sui workload in esecuzione. Per i passaggi di risoluzione dei problemi, consulta Esamina l'utilizzo della quota dell'API Cloud Logging.

Controlli di accesso

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

Archiviandoli in un bucket di log separato con accesso limitato, i log del control plane 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 control plane per motivi di privacy o sicurezza, l'archiviazione in un bucket di log separato con accesso limitato consente di eliminare i log senza influire su quelli di altri componenti o servizi.

Passaggi successivi