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.
Log di sistema, inclusi quelli elencati nei log disponibili.
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.
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 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. I log vengono raccolti utilizzando un agente basato su fluentbit. Se vuoi
modificare il comportamento predefinito degli agenti fluentd, puoi eseguire un
agente fluentd personalizzato.
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 livelloERROR. I log strutturati possono includere un camposeverity, 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 disponibili
Se scegli di inviare i log a Cloud Logging, devi inviare i log di sistema e, se vuoi, puoi inviarli da origini aggiuntive.
La seguente tabella indica i valori supportati per il flag --logging per i comandi create e update.
| Sorgente log | Valore --logging |
Log raccolti |
|---|---|---|
| Nessuna | 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:
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 su 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.
|
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 disabilitati. Sconsigliamo di disabilitare i log dei carichi di lavoro a causa dell'impatto sulla supportabilità.
Per i progetti dell'edizione GKE Enterprise, altri log utili sono abilitati 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 in cui è abilitato GKE Enterprise:
| Nome log | Autopilot | Standard |
|---|---|---|
| Sistema | ||
| Carichi di lavoro | - | |
| Server API | ||
| Scheduler | ||
| Gestore del controller |
I log del piano di controllo (server API, scheduler e gestore del controller) sono soggetti agli addebiti di Cloud Logging.
Prezzi
I log del piano di controllo GKE vengono esportati in Cloud Logging. Si applicano i prezzi di Cloud Logging.
Quando esporti i log in un altro servizio Google Cloud, come BigQuery, ti vengono addebitati i costi di archiviazione maturati. Per i costi associati a Cloud Logging, consulta Prezzi.
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.