Panoramica di GKE Autopilot

Autopilot è una modalità operativa gestita in Google Kubernetes Engine (GKE). Questa pagina descrive i vantaggi della modalità Autopilot e fornisce informazioni sulla pianificazione dei cluster, sul deployment dei workload e sulla configurazione di networking e sicurezza. Amministratori, architetti e operatori possono utilizzare queste informazioni per prendere decisioni consapevoli quando valutano l'allineamento della modalità GKE Autopilot ai requisiti operativi dei loro workload containerizzati.

Per ulteriori informazioni sulle differenze tra le modalità operative in GKE, consulta Confronta GKE Autopilot e Standard.

Che cos'è Autopilot?

GKE Autopilot è una modalità operativa in GKE in cui Google gestisce la configurazione dell'infrastruttura, inclusi nodi, scalabilità, sicurezza e altre impostazioni preconfigurate. La modalità Autopilot è ottimizzata per eseguire la maggior parte dei workload di produzione ed esegue il provisioning delle risorse di computing in base ai manifest Kubernetes.

Puoi eseguire un intero cluster in modalità Autopilot, in modo che il cluster e tutti i suoi workload seguano le best practice e i suggerimenti di GKE per la scalabilità, la sicurezza, gli upgrade e la configurazione dei nodi. Puoi anche eseguire workload specifici in modalità Autopilot nei cluster GKE Standard. Questa opzione ti consente di utilizzare Autopilot in ambienti in cui hai ancora bisogno del controllo manuale della tua infrastruttura. Per saperne di più, consulta Informazioni sui workload in modalità Autopilot in GKE Standard.

Vantaggi

  • Concentrati sulle tue app: Google gestisce l'infrastruttura, così puoi concentrarti sulla creazione e sul deployment delle tue applicazioni.
  • Sicurezza: i cluster Autopilot hanno una configurazione con protezione avanzata predefinita, con molte impostazioni di sicurezza abilitate per impostazione predefinita. GKE applica automaticamente le patch di sicurezza ai nodi quando sono disponibili, rispettando le pianificazioni di manutenzione configurate.
  • Prezzi: il modello di prezzi di Autopilot semplifica le previsioni e l'attribuzione della fatturazione.
  • Gestione dei nodi: Google gestisce i nodi worker, quindi non è necessario creare nuovi nodi per adattarli ai workload o configurare upgrade e riparazioni automatici.
  • Scalabilità: quando i workload sono sottoposti a un carico elevato e aggiungi altri pod per gestire il traffico, ad esempio con la scalabilità automatica orizzontale dei pod di Kubernetes, GKE esegue automaticamente il provisioning di nuovi nodi per questi pod ed espande automaticamente le risorse nei nodi esistenti in base alle esigenze.
  • Pianificazione: Autopilot gestisce il bin packing dei pod per te, quindi non devi pensare a quanti pod sono in esecuzione su ciascun nodo. Puoi controllare ulteriormente il posizionamento dei pod utilizzando meccanismi di Kubernetes come l'affinità e la topologia di distribuzione dei pod.
  • Gestione delle risorse: se esegui il deployment dei workload senza impostare valori delle risorse come CPU e memoria, Autopilot imposta automaticamente i valori predefiniti preconfigurati e modifica le richieste di risorse a livello di workload.
  • Networking: Autopilot attiva alcune funzionalità di sicurezza di rete per impostazione predefinita, ad esempio il passaggio di tutto il traffico di rete dei pod attraverso le regole firewall del Virtual Private Cloud, anche se il traffico è indirizzato ad altri pod nel cluster.
  • Gestione dei rilasci: tutti i cluster Autopilot sono registrati in un canale di rilascio GKE in modo che il control plane e i nodi vengano eseguiti sulle ultime versioni qualificate in quel canale.
  • Flessibilità gestita: se i tuoi workload hanno requisiti hardware o di risorse specifici, come le GPU, puoi definirli in ComputeClasses. Quando richiedi una classe ComputeClass nel tuo workload, GKE utilizza i tuoi requisiti per configurare i nodi per i tuoi pod. Non è necessario configurare manualmente l'hardware per i nodi o per i singoli workload.
  • Complessità operativa ridotta: Autopilot riduce l'overhead di amministrazione della piattaforma eliminando la necessità di monitorare continuamente i nodi, la scalabilità e le operazioni di pianificazione.

