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. Anche se GKE memorizza i log, questi non vengono memorizzati in modo permanente. Ad esempio, i log dei container GKE vengono rimossi quando il pod host viene rimosso, quando lo spazio sul 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 di sistema e dei container, 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 dai processi containerizzati
kubelet e log di runtime del container
Log dei 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 audit log includono il log delle attività di amministrazione, il log degli accessi ai dati e il log degli eventi. Per informazioni dettagliate sui log di controllo per GKE, consulta la documentazione Log di controllo per GKE. Gli audit log per GKE non possono essere disabilitati.
Log di sistema, inclusi quelli elencati nei log disponibili.
I log delle applicazioni includono tutti i log generati dai 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 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 LogEntry che supera il limite di dimensioni viene eliminato per i log jsonPayload e troncato per i log textPayload.
Se vuoi, 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 di Controller Manager includono tutti i log generati da Kubernetes Controller Manager (
kube-controller-manager).
Per scoprire di più su ciascuno di questi componenti del control plane, consulta la sezione 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 inseriti 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 ti consentono di ridurre il volume dei log inviati a Cloud Logging.
Velocità effettiva di logging
Quando la registrazione di sistema è abilitata, 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 su container, pod e cluster e poi invia i log a Cloud Logging utilizzando un agente basato su fluentbit.
Se alcuni nodi GKE richiedono un throughput di log superiore a quello predefinito e il tuo cluster GKE Standard utilizza la versione del control plane 1.23.13-gke.1000 o successive, puoi configurare GKE per eseguire il deployment di una configurazione alternativa dell'agente Logging progettata per massimizzare il throughput di logging.
Per saperne di più, vedi Regolare la velocità effettiva dei log.
Raccolta dei log con fluentd o fluentbit personalizzato
L'agente di logging predefinito di GKE fornisce una soluzione gestita per distribuire e gestire gli agenti che inviano i log dei tuoi cluster a Cloud Logging. I log vengono raccolti utilizzando un agente basato su Fluent Bit.
Raccolta dei log auditd di Linux per i nodi GKE
Puoi abilitare i log di controllo 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 di file binari. Puoi utilizzare queste informazioni per eseguire il debug dei problemi o esaminare gli incidenti di sicurezza.
Per saperne di più, consulta la pagina Abilitazione degli 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 Log di controllo.
Controllo dell'accesso a Logging
Controllo dell'accesso ai log ha due aspetti: 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 hanno bisogno 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
Per visualizzare i log nel tuo progetto, devi disporre del 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 al controllo dell'accesso. Puoi anche 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 è
obbligatorio per creare un sink di logging, che viene 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 di uno spazio dei nomi a un bucket di logging centralizzato.
Per saperne di più, consulta la guida Controllo dell'accesso per Cloud Logging.
Best practice
- Logging strutturato:l'agente di logging integrato con GKE
legge i documenti JSON serializzati in stringhe a riga singola e scritti in
output standard o errore standard e li invia a Google Cloud Observability
come voci di log strutturate.
- Per maggiori dettagli sull'utilizzo di un agente di logging integrato, vedi Logging strutturato.
- Puoi utilizzare i filtri avanzati dei log 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
INFOe 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 formato e la struttura. Per ulteriori informazioni, consulta la panoramica su routing e archiviazione.
Avvisi:quando la registrazione registra un comportamento imprevisto, puoi utilizzare le metriche basate sui log per configurare i criteri di avviso. Per un esempio, vedi 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 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 origini aggiuntive.
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 quanto segue:
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 del 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 sia atomiche che finali per ogni oggetto HPA nel cluster GKE. Per maggiori dettagli, vedi Visualizzare gli eventi di scalabilità automatica orizzontale dei pod. |
| Connessioni di rete del control plane | KCP_CONNECTION |
Disponibile solo con GKE control plane authority Log delle connessioni di rete in entrata per le istanze del control plane GKE. Per maggiori dettagli, vedi Verificare le connessioni di Google al control plane del cluster. |
| Eventi SSH del control plane | KCP_SSHD |
Disponibile solo con GKE control plane authority Genera log per tutti gli eventi SSH, come l'accettazione della chiave pubblica e la chiusura della sessione, che si verificano quando il personale Google si connette alle istanze del piano di controllo del cluster durante le richieste di assistenza o per altri accessi amministrativi. Per maggiori dettagli, vedi Verificare le connessioni di Google al control plane del cluster. |
Log attivati per impostazione predefinita in GKE Enterprise
Quando crei un nuovo cluster GKE su Google Cloud, i log dei workload sono abilitati per impostazione predefinita per tutti i cluster Autopilot, ma possono essere disabilitati.
Per i progetti GKE Enterprise, vengono abilitati per impostazione predefinita log utili aggiuntivi 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 con GKE Enterprise abilitato:
| Nome log | Autopilot | Standard |
|---|---|---|
| Sistema | ||
| Workload | ||
| Server API | ||
| Scheduler | ||
| Gestore del controller | ||
| Connessioni di rete del control plane | ||
| Eventi SSH del control plane |
I log di sistema e del control plane (server API, scheduler, gestore dei controller) comportano addebiti per Cloud Logging.
Prezzi
I log GKE vengono esportati in Cloud Logging. Vengono applicati i prezzi di Cloud Logging.
Ti vengono addebitati i costi di archiviazione maturati quando esporti i log in un altro servizio, come BigQuery. Google Cloud Per i costi associati a Cloud Logging, consulta la sezione Prezzi.
Quota
I log del control plane consumano la quota "Richieste di scrittura al minuto" dell'API Cloud Logging. Prima di attivare i log del control plane, controlla il picco di utilizzo 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 attivare i log del control plane.
Controlli di accesso
Se vuoi limitare l'accesso all'interno della tua organizzazione ai log del control plane di Kubernetes, puoi creare un bucket di log separato con controlli di accesso più limitati.
Se li memorizzi 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, memorizzarli in un bucket di log separato con accesso limitato consente di eliminarli senza influire sui log di altri componenti o servizi.