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 stesso memorizzi i log, questi non vengono archiviati in modo permanente. Ad esempio, i log dei container GKE vengono rimossi quando il pod di hosting viene rimosso, 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 cluster vengono rimossi dopo un'ora.

Agente di logging GKE

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

  • Log di output ed errori standard provenienti dai processi containerizzati

  • Log di runtime di kubelet e del container

  • Log per i componenti di sistema, ad esempio gli script di avvio della 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:

  • I log di controllo includono il log delle attività di amministrazione, il log degli accessi ai dati e il log degli eventi. Per informazioni dettagliate sui log di controllo per GKE, consulta la documentazione relativa ai log di controllo 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.

    I seguenti limiti potrebbero comportare l'invio non riuscito 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 ignorato per i log jsonPayload e troncato per i log textPayload.

Se vuoi, GKE può raccogliere tipi aggiuntivi di log da alcuni componenti del piano di controllo Kubernetes e archiviarli in Cloud Logging:

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

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

  • I log di Controller Manager includono tutti i log generati da Kubernetes Controller Manager (kube-controller-manager).

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

Raccogliere i 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, escludenti o esportati in BigQuery, Pub/Sub o Cloud Storage.

Puoi anche configurare un cluster standard in modo da 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 ti consentono di ridurre il volume dei log inviati a Cloud Logging.

Velocità effettiva di registrazione

Quando la registrazione di sistema è attivata, viene eseguito il deployment e la gestione automatica di un agente Cloud Logging dedicato. Viene eseguito su tutti i nodi GKE di un cluster per raccogliere i log, aggiunge metadati utili relativi a container, pod e cluster e poi invia i log a Cloud Logging utilizzando un agente basato su FluentBit.

Se alcuni nodi GKE richiedono più del throughput dei log predefinito e il tuo cluster GKE Standard utilizza la versione del piano di controllo 1.23.13-gke.1000 o successiva, puoi configurare GKE per eseguire il deployment di una configurazione alternativa dell'agente Logging progettata per massimizzare il throughput del logging.

Per ulteriori informazioni, vedi Regolare il throughput dei log.

Raccolta dei log con Fluentd o Fluentbit personalizzati

L'agente di logging predefinito di GKE fornisce una soluzione gestita per eseguire il deployment e gestire gli agenti che inviano i log dei tuoi cluster a Cloud Logging. I log vengono raccolti utilizzando un agente basato su FluentBit.

Raccolta dei log auditd di Linux per i nodi GKE

Puoi attivare i log di controllo 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 di binari. Puoi utilizzare queste informazioni per eseguire il debug dei problemi o esaminare gli incidenti di sicurezza.

Per scoprire di più, consulta Abilitazione degli audit log 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 del cluster GKE, vai a Log di controllo.

Controllo dell'accesso a Logging

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

Accesso alle applicazioni

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

Accesso alla visualizzazione utente

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

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

Accesso amministrativo utenti

I ruoli IAM roles/logging.configWriter e roles/logging.admin forniscono le funzionalità di amministrazione. Il ruolo roles/logging.configWriter è obbligatorio per creare un'area di destinazione per i log, che viene comunemente utilizzata 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 legge i documenti JSON serializzati in stringhe di una riga e li scrive nell'output standard o nell'errore standard, per poi inviarli a Google Cloud Observability come voci di log strutturate.
    • Per maggiori dettagli sull'utilizzo di un agente di 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 verbatim nel messaggio di log risultante in Google Cloud Observability.
  • Gravità: per impostazione predefinita, i log scritti nell'output standard sono a livelloINFO e 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 formato e la struttura. Per ulteriori informazioni, consulta la panoramica su routing e archiviazione.
  • Avvisi:quando la registrazione registra un comportamento imprevisto, puoi utilizzare le metriche basate sui log per configurare i criteri di avviso. Per un esempio, consulta Creare un criterio di avviso per una metrica del contatore. Per informazioni dettagliate sulle metriche basate su log, consulta la panoramica delle metriche basate su log.
  • Error Reporting: per raccogliere gli errori delle 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 log da origini aggiuntive.

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 quanto segue:
  • Tutti i pod in esecuzione negli spazi dei nomi kube-system, istio-system, knative-serving, gke-system e config-management-system.
  • Servizi non in container, 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.

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

Carichi di lavoro WORKLOAD Tutti i log generati da 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.
Gestore del controller CONTROLLER_MANAGER Tutti i log generati da kube-controller-manager. Questo valore è facoltativo per tutti i tipi di cluster.
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 Verificare le connessioni di Google al piano di controllo del cluster.
Eventi SSH del piano di controllo 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 di Google si connette alle istanze del piano di controllo del cluster durante le richieste di assistenza o per altro accesso amministrativo.

Per maggiori dettagli, consulta Verificare le connessioni di Google al piano di controllo del cluster.

Log abilitati per impostazione predefinita in GKE Enterprise

Quando crei un nuovo cluster GKE su Google Cloud, i log del carico di lavoro sono abilitati per impostazione predefinita per tutti i cluster Autopilot, ma possono essere disattivati.

Per i progetti GKE Enterprise, altri log utili vengono attivati per impostazione predefinita se ti registri a un parco risorse durante la creazione del cluster.

Nella tabella seguente, un segno di spunta () indica quali log sono abilitati per impostazione predefinita quando crei e registri un nuovo cluster in un progetto con GKE Enterprise abilitato:

Nome log Autopilot Standard
Sistema
Carichi di lavoro -
Server API
Scheduler
Gestore del controller
Connessioni di rete del control plane
Eventi SSH del piano di controllo

I log del control plane (server API, Scheduler e Controller Manager) comportano costi di Cloud Logging.

Prezzi

I log del control plane 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 piano di controllo utilizzano la quota "Richieste di scrittura al minuto" dell'API Cloud Logging. Prima di attivare i log del piano di controllo, controlla il picco di utilizzo recente di questa quota. Se hai molti cluster nello stesso progetto o stai già per raggiungere il limite di quota, puoi richiedere un aumento del limite di quota prima di attivare 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 di accesso più limitati.

Se li archivi in un bucket dei log separato con accesso limitato, i log del piano di controllo nel bucket dei log non saranno automaticamente accessibili a chiunque abbia accessoroles/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 dei log separato con accesso limitato ti consente di eliminarli senza influire sui log di altri componenti o servizi.