Autopilot viene fornito con uno SLA che copre sia il control plane sia la capacità di computing utilizzata dai pod.

Informazioni sulla piattaforma di computing ottimizzata per i container Autopilot

In GKE versione 1.32.3-gke.1927002 e successive, Autopilot include una piattaforma di computing specializzata e ottimizzata per i container per i tuoi workload. Questa piattaforma è ideale per la maggior parte dei workload per uso generico che non richiedono hardware specifico, come i server web e i job batch di media intensità.

La piattaforma di computing ottimizzata per i container utilizza i nodi GKE Autopilot che possono essere ridimensionati dinamicamente durante l'esecuzione, progettati per fare lo scale up da frazioni di una CPU con interruzioni minime. Questo ridimensionamento dinamico riduce notevolmente il tempo necessario per eseguire il provisioning di nuova capacità man mano che i workload scalano. Per migliorare la velocità di scalabilità e ridimensionamento, GKE mantiene anche un pool di capacità di computing pre-provisioning che può essere allocata automaticamente per i workload in risposta all'aumento delle richieste di risorse. Poiché la serie di macchine sottostante non è fissa, le prestazioni per CPU variano a seconda della serie di macchine su cui GKE pianifica il pod.

La piattaforma di computing ottimizzata per i container offre i seguenti vantaggi:

  • La capacità di computing corrisponde ai workload: Autopilot regola dinamicamente la capacità di computing per la piattaforma di computing ottimizzata per i container in base a fattori come il numero di pod e il consumo di risorse. Di conseguenza, la capacità di computing nel cluster corrisponde alle esigenze dei tuoi workload.
  • Tempi di scalabilità rapidi: durante gli eventi di scale up, GKE può ridimensionare in modo dinamico i nodi esistenti per ospitare più pod o un maggiore consumo di risorse. Questo provisioning dinamico della capacità spesso significa che i nuovi pod non devono attendere l'avvio di nuovi nodi. Il ridimensionamento dei nodi non è supportato per i workload Arm.
  • Supporto multi-architettura: la piattaforma di computing ottimizzata per i container supporta le architetture x86 e Arm per i workload per uso generico. Per impostazione predefinita, i workload utilizzano l'architettura x86. Puoi eseguire i workload sulla piattaforma ARM per uso generico specificando il selettore di nodi kubernetes.io/arch: arm64 o selezionando le classi di calcolo autopilot-arm o autopilot-arm-spot.

Puoi utilizzare la piattaforma di computing ottimizzata per i container Autopilot nei seguenti modi:

Prezzi

I prezzi di Autopilot utilizzano modelli diversi a seconda del tipo di hardware utilizzato dai pod, come segue:

  • Pod Autopilot per uso generico: i seguenti tipi di pod utilizzano un modello di fatturazione basato sui pod e sono classificati come pod per uso generico:

    • Pod eseguiti sulla piattaforma di computing ottimizzata per i container nei cluster Autopilot o Standard.
    • Pod che selezionano le classi di computing integrate Balanced o Scale-Out nei cluster Autopilot.

    Per saperne di più, consulta la sezione "Workload Autopilot per uso generico" in Prezzi di Google Kubernetes Engine.

  • Workload Autopilot che selezionano hardware specifico: i pod che selezionano hardware specifico, come serie di macchine Compute Engine, acceleratori hardware o utilizzando ComputeClasses, utilizzano un modello di fatturazione basato sui nodi. In questo modello, paghi per l'hardware sottostante e un premium per la gestione dei nodi.

    Per saperne di più, consulta la sezione "Workload Autopilot che selezionano hardware specifico" in Prezzi di Google Kubernetes Engine.

