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 viene rimosso il pod host, quando lo spazio su disco in 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 di 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 di logging GKE controlla i log dei container nelle seguenti origini:

  • Log di output ed errori standard provenienti da processi containerizzati

  • Log di kubelet e del runtime del container

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

  • Gli audit log 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 relativa agli audit log per GKE. Gli audit log per GKE non possono essere disabilitati.

  • I log di sistema , inclusi i log elencati nei log disponibili.

  • I log delle applicazioni includono tutti i log generati da 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 GKE. Una chiave stream nel log JSON dell'applicazione potrebbe causare un comportamento imprevisto e la perdita di log.
    • Cloud Logging ha un limite di dimensioni per LogEntry. Qualsiasi LogEntry che superi il limite di dimensioni viene eliminato per i log jsonPayload e troncato per i log textPayload.

Facoltativamente, GKE può raccogliere altri tipi di log da determinati componenti del control plane 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 del gestore dei controller includono tutti i log generati dal gestore dei controller Kubernetes (kube-controller-manager).

Per saperne 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. Per i cluster Autopilot e Standard, i filtri di esclusione consentono di ridurre il volume di log inviati a Cloud Logging.

Velocità effettiva di logging

Quando il logging di sistema è abilitato, 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 sul container, sul pod e sul cluster e poi invia i log a Cloud Logging utilizzando un agente basato su fluentbit.

Se alcuni nodi GKE richiedono una velocità effettiva di log superiore a quella predefinita e il cluster GKE Standard utilizza la versione del control plane 1.23.13-gke.1000 o successive, 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 saperne di più, consulta Modificare la velocità effettiva dei log.

Raccolta di log con fluentd o fluentbit personalizzati

L'agente di logging predefinito di GKE esegue il deployment e la gestione degli agenti che inviano i log dei 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 del tuo DaemonSet fluentd o fluentbit personalizzato 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 auditd di Linux per i nodi GKE

Puoi abilitare gli audit log dettagliati del sistema operativo 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 dei problemi o esaminare gli incidenti di sicurezza.

Per saperne di più, consulta Abilitare gli audit log 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 a Logging

Esistono due aspetti del controllo dell'accesso a Logging: l'accesso alle applicazioni e l'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 devono disporre 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 alla visualizzazione utente

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

Per saperne di più 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 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, che è 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 dell'accesso per Cloud Logging.

Best practice

  • Logging strutturato: l'agente di logging integrato con GKE leggerà i documenti JSON serializzati in stringhe a riga singola 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 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 letteralmente nel messaggio di log risultante in Google Cloud Observability.
  • Gravità: per impostazione predefinita, i log scritti nell'output standard sono a livello INFO 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 un'analisi aggiuntiva, 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 Logging registra un comportamento imprevisto, puoi utilizzare le metriche basate su log per configurare i criteri di avviso. Per un esempio, consulta Creare una criterio di avviso per una metrica contatore. Per informazioni dettagliate sulle metriche basate su log, consulta Panoramica delle metriche basate su log.

  • Segnalazione degli errori: per raccogliere gli errori dalle applicazioni in esecuzione sui 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, inclusi i 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 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 dei controller 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 raccomandazione atomiche e finali per ogni oggetto HPA nel cluster GKE.

Per maggiori dettagli, vedi Visualizzare gli eventi di Horizontal Pod Autoscaler.
Connessioni di rete del control plane KCP_CONNECTION

Disponibile solo con l'autorità del control plane GKE

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

Disponibile solo con l'autorità del control plane GKE

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 control plane del cluster durante i casi di assistenza o per altri accessi amministrativi.

Per maggiori dettagli, vedi Verificare le connessioni Google al control plane del cluster.

Prezzi

I log 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 Google Cloud servizio, ad esempio BigQuery. Per i costi associati a Cloud Logging, consulta Prezzi.

Quota

I log del control plane consumano la quota "Richieste di scrittura al minuto" dell'API Cloud Logging. Prima di abilitare i log del control plane, controlla l'utilizzo di picco recente di questa quota. Se hai molti cluster nello stesso progetto o ti stai già avvicinando al limite di quota, puoi richiedere un aumento del limite di quota prima di abilitare i log del control plane.

Controlli di accesso

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

Se li archivi in un bucket di log separato con accesso limitato, i log del control plane nel bucket di log non saranno accessibili automaticamente 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 sui log di altri componenti o servizi.

Passaggi successivi