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.
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 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.
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 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. 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 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 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 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 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 per la raccolta dei log installato nel cluster. Questo valore non è supportato per i cluster Autopilot. |
| Sistema | SYSTEM |
Raccoglie i log dai seguenti elementi:
Raccoglie anche 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 degli utenti. 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 dei carichi di lavoro vengono 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 della versione GKE Enterprise, vengono abilitati per impostazione predefinita altri log utili se 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.
I costi di archiviazione maturati ti vengono addebitati quando esporti i log in un altro servizio Google Cloud, come BigQuery. Per i costi associati a Cloud Logging, consulta i prezzi.
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.