Cluster e workload Autopilot

GKE ti consente di utilizzare la modalità Autopilot per interi cluster o per workload specifici nei cluster Standard. I cluster Autopilot sono il modo consigliato per utilizzare GKE, perché l'intero cluster utilizza le best practice di Google per impostazione predefinita.

Tuttavia, alcune organizzazioni hanno requisiti di controllo manuale o di flessibilità che richiedono l'utilizzo di un cluster GKE Standard. In questi casi, puoi comunque utilizzare Autopilot per workload specifici nei tuoi cluster Standard, il che ti consente di usufruire di molte funzionalità di Autopilot a livello di workload.

Le sezioni seguenti mostrano come pianificare e creare cluster Autopilot. Se hai un cluster Standard e vuoi eseguire alcuni dei tuoi workload in modalità Autopilot, consulta Informazioni sui workload in modalità Autopilot in GKE Standard.

Pianifica i cluster Autopilot

Prima di creare un cluster, pianifica e progetta l'architettura Google Cloud . In Autopilot, richiedi l'hardware nelle specifiche del workload. GKE esegue il provisioning e gestisce l'infrastruttura corrispondente per eseguire questi workload. Ad esempio, se esegui workload di machine learning, richiedi acceleratori hardware.

Pianifica e richiedi la quota per il tuo progetto o la tua organizzazione Google Cloud in base alla scalabilità dei tuoi workload. GKE può eseguire il provisioning dell'infrastruttura per i tuoi workload solo se il tuo progetto dispone di una quota sufficiente per l'hardware.

Durante la pianificazione, tieni presente i seguenti fattori:

  • Dimensioni e scalabilità del cluster stimate
  • Tipo di workload
  • Layout e utilizzo del cluster
  • Layout e configurazione di Networking
  • Configurazione di sicurezza
  • Gestione e manutenzione dei cluster
  • Deployment e gestione dei workload
  • Logging e monitoraggio

Le sezioni seguenti forniscono informazioni e risorse utili per queste considerazioni.

Networking

Quando crei un cluster Autopilot con networking pubblico, i workload nel cluster possono comunicare tra loro e con internet. Questa è la modalità di networking predefinita. Google Cloud e Kubernetes forniscono varie funzionalità di networking aggiuntive che puoi utilizzare in base ai tuoi requisiti, ad esempio cluster con networking privato.

Il networking in Kubernetes e nel cloud è complesso. Prima di iniziare a modificare i valori predefiniti impostati daGoogle Cloud , assicurati di conoscere i concetti di base del networking. La tabella seguente fornisce risorse per scoprire di più sul networking in GKE in base al tuo caso d'uso:

Caso d'uso Risorse
Comprendere il funzionamento del networking in Kubernetes e GKE

Dopo aver appreso il modello di networking, valuta i requisiti di networking e sicurezza di rete della tua organizzazione. Scegli le funzionalità di networking di GKE e Google Cloud che soddisfano questi criteri.

Pianifica la configurazione di rete GKE

Ti consigliamo di comprendere le quote di networking per GKE, ad esempio gli endpoint per servizio e i limiti delle richieste API. Le seguenti risorse ti aiuteranno a pianificare aspetti specifici della configurazione di networking:
Esponi i tuoi workload
  • Per esporre le tue app a internet, utilizza i servizi, che ti consentono di esporre un'app in esecuzione in un gruppo di pod come un singolo servizio di rete.
  • Per configurare i workload in modo che comunichino in modo sicuro con le API Google Cloud , utilizza Workload Identity Federation for GKE.
