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. GKE stesso archivia 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 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 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 in kube-system che raccoglie automaticamente gli eventi e li invia 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 sugli audit log per GKE, fai riferimento Audit log per GKE documentazione. Gli audit log per GKE non possono essere disattivati.
Log di sistema, inclusi i log elencati nella sezione Log disponibili.
I log delle applicazioni includono tutti i log generati da container non di sistema. in esecuzione sui nodi utente.
A causa delle seguenti limitazioni, l'esecuzione dei log dell'applicazione potrebbe non riuscire inviate 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 chiavestreamnel log JSON dell'applicazione potrebbe causare un comportamento imprevisto e l'eliminazione dei log.- Cloud Logging ha un limite di dimensioni per LogEntry. Qualsiasi voce di log che supera il limite di dimensione viene eliminata per i log jsonPayload e troncato per i log textPayload.
Facoltativamente, GKE può raccogliere altri tipi di log di alcuni componenti del piano di controllo Kubernetes e li archivia 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 di Gestione controller includono tutti i log generati da Kubernetes Gestore del titolare (
kube-controller-manager).
Per scoprire di più su ciascuno di questi componenti del piano di controllo, consulta Architettura del cluster GKE.
Raccolta dei log
Quando crei un nuovo cluster GKE, l'integrazione Cloud Logging è abilitato per impostazione predefinita.
I log di sistema e delle applicazioni vengono inviati Router dei log in Cloud Logging.
Da qui, i log possono essere importati in Cloud Logging, excluded (escluso) o esportate in BigQuery, in Pub/Sub o in Cloud Storage.
Puoi anche configurare un cluster Standard per acquisire solo i dati di sistema log delle applicazioni e non raccolgono 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 logging
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 i nodi GKE richiedono più log rispetto a quelli predefiniti e il tuo cluster GKE Standard utilizza 1.23.13-gke.1000 o versioni successive del piano di controllo, puoi configurare a GKE di eseguire il deployment di una configurazione alternativa Agente Logging progettato per massimizzare la velocità effettiva di logging.
Per ulteriori informazioni, vedi Regolare il throughput dei log.
Raccolta di log con fluentd o fluentbit personalizzati
L'agente Logging predefinito di GKE fornisce una soluzione gestita eseguire il deployment e gestire gli agenti che inviano i log per i tuoi cluster e in Cloud Logging. I log vengono raccolti utilizzando un agente basato su FluentBit.
Raccolta dei log auditd di Linux per i nodi GKE
Puoi attivare le notifiche audit log del sistema operativo sui nodi GKE in esecuzione 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 usare queste informazioni per risolvere i problemi o indagare incidenti di sicurezza.
Per saperne di più, vedi 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 del cluster GKE, vai a Log di controllo.
Controllo dell'accesso al logging
Esistono due aspetti del controllo dell'accesso ai log: accesso alle applicazioni e accesso degli utenti. Cloud Logging fornisce Identity and Access Management (IAM) ruoli 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 di base.
Accesso alla visualizzazione utente
Per visualizzare i log nel progetto, devi disporre del ruolo roles/logging.viewer. Per accedere ai log di accesso ai dati, è necessario disporre
l'autorizzazione IAM logging.privateLogViewer.
Per ulteriori informazioni su autorizzazioni e ruoli, consulta la guida al controllo dell'accesso. Puoi anche consultare 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 capacità amministrative. 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 una funzione
un sink insieme a un filtro di logging per indirizzare tutti i log per uno spazio dei nomi a un
nel bucket di logging centralizzato.
Per scoprire di più, consulta la guida per il controllo dell'accesso. per Cloud Logging.
Best practice
- Logging strutturato:l'agente di logging integrato con GKE
leggerà i documenti JSON serializzati in stringhe su una sola riga e scritti in
o l'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 avanzati per i log per filtrare i log in base ai campi del documento JSON.
- I campi comuni dei log generati con glog verranno 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 livello
INFOe i log scritti nell'errore standard sono a livelloERROR. I log strutturati possono includere un camposeverity, che definisce il valore gravità. - Esportazione in BigQuery: per ulteriori analisi, puoi esportare log a servizi esterni come BigQuery o Pub/Sub. I log esportati in BigQuery mantengono il formato e la struttura. Per saperne di più, consulta Panoramica su routing e archiviazione informazioni.
- Avvisi: quando Logging registra un comportamento imprevisto, puoi usa metriche basate su 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 sul tuo puoi utilizzare i cluster GKE 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 il parametro
create e
i comandi 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 Autopilot cluster. |
| Sistema | SYSTEM |
Raccoglie i log da quanto segue:
Raccoglie anche gli eventi Kubernetes. Questo valore è obbligatorio per 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 è
facoltativa 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 sono abilitati per impostazione predefinita per tutti i cluster Autopilot, può essere disattivato.
Per i progetti dell'edizione GKE Enterprise, altri log utili sono abilitate per impostazione predefinita registrarsi a un parco risorse durante la creazione del cluster.
Nella tabella seguente, è presente un segno di spunta () indica quali log sono abilitati per impostazione predefinita quando crei e registra un nuovo cluster in un progetto con GKE Enterprise abilitato:
| Nome log | Autopilot | Standard |
|---|---|---|
| Sistema | ||
| Carichi di lavoro | - | |
| Server API | ||
| Scheduler | ||
| Gestore del controller |
I log del control plane (server API, Scheduler e Controller Manager) comportano costi 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 in un altro servizio Google Cloud, come 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 al piano di controllo Kubernetes puoi creare un bucket di log separato con altre controlli di accesso 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 nessuno
Accesso di 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 dei log separato con accesso limitato ti consente di eliminarli senza influire sui log di altri componenti o servizi.