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 host viene vengono rimossi quando il disco su cui sono archiviati si esaurisce lo spazio disponibile o 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 di sistema e dei container, GKE esegue il deployment, per impostazione predefinita, agente di logging per nodo che legge i log dei container, aggiunge metadati utili e quindi li archivia in Cloud Logging. L'agente Logging di GKE verifica la presenza di log dei container nelle origini seguenti:
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 dai tuoi nel 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 Eventi. Per informazioni dettagliate sugli audit log per GKE, fai riferimento Audit log per GKE documentazione. 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 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 saperne di più su ognuno 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 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 Autopilot I cluster standard, i filtri di esclusione consentono di ridurre il volume di e i log inviati a Cloud Logging.
Velocità effettiva di logging
Quando il logging del sistema è abilitato, viene eseguito un agente Cloud Logging dedicato viene eseguito automaticamente il deployment e viene gestito automaticamente. Viene eseguito su tutti i nodi GKE in un cluster per raccogliere i log, aggiunge i metadati relativi a container, pod e cluster, quindi invia i log al 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, 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 eseguire il deployment e gestire gli agenti che inviano i log per i tuoi cluster in Cloud Logging. I log vengono raccolti utilizzando un agente basato su fluentbit.
Raccolta di log auditd di Linux per i nodi GKE in corso...
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, come messaggi di errore, tentativi di accesso esecuzioni binarie. 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 al cluster Kubernetes e le operazioni cluster GKE, vai a Audit logging.
Controllo dell'accesso al logging
Il controllo dell'accesso al logging ha due aspetti: accesso all'applicazione e access. Cloud Logging fornisce Identity and Access Management (IAM) ruoli 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 viene concesso assegnando il ruolo IAM
roles/logging.logWriter all'account di servizio collegato all'elemento sottostante
pool di nodi.
Accesso in visualizzazione utente
Per visualizzare i log nel tuo account, devi disporre del ruolo roles/logging.viewer
progetto. Per accedere ai log di accesso ai dati, è necessario disporre
l'autorizzazione IAM logging.privateLogViewer.
Per ulteriori informazioni su autorizzazioni e ruoli, visita 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. La
Il ruolo roles/logging.configWriter è
necessario per creare un sink di logging, solitamente utilizzato 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.
- Consulta Logging strutturato per maggiori dettagli su come collaborare con un agente Logging integrato.
- Puoi utilizzare i filtri avanzati per i log per filtrare i log in base ai campi del documento JSON.
- I log generati con glog avranno
campi comuni analizzati, 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 nella
INFOe i log scritti nell'errore standard si trovano al 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, vedi Crea 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 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, se vuoi, 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 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 è
facoltativa per tutti i tipi di cluster.
|
| Scheduler | SCHEDULER |
Tutti i log generati da kube-scheduler. Questo valore è
facoltativa 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. Sconsigliamo di disabilitare i log dei carichi di lavoro a causa impatto sulla supportabilità.
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 piano di controllo (server API, scheduler e gestore del controller) 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 consumano le "Richieste di scrittura al minuto" quota del l'API Cloud Logging. Prima di abilitare i log del piano di controllo, controllare l'utilizzo di picco recente di quella quota. Se hai molti cluster nello stesso progetto o ti stai già avvicinando limite di 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 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,
in un bucket di log separato con accesso limitato, consente di
i log senza influire su quelli di altri componenti o servizi.