Esegui servizi connessi ad alta affidabilità in più cluster Utilizza i servizi multi-cluster (MCS).
Bilancia il carico del traffico in entrata
Configura la sicurezza di rete del cluster
  • Per controllare o impedire l'accesso al tuo cluster dalla rete internet pubblica, personalizza l'isolamento della rete personalizza l'isolamento della rete.
  • Per limitare l'accesso al control plane a intervalli di indirizzi IP specifici, utilizza le reti autorizzate del control plane.
  • Per controllare il traffico dei pod, utilizza le policy di rete. L'applicazione delle policy di rete è disponibile con GKE Dataplane V2, che è abilitato per impostazione predefinita nei cluster Autopilot. Per istruzioni, consulta le policy di rete.
Osserva il traffico di rete Kubernetes

Per impostazione predefinita, Autopilot utilizza GKE Dataplane V2 per le metriche e l'osservabilità .

  • Per importare le metriche di GKE Dataplane V2, configura Google Cloud Managed Service per Prometheus. Per impostazione predefinita, le metriche di GKE Dataplane V2 sono esposte in GKE Autopilot.
  • Per accedere alle visualizzazioni, ai verdetti delle policy di rete e ai dump dei flussi, configura strumenti di risoluzione dei problemi aggiuntivi utilizzando l'osservabilità di GKE Dataplane V2.

Scalabilità

La gestione efficace di una piattaforma su larga scala richiede pianificazione e un'attenta valutazione. Devi considerare la scalabilità del tuo design, ovvero la capacità dei tuoi cluster di crescere rimanendo entro gli obiettivi del livello di servizio (SLO). Per indicazioni dettagliate sia per gli amministratori della piattaforma che per gli sviluppatori, consulta le Linee guida per la creazione di cluster scalabili.

Devi anche considerare le quote e i limiti di GKE, soprattutto se prevedi di eseguire cluster di grandi dimensioni con potenzialmente migliaia di pod.

In Autopilot, GKE scala automaticamente i nodi in base al numero di pod nel cluster. Se un cluster non ha workload in esecuzione, Autopilot può fare lo scale down automatico del cluster fino a zero nodi. In seguito allo scale down del cluster, non rimangono nodi nel cluster e i pod di sistema sono di conseguenza in uno stato non pianificabile. Questo è un comportamento previsto. Nella maggior parte dei cluster Autopilot appena creati, potresti notare che la pianificazione dei primi workload di cui esegui il deployment richiede più tempo. Questo perché il nuovo cluster Autopilot inizia con zero nodi utilizzabili al momento della creazione e attende il deployment di un workload per eseguire il provisioning di nodi aggiuntivi.

Best practice:

Per scalare automaticamente il numero di pod nel cluster, utilizza un meccanismo come la scalabilità automatica orizzontale dei pod di Kubernetes, che può scalare i pod in base alle metriche integrate di CPU e memoria o in base alle metriche personalizzate di Cloud Monitoring. Inoltre, Autopilot attiva la scalabilità automatica verticale dei pod per impostazione predefinita. Per ottimizzare le richieste di CPU dei container durante la scalabilità automatica delle repliche, puoi utilizzare il dimensionamento ottimale di HPA con VPA (anteprima). Per scoprire come configurare la scalabilità orizzontale in base a varie metriche, consulta Configura la scalabilità automatica orizzontale dei pod.

Sicurezza

I cluster Autopilot abilitano e applicano le best practice e le impostazioni di sicurezza per impostazione predefinita, inclusi molti dei suggerimenti riportati in Rafforza la sicurezza del cluster e nella Panoramica della sicurezza di GKE.

Se esegui workload Autopilot nei cluster Standard, GKE applica varie misure di sicurezza Autopilot a questi workload secondo il principio del "best effort". Puoi applicare rigorosamente policy di sicurezza Autopilot specifiche nell'intero cluster Standard. Se applichi tutte le policy di Autopilot disponibili, il tuo cluster Standard avrà un ambiente operativo simile a quello di un cluster Autopilot.

Per scoprire di più sulle misure di protezione di Autopilot e su come implementare i tuoi requisiti di sicurezza specifici, consulta Misure di sicurezza in Autopilot.

Crea un cluster

Dopo aver pianificato l'ambiente e compreso i requisiti, crea un cluster Autopilot. I nuovi cluster Autopilot sono cluster regionali con un indirizzo IP accessibile pubblicamente. A ogni cluster vengono applicate misure di protezione di base, oltre alla scalabilità automatica e ad altre funzionalità. Per un elenco completo delle funzionalità preconfigurate, consulta Confronta GKE Autopilot e Standard.

Se vuoi creare il cluster senza accesso agli indirizzi IP esterni, configura l'isolamento della rete.

Esegui il deployment dei workload in modalità Autopilot

Puoi eseguire workload Kubernetes compatibili in modalità Autopilot in modo che GKE gestisca la scalabilità, la pianificazione efficiente e l'infrastruttura sottostante. Puoi utilizzare la piattaforma di computing ottimizzata per i container per i tuoi workload per uso generico oppure puoi selezionare un hardware specifico per i tuoi workload utilizzando una ComputeClass.

Puoi eseguire questi workload Autopilot in uno dei seguenti modi:

Per una guida interattiva nella console Google Cloud per il deployment e l'esposizione di un'app in un cluster Autopilot, fai clic su Procedura guidata:

Procedura guidata

La tabella seguente mostra alcuni requisiti comuni e fornisce consigli su cosa fare:

Caso d'uso Risorse
Controlla le proprietà dei singoli nodi durante la scalabilità di un cluster Crea una ComputeClass personalizzata e richiedila nel manifest del workload. Per saperne di più, consulta Informazioni sulle ComputeClass personalizzate.
Esegui i workload Autopilot in un cluster Standard Utilizza una classe ComputeClass Autopilot nel cluster Standard. Per saperne di più, consulta Informazioni sui workload in modalità Autopilot in GKE Standard.
Esegui workload ARM Per i workload per uso generico, richiedi l'architettura Arm e la classe ComputeClass integrata autopilot-arm o autopilot-arm-spot. Per requisiti hardware specifici, richiedi una serie di macchine con CPU Arm in una ComputeClass personalizzata. Per saperne di più, consulta Informazioni sulle ComputeClass personalizzate.
Esegui workload AI/ML accelerati Richiedi le GPU in una classe ComputeClass o nel manifest del workload. Per saperne di più sulla richiesta di GPU nel manifest del workload, consulta Esegui il deployment dei workload GPU in Autopilot.
Esegui workload a tolleranza di errore, come i job batch, a costi inferiori.

Puoi utilizzare qualsiasi ComputeClass o configurazione hardware con i pod spot.
Eseguire workload che richiedono interruzioni minime, come server di gioco o code di lavoro Solo nei cluster Autopilot, specifica l'annotazione cluster-autoscaler.kubernetes.io/safe-to-evict=false nella specifica del pod. I pod sono protetti dall'espulsione causata da upgrade automatici dei nodi o eventi di scale down per un massimo di sette giorni. Per saperne di più, consulta Estendi il tempo di esecuzione dei pod Autopilot.
Consenti ai workload di superare le richieste se sono disponibili risorse inutilizzate nella somma delle richieste di risorse dei pod sul nodo. Imposta il valore limits della risorsa su un valore superiore a requests o non impostare limiti delle risorse. Per saperne di più, consulta Configura il bursting dei pod in GKE.

Autopilot ti consente di richiedere risorse di CPU, memoria e archiviazione temporanea per i tuoi workload. Gli intervalli consentiti dipendono dal fatto che tu voglia eseguire i tuoi pod sulla piattaforma di computing ottimizzata per i container Autopilot o su un hardware specifico. Per informazioni sulle richieste di risorse dei container predefinite e sugli intervalli di risorse consentiti, consulta Richieste di risorse in Autopilot.

Separazione dei workload

I cluster Autopilot supportano l'utilizzo di selettori di nodi e affinità dei nodi per configurare la separazione dei workload. La separazione dei workload è utile quando devi indicare a GKE di posizionare i workload su nodi che soddisfano criteri specifici, come le etichette dei nodi personalizzate. Ad esempio, puoi indicare a GKE di pianificare i pod dei server di gioco sui nodi con l'etichetta game-server ed evitare di pianificare altri pod su questi nodi.

Per scoprire di più, consulta Configura la separazione dei workload in GKE.

Pianifica i pod in zone specifiche utilizzando la topologia a livello di zona

Se devi posizionare i pod in una zona Google Cloud specifica, ad esempio per accedere alle informazioni su un disco permanente di Compute Engine a livello di zona, consulta Posiziona i pod GKE in zone specifiche.

Affinità e anti-affinità dei pod

Utilizza l'affinità e l'anti-affinità dei pod per collocare i pod su un singolo nodo o per fare in modo che alcuni pod ne evitino altri. L'affinità e l'anti-affinità dei pod indicano a Kubernetes di prendere una decisione di pianificazione in base alle etichette dei pod in esecuzione sui nodi in un dominio di topologia specifico, ad esempio una regione o una zona specifica. Ad esempio, puoi indicare a GKE di evitare di pianificare i pod di frontend insieme ad altri pod di frontend sugli stessi nodi per migliorare la disponibilità in caso di interruzione.

Per istruzioni e ulteriori dettagli, consulta Affinità e anti-affinità dei pod.

In GKE, puoi utilizzare l'affinità e l'anti-affinità pod con le seguenti etichette in topologyKey:

  • topology.kubernetes.io/zone
  • kubernetes.io/hostname

Vincoli di distribuzione della topologia dei pod

Per migliorare la disponibilità dei workload man mano che Kubernetes aumenta e riduce il numero di pod, puoi impostare i vincoli di distribuzione della topologia dei pod. In questo modo, controlli il modo in cui Kubernetes distribuisce i pod tra i nodi all'interno di un dominio di topologia, ad esempio una regione. Ad esempio, puoi indicare a Kubernetes di posizionare un numero specifico di pod di sessioni del server di gioco in ciascuna delle tre zone Google Cloud nella regione us-central1.

Per esempi, ulteriori dettagli e istruzioni, consulta Vincoli di distribuzione della topologia dei pod.

Best practice:

Se utilizzi topologySpreadConstraints con la scalabilità automatica dei cluster, ti consigliamo di impostare nodeTaintsPolicy: Honor. Questa impostazione aiuta a garantire che il gestore della scalabilità automatica dei cluster simuli correttamente la migrazione dei pod durante gli eventi di scale down, evitando potenziali loop di scalabilità. Senza questa impostazione, il gestore della scalabilità automatica potrebbe fare lo scale down dei nodi in modo da violare i vincoli di distribuzione della topologia, causando eventi di scale up immediati e l'interruzione del workload.

L'impostazione whenUnsatisfiable: ScheduleAnyway aiuta anche a evitare che i pod diventino non pianificabili in caso di squilibri temporanei della topologia, ad esempio durante un errore della zona.

Gestisci e monitora i cluster Autopilot

In Autopilot, GKE gestisce automaticamente gli upgrade e la manutenzione del cluster sia per il control plane sia per i nodi worker. I cluster Autopilot dispongono anche di funzionalità integrate per monitorare i cluster e i workload.

Upgrade della versione di GKE

Tutti i cluster Autopilot sono registrati in un canale di rilascio GKE. Nei canali di rilascio, GKE gestisce la versione di Kubernetes del cluster, bilanciando la disponibilità delle funzionalità e la stabilità della versione a seconda del canale. Per impostazione predefinita, i cluster Autopilot sono registrati nel canale di rilascio regolare, ma puoi selezionare un canale diverso che soddisfi le tue esigenze di stabilità e funzionalità. Per saperne di più sui canali di rilascio, consulta Informazioni sui canali di rilascio.

GKE avvia automaticamente gli upgrade, monitora l'avanzamento e mette in pausa l'operazione se si verificano problemi. Puoi controllare manualmente il processo di upgrade nei seguenti modi:

  • Per controllare quando GKE può eseguire gli upgrade automatici, crea periodi di manutenzione. Ad esempio, puoi impostare il periodo di manutenzione sulla notte prima del reset settimanale del tuo gioco multiplayer, in modo che i giocatori possano accedere al reset senza interruzioni.
  • Per controllare quando GKE non può avviare gli upgrade automatici durante un intervallo di tempo specifico, utilizza le esclusioni dalla manutenzione. Ad esempio, puoi impostare un'esclusione per manutenzione per la durata dell'evento di vendita del Black Friday e del Cyber Monday, in modo che i tuoi clienti possano fare acquisti senza problemi.
  • Per ottenere una nuova versione prima dell'inizio degli upgrade automatici, esegui l'upgrade manuale del control plane. GKE riconcilia la versione del nodo con la versione del control plane nel tempo.
  • Per ottenere una versione patch disponibile solo in un canale di rilascio più recente, consulta Esegui le versioni patch da un canale più recente. Ad esempio, potresti aver bisogno di una versione patch specifica per mitigare una recente divulgazione di vulnerabilità.

Monitora i cluster Autopilot

I cluster Autopilot hanno già Cloud Logging, Cloud Monitoring e Google Cloud Managed Service per Prometheus abilitati.

I cluster Autopilot raccolgono automaticamente i seguenti tipi di log e metriche, rispettando le best practice di Google per la raccolta della telemetria:

Log per Cloud Logging

  • Log di sistema
  • Log dei workload
  • Audit log delle attività di amministrazione
  • Audit log degli accessi ai dati

Metriche per Cloud Monitoring

  • Metriche di sistema
  • Metriche dei workload (da Google Cloud Managed Service per Prometheus)

Non è necessaria alcuna configurazione aggiuntiva per abilitare il logging e il monitoraggio. La seguente tabella mostra come interagire con la telemetria raccolta in base ai tuoi requisiti:

Caso d'uso Risorse
Comprendi e accedi ai log di GKE
  • Per scoprire i tipi di log che raccogliamo automaticamente, consulta Quali log vengono raccolti.
  • Per accedere ai log e utilizzare l'interfaccia utente di Cloud Logging nella console Google Cloud , consulta Visualizzazione dei log di GKE.
  • Per query di esempio che puoi utilizzare per filtrare i log di sistema e dei workload di Kubernetes, consulta Query relative a Kubernetes.
  • Per query di esempio che puoi utilizzare per filtrare gli audit log delle attività di amministrazione e del controllo dell'accesso ai dati, consulta Informazioni sull'audit logging di GKE.
  • Per configurare i log per gli ambienti multi-tenant, ad esempio quando i team hanno spazi dei nomi specifici in un singolo cluster GKE, ma ogni team ha il proprio progetto Google Cloud , consulta Logging multi-tenant su GKE.
Osserva le prestazioni dei tuoi cluster GKE

Un monitoraggio efficace delle prestazioni del cluster può aiutarti a ottimizzare i costi operativi dei cluster e dei workload.
Monitora la security posture dei tuoi cluster Utilizza la dashboard della security posture per controllare i workload in esecuzione in base alle best practice di GKE, scansionare le vulnerabilità nei sistemi operativi dei container e nei pacchetti di linguaggio e ricevere suggerimenti di mitigazione attuabili. Per saperne di più, consulta Informazioni sulla dashboard della security posture.

Risoluzione dei problemi

Per la procedura di risoluzione dei problemi, consulta Risoluzione dei problemi relativi ai cluster Autopilot.

Passaggi successivi