Best practice per il networking di GKE

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento illustra le best practice per configurare le opzioni di networking per i cluster Google Kubernetes Engine (GKE). È stata concepita come una guida alla pianificazione dell'architettura per i Cloud Architect e gli ingegneri di rete con suggerimenti applicabili alla maggior parte dei cluster GKE. Prima di creare i cluster, ti consigliamo di esaminare tutte le sezioni per comprendere le opzioni e le implicazioni del networking. Questo documento non ha lo scopo di presentare i concetti o la terminologia di rete di Kubernetes e presuppone che tu abbia già una certa conoscenza del networking di Kubernetes. Per ulteriori informazioni, consulta la panoramica della rete GKE.

Durante la revisione di questo documento tieni conto del livello di esposizione del tuo cluster e del tipo di cluster, di come prevedi di esporre i carichi di lavoro internamente alla tua rete Virtual Private Cloud (VPC) o esternamente a Internet, di come intendi scalare i tuoi carichi di lavoro e di quali tipi di servizi Google verranno consumati.

Progettazione VPC

Quando progetti le tue reti VPC, segui le best practice per la progettazione di VPC. La seguente sezione fornisce alcuni suggerimenti specifici di GKE per la progettazione di reti VPC.

Usa cluster nativi di VPC

Prima di creare un cluster, devi scegliere un cluster basato su percorsi o un cluster nativo VPC. Ti consigliamo di scegliere un cluster nativo di VPC perché utilizza gli intervalli di indirizzi IP alias sui nodi GKE e scala più facilmente rispetto ai cluster basati su route. I cluster nativi di VPC sono obbligatori per i cluster GKE privati e per la creazione di cluster su VPC condivisi. Per i cluster creati in Autopilot, la modalità VPC nativa è sempre attiva e non può essere disattivata.

I cluster nativi di VPC sono più facilmente scalabili rispetto ai cluster basati su route senza consumare le route di Google Cloud e pertanto sono meno suscettibili a raggiungere i limiti di routing. I vantaggi dell'utilizzo dei cluster nativi VPC vanno di pari passo con il supporto IP alias. Ad esempio, i gruppi di endpoint di rete (NEG) possono essere utilizzati solo con indirizzi IP secondari, quindi sono supportati solo nei cluster nativi VPC.

Utilizza reti VPC condivise

I cluster GKE richiedono un'attenta pianificazione degli indirizzi IP. La maggior parte delle organizzazioni tendono ad avere una struttura di gestione centralizzata con un amministratore di rete che può allocare uno spazio di indirizzi IP per i cluster e un amministratore di piattaforma per il funzionamento dei cluster. Questo tipo di struttura organizzativa funziona bene con l'architettura di rete VPC condivisa di Google Cloud. Nell'architettura di rete VPC condivisa, un amministratore di rete può creare subnet e condividerle con particolari entità. Puoi quindi creare cluster GKE nei progetti di servizio in queste subnet.

In generale, una rete VPC condivisa è un'architettura utilizzata di frequente, adatta alla maggior parte delle organizzazioni con un team di gestione centralizzato. Ti consigliamo di utilizzare le reti VPC condivise per creare le subnet per i cluster GKE ed evitare conflitti di indirizzi IP in tutta l'organizzazione.

Strategie di gestione degli indirizzi IP

I cluster Kubernetes richiedono un indirizzo IP univoco per ogni pod. In GKE, tutti questi indirizzi sono instradabili in tutta la rete VPC. Pertanto, è necessaria la pianificazione degli indirizzi IP perché gli indirizzi non possono sovrapporsi allo spazio degli indirizzi IP privati utilizzato on-premise o in altri ambienti connessi. Le seguenti sezioni suggeriscono strategie per la gestione degli indirizzi IP con GKE.

Pianifica l'allocazione degli indirizzi IP richiesta

I cluster privati sono consigliati e vengono trattati ulteriormente nella sezione Sicurezza di rete. Nel contesto dei cluster privati, sono supportati solo i cluster nativi di VPC e richiedono la definizione dei seguenti intervalli IP:

  • Intervallo di indirizzi IP del piano di controllo: una subnet RFC 1918 /28 che deve sovrapporsi a qualsiasi altro routing CIDR (lessless inter-domain routing) nella rete VPC.
  • Subnet: la subnet con l'intervallo IP principale da allocare per tutti i nodi nel cluster. Anche i servizi di tipo LoadBalancer che utilizzano l'annotazione cloud.google.com/load-balancer-type: "Internal" utilizzano questa subnet.
  • Intervallo di indirizzi IP del pod: l'intervallo IP allocato per tutti i pod nel cluster, noto anche come CIDR del cluster.
  • Intervallo di indirizzi IP di servizio: l'intervallo di indirizzi IP allocato per tutti i servizi nel cluster, noto anche come CIDR dei servizi.

L'intervallo di indirizzi IP del piano di controllo è dedicato al piano di controllo gestito da GKE che si trova in un progetto tenant gestito da Google in peering con il tuo VPC. Questo intervallo di indirizzi IP deve sovrapporsi a qualsiasi indirizzo IP nel tuo gruppo di peering VPC.

Durante la creazione di un cluster, la subnet ha un intervallo principale per i nodi del cluster e deve esistere prima della creazione del cluster. La subnet deve ospitare il numero massimo di nodi previsto nel cluster. Puoi utilizzare il gestore della scalabilità automatica del cluster per limitare il numero massimo di nodi.

Gli intervalli di indirizzi IP dei pod e dei servizi sono rappresentati come intervalli secondari distinti della subnet, implementati come indirizzi IP alias nei cluster nativi di VPC.

Scegli intervalli di indirizzi sufficientemente ampi da poter gestire tutti i nodi, i pod e i servizi del cluster.

Utilizza lo spazio non RFC 1918, se necessario

Per alcuni ambienti, lo spazio RFC 1918 in grandi blocchi CIDR contigui potrebbe essere già allocato in un'organizzazione. Puoi utilizzare spazio non RFC 1918 per CIDR aggiuntivi per i cluster GKE, se non si sovrappongono agli indirizzi IP pubblici di proprietà di Google. Consigliamo di utilizzare parte dello spazio di indirizzi RFC 6598 (100.64.0.0/10) perché lo spazio di indirizzi di Classe E può presentare problemi di interoperabilità con hardware on-premise. Inoltre, quando usi IP pubblici privati, fai attenzione, e valuta la possibilità di controllare la pubblicità dei percorsi nelle reti on-prem verso Internet quando scegli questa opzione.

Evita l'uso di SNAT nel cluster tra pod in pod e traffico da pod a servizi. Quando utilizzi IP pubblici privati privatamente con cluster privati, il comportamento predefinito presume SNAT per tutto lo spazio di indirizzi non RFC 1918. Per risolvere il problema, configura correttamente l'agente di mascheramento IP. nonMasqueradeCIDRs deve contenere almeno il CIDR del cluster e il CIDR dei servizi.

Usa modalità subnet personalizzata

Quando configuri la rete, seleziona anche la modalità subnet: auto (predefinita) o custom (opzione consigliata). La modalità auto lascia l'allocazione delle subnet a Google e rappresenta una buona opzione per iniziare senza la pianificazione degli indirizzi IP. Tuttavia, consigliamo di selezionare la modalità custom perché questa modalità ti consente di scegliere intervalli di indirizzi IP che non si sovrappongano ad altri intervalli nel tuo ambiente. Se utilizzi un VPC condiviso, un amministratore dell'organizzazione o di rete può selezionare questa modalità.

L'esempio seguente crea una rete denominata my-net-1 con modalità subnet personalizzata:

gcloud compute networks create my-net-1 --subnet-mode custom

Densità piano pod per nodo

Per impostazione predefinita, i cluster standard riservano un intervallo /24 per ogni nodo fuori dallo spazio degli indirizzi dei pod nella subnet e consentono fino a 110 pod per nodo. Tuttavia, puoi configurare un cluster standard in modo da supportare fino a 256 pod per nodo, con un intervallo /23 riservato per ogni nodo. A seconda delle dimensioni dei nodi e del profilo dell'applicazione dei pod, potresti eseguire un numero notevolmente inferiore di pod su ciascun nodo.

Se non prevedi di eseguire più di 64 pod per nodo, ti consigliamo di modificare il numero massimo di pod per nodo per preservare lo spazio degli indirizzi IP nella subnet del tuo pod.

Se prevedi di eseguire più dei 110 pod predefiniti per nodo, puoi aumentare il numero massimo di pod per nodo fino a 256, con /23 riservato per ogni nodo. Con questo tipo di configurazione ad alta densità di pod, ti consigliamo di utilizzare istanze con 16 o più core della CPU per garantire la scalabilità e le prestazioni del cluster.

Per i cluster Autopilot, il numero massimo di pod per nodo è impostato su 32, riservando un intervallo /26 per ogni nodo. Questa impostazione non è configurabile nei cluster Autopilot.

Evitare sovrapposizioni con indirizzi IP utilizzati in altri ambienti

Puoi connettere la rete VPC a un ambiente on-premise o ad altri provider di servizi cloud tramite Cloud VPN o Cloud Interconnect. Questi ambienti possono condividere route, rendendo lo schema di gestione degli indirizzi IP on-premise importante nella pianificazione degli indirizzi IP per GKE. Ti consigliamo di assicurarti che gli indirizzi IP non si sovrappongano a quelli utilizzati in altri ambienti.

Crea una subnet del bilanciatore del carico

Crea una subnet del bilanciatore del carico separata per esporre i servizi con il bilanciamento del carico TCP/UDP interno. Se non viene utilizzata una subnet separata del bilanciatore del carico, questi servizi sono esposti utilizzando un indirizzo IP dalla subnet del nodo, il che può portare all'utilizzo di tutto lo spazio allocato in quella subnet prima del previsto e può impedire la scalabilità del cluster GKE al numero previsto di nodi.

L'utilizzo di una subnet separata per il bilanciatore del carico significa anche che puoi filtrare il traffico da e verso i nodi GKE separatamente per i servizi esposti dal bilanciamento del carico TCP/UDP interno, il che ti consente di impostare limiti di sicurezza più rigorosi.

Prenota spazio sufficiente per gli indirizzi IP per il gestore della scalabilità automatica dei cluster

Puoi utilizzare il gestore della scalabilità automatica del cluster per avviare i nodi verso l'alto o verso il basso in modo dinamico, in modo da controllare i costi e migliorare l'utilizzo. Tuttavia, quando utilizzi il gestore della scalabilità automatica dei cluster, assicurati che la pianificazione degli indirizzi IP tenga conto delle dimensioni massime di tutti i pool di nodi. Ogni nuovo nodo richiede un proprio indirizzo IP nodo e un proprio insieme allocabile di indirizzi IP dei pod in base ai pod configurati per ciascun nodo. Il numero di pod per nodo può essere configurato in modo diverso da quello configurato a livello di cluster. Non puoi modificare il numero di pod per nodo dopo aver creato il cluster o il pool di nodi. Per un'allocazione ottimale dell'indirizzo IP, devi considerare i tipi di carico di lavoro e assegnarli a pool di nodi distinti.

Opzioni di sicurezza della rete

In questa sezione vengono descritti alcuni suggerimenti chiave per l'isolamento dei cluster. La sicurezza della rete per i cluster GKE è una responsabilità condivisa tra Google e gli amministratori del cluster.

Scegli un tipo di cluster privato

Esistono due tipi di isolamento di rete per i cluster: pubblico e privato. I cluster pubblici hanno indirizzi IP privati e pubblici sui nodi e solo un endpoint pubblico per i nodi del piano di controllo. I cluster privati forniscono un maggiore isolamento perché hanno solo indirizzi IP privati sui nodi e hanno endpoint privati e pubblici per i nodi del piano di controllo (che possono essere ulteriormente isolati e discussi nella sezione Riduci al minimo l'esposizione del piano di controllo del cluster). Nei cluster privati, puoi comunque accedere alle API di Google con l'accesso privato Google. Consigliamo di scegliere i cluster privati per l'isolamento di rete.

In un cluster privato, i pod sono isolati dalle comunicazioni in entrata e in uscita (il perimetro del cluster). Puoi controllare questi flussi direzionali esponendo i servizi utilizzando il bilanciamento del carico e Cloud NAT, discusso nella sezione sulla connettività dei cluster in questo documento. Il seguente diagramma mostra questo tipo di configurazione:

Diagramma 1: comunicazione sui cluster privati

Questo diagramma mostra in che modo un cluster privato può comunicare. I client on-premise possono connettersi al cluster con il client kubectl. L'accesso ai servizi Google viene fornito tramite l'accesso privato Google e la comunicazione con Internet è disponibile solo utilizzando Cloud NAT.

Per saperne di più, consulta i requisiti, le restrizioni e le limitazioni dei cluster privati.

Riduci al minimo l'esposizione del piano di controllo del cluster

In un cluster privato, il server API GKE può essere esposto come pubblico o come endpoint privato. Puoi decidere quale endpoint utilizzare quando crei il cluster. Puoi controllare l'accesso con le reti autorizzate, in cui gli endpoint pubblici e privati sono autorizzati per consentire tutte le comunicazioni tra il pod e gli indirizzi IP del nodo nel cluster. Per abilitare un endpoint privato quando crei un cluster, utilizza il flag --enable-private-endpoint.

Autorizzare l'accesso al piano di controllo

Le reti autorizzate possono aiutare a stabilire quali subnet IP possono accedere ai nodi del piano di controllo GKE. Dopo aver abilitato queste reti, puoi limitare l'accesso a intervalli di indirizzi IP di origine specifici. Se l'endpoint pubblico è disabilitato, gli intervalli di indirizzi IP di origine devono essere privati. Se è abilitato un endpoint pubblico, puoi consentire intervalli di indirizzi IP pubblici o privati. Configura gli annunci di route personalizzati per consentire all'endpoint privato del piano di controllo del cluster di essere raggiungibile da un ambiente on-premise. Puoi rendere l'endpoint dell'API GKE privata raggiungibile a livello globale utilizzando l'opzione --enable-master-global-access quando crei un cluster.

Il seguente diagramma mostra la connettività tipica del piano di controllo utilizzando le reti autorizzate:

Diagramma 2: connettere il piano di controllo utilizzando le reti autorizzate

Questo diagramma mostra che gli utenti attendibili possono comunicare con il piano di controllo GKE tramite l'endpoint pubblico poiché fanno parte di reti autorizzate, mentre l'accesso da attori non attendibili è bloccato. Le comunicazioni da e verso il cluster GKE avvengono tramite l'endpoint privato del piano di controllo.

Consenti connettività piano di controllo

Alcuni pod di sistema su ogni nodo worker devono raggiungere servizi come il server API Kubernetes (kube-apiserver), le API di Google o il server dei metadati. kube-apiserver deve inoltre comunicare con alcuni pod di sistema, come event-exporter in modo specifico. Questa comunicazione è consentita per impostazione predefinita. Se esegui il deployment delle regole firewall VPC all'interno dei progetti (maggiori dettagli nella sezione Limita il traffico del cluster), assicurati che questi pod possano continuare a comunicare con il kube-apiserver e con le API di Google.

Esegui il deployment del proxy per l'accesso al piano di controllo da reti in peering

L'accesso al piano di controllo per i cluster GKE privati è tramite il peering di rete VPC. Il peering di rete VPC non è transitorio, pertanto non puoi accedere al piano di controllo del cluster da un'altra rete in peering.

Se vuoi l'accesso diretto da un'altra rete in peering o da on-premise quando utilizzi un'architettura hub-and-soke, esegui il deployment dei proxy per il traffico del piano di controllo. Per saperne di più, vedi Creazione di cluster privati Kubernetes con proxy di rete per l'accesso al piano di controllo.

Limita il traffico del cluster tramite i criteri di rete

Sono possibili più livelli di sicurezza di rete per i carichi di lavoro del cluster che possono essere combinati: regole firewall VPC, criteri firewall gerarchici e criteri di rete GKE. Le regole firewall VPC e i criteri firewall gerarchici si applicano a livello di macchina virtuale (VM), ossia i nodi worker in cui risiedono i pod del cluster GKE. I criteri di rete GKE si applicano a livello di pod per applicare i percorsi del traffico pod. Per ulteriori informazioni, consulta il progetto base sulla sicurezza di Anthos: limitazione del traffico.

L'implementazione dei firewall VPC può interrompere la comunicazione predefinita del piano di controllo, ad esempio la comunicazione kubelet con il piano di controllo. GKE crea le regole firewall obbligatorie per impostazione predefinita, ma possono essere sovrascritte. Alcuni deployment potrebbero richiedere il piano di controllo per raggiungere il cluster nel servizio. Puoi utilizzare i firewall VPC per configurare un criterio in entrata che rende il servizio accessibile.

I criteri di rete GKE sono configurati tramite l'API Network Policy di Kubernetes per applicare la comunicazione di pod e servizi del cluster. Puoi abilitare i criteri di rete quando crei un cluster utilizzando l'opzione gcloud container clusters create--enable-network-policy. Per limitare il traffico utilizzando i criteri di rete, puoi seguire la guida all'implementazione dei progetti base per limitare il traffico di Anthos.

GKE Dataplane V2 si basa su eBPF e offre un'esperienza di visibilità e sicurezza della rete integrate. Quando crei un cluster utilizzando GKE Dataplane V2, non è necessario abilitare esplicitamente i criteri di rete perché GKE Dataplane V2 gestisce il routing dei servizi, l'applicazione dei criteri di rete e il logging. Abilita il nuovo piano dati con l'opzione gcloud --enable-dataplane-v2 quando crei un cluster. Dopo aver configurato i criteri di rete, è possibile configurare un oggetto CRD NetworkLogging predefinito per registrare le connessioni di rete consentite e negate.

Abilita i criteri di sicurezza di Google Cloud Armor per Ingress

Con i criteri di sicurezza di Google Cloud Armor puoi proteggere le applicazioni che utilizzano il bilanciamento del carico HTTP(S) esterno da attacchi DDoS e altri attacchi basati sul Web bloccando tale traffico sul perimetro della rete. In GKE, abilita i criteri di sicurezza di Google Cloud Armor per le applicazioni utilizzando Ingress per il bilanciamento del carico HTTP(S) esterno e aggiungendo un criterio di sicurezza a BackendConfig collegato all'oggetto Ingress.

Utilizza Identity-Aware Proxy per fornire l'autenticazione per le applicazioni che utilizzano utenti IAM

Se vuoi fare in modo che i servizi siano accessibili solo agli utenti che appartengono all'organizzazione, ma senza dover utilizzare la rete aziendale, puoi utilizzare Identity-Aware Proxy per creare un livello di autenticazione per queste applicazioni. Per attivare Identity-Aware Proxy per GKE, segui i passaggi di configurazione per aggiungere Identity-Aware Proxy come parte di BackendConfig per il servizio Ingress. Identity-Aware Proxy può essere combinato con Google Cloud Armor.

Utilizzare i vincoli dei criteri dell'organizzazione per migliorare ulteriormente la sicurezza

I vincoli dei criteri organizzativi ti consentono di impostare criteri per migliorare ulteriormente il tuo livello di sicurezza. Ad esempio, puoi utilizzare i vincoli per limitare la creazione del bilanciatore del carico a determinati tipi, come solo i bilanciatori del carico interni o la limitazione all'utilizzo di indirizzi IP esterni.

Scalabilità della connettività dei cluster

Questa sezione illustra le opzioni scalabili per la connettività DNS e in uscita dai tuoi cluster verso Internet e i servizi Google.

Abilita NodeLocal DNSCache

GKE utilizza kube-dns per fornire il servizio DNS locale del cluster come componente aggiuntivo predefinito del cluster. kube-dns viene replicato in tutto il cluster in funzione del numero totale di core e nodi del cluster.

Puoi migliorare le prestazioni del DNS con NodeLocal DNSCache. NodeLocal DNSCache è un componente aggiuntivo di cui viene eseguito il deployment come DaemonSet e non richiede modifiche di configurazione dei pod. Le ricerche DNS al servizio pod locale non creano connessioni aperte che devono essere monitorate sul nodo per una scalabilità più ampia. Le ricerche di nomi host esterni vengono inoltrate a Cloud DNS, mentre tutte le altre query DNS vengono indirizzate a kube-dns.

Attiva NodeLocal DNSCache per tempi di ricerca delle query DNS più coerenti e scalabilità del cluster migliorata. Per i cluster Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita e non può essere sostituito.

La seguente opzione dell'interfaccia a riga di comando di Google Cloud abilita NodeLocal DNSCache quando crei un cluster: --addons NodeLocalDNS.

Se hai il controllo sul nome che le applicazioni cercano di risolvere, esistono vari modi per migliorare la scalabilità del DNS. Ad esempio, utilizza un nome di dominio completo (termina il nome host con un punto) o disabilita l'espansione del percorso di ricerca tramite l'opzione manifest Pod.dnsConfig.

Utilizza Cloud NAT per l'accesso a Internet da cluster privati

Per impostazione predefinita, i cluster privati non hanno accesso a Internet. Per consentire ai pod di raggiungere Internet, abilita Cloud NAT per ogni area geografica. Attiva Cloud NAT per gli intervalli primari e secondari nella subnet GKE. Assicurati di allocare un numero sufficiente di indirizzi IP per Cloud NAT e porte per VM.

Dovresti evitare il doppio SNAT per il traffico dei pod (SNAT prima sul nodo GKE e poi nuovamente su Cloud NAT). A meno che non sia richiesto a SNAT di nascondere gli IP dei pod verso le reti on-premise connesse da Cloud VPN o Cloud Interconnect, disable-default-snat e di trasferire il monitoraggio SNAT su Cloud NAT per la scalabilità. Questa soluzione funziona per tutti gli intervalli di IP primari e secondari delle subnet. Utilizza i criteri di rete per limitare il traffico esterno dopo l'abilitazione di Cloud NAT. Cloud NAT non è richiesto per accedere ai servizi Google.

Utilizzare l'accesso privato Google per accedere ai servizi Google

Nei cluster privati, i pod non hanno indirizzi IP pubblici per raggiungere i servizi pubblici, tra cui le API e i servizi Google. L'accesso privato Google consente alle risorse private di Google Cloud di raggiungere i servizi Google. I servizi Google standard supportati dall'accesso privato Google includono BigQuery, Autorizzazione binaria, Artifact Registry e altro ancora.

Questa opzione è disattivata per impostazione predefinita e deve essere abilitata sulla subnet associata al cluster durante la creazione della subnet.

L'opzione --enable-private-ip-google-access Google CLI di Google Cloud abilita l'accesso privato Google quando crei la subnet.

Applicazione di applicazioni

Quando crei applicazioni raggiungibili dall'esterno o dall'interno della tua organizzazione, assicurati di utilizzare le opzioni e il tipo di bilanciatore del carico corretti. Questa sezione fornisce alcuni suggerimenti su come esporre e scalare le applicazioni con Cloud Load Balancing.

Utilizza il bilanciamento del carico nativo del container

Utilizza il bilanciamento del carico nativo del container per esporre i servizi utilizzando HTTP(S) esternamente. Il bilanciamento del carico nativo del container consente meno hop di rete, minore latenza e distribuzione del traffico più precisa. Aumenta inoltre la visibilità nei tempi di round trip e consente di utilizzare funzionalità di bilanciamento del carico come Cloud CDN e Google Cloud Armor.

Scegli la risorsa GKE corretta per esporre la tua applicazione

A seconda dell'ambito dei client (interni, esterni o addirittura interni al cluster), dell'area geografica dell'applicazione e dei protocolli utilizzati, esistono diverse risorse GKE che puoi scegliere di utilizzare per esporre l'applicazione. La Panoramica del networking dei servizi illustra queste opzioni e può aiutarti a scegliere la risorsa migliore per esporre ogni parte dell'applicazione utilizzando le opzioni di bilanciamento del carico di Google Cloud.

Crea controlli di integrità basati su BackendConfig

Se usi una risorsa Ingress per esporre i servizi, utilizza una configurazione del controllo di integrità in un CRD di backend per utilizzare la funzionalità di controllo di integrità del bilanciamento del carico HTTP(S). Puoi indirizzare il controllo di integrità all'endpoint appropriato e impostare le tue soglie. Senza un CRD di backend, i controlli di integrità vengono dedotti dai parametri del probe di idoneità o utilizzano parametri predefiniti.

Utilizza i criteri del traffico locale per mantenere gli indirizzi IP originali

Quando utilizzi un bilanciatore del carico TCP/UDP interno con GKE, imposta l'opzione externalTrafficPolicy su Local per mantenere l'indirizzo IP di origine delle richieste. Utilizza questa opzione se la tua applicazione richiede l'indirizzo IP di origine originale. Tuttavia, l'opzione externalTrafficPolicy local può ridurre la diffusione ottimale del carico, perciò usa questa funzionalità solo quando necessario. Per i servizi HTTP(S), puoi utilizzare i controller Ingress e ottenere l'indirizzo IP originale leggendo l'intestazione X-Forwarded-For nella richiesta HTTP.

Operazioni e amministrazione

Le seguenti sezioni contengono le best practice operative che ti consentono di garantire opzioni di autorizzazione granulari per i carichi di lavoro. Per evitare di creare regole di firewall manuali, segui le best practice operative in questa sezione. Include anche suggerimenti per la distribuzione dei carichi di lavoro e per il monitoraggio e il logging in GKE.

Utilizzare Workload Identity per autenticare i carichi di lavoro verso le API di Google

Utilizza Workload Identity per accedere ad altri servizi di Google Cloud dal tuo cluster GKE. Workload Identity ti aiuta a mantenere il principio del privilegio minimo poiché puoi collegare gli account di servizio Kubernetes agli account di servizio Google. Gli account di servizio Kubernetes possono essere assegnati ai pod in modo da avere autorizzazioni granulari per accedere alle API di Google per carico di lavoro. Nei cluster Autopilot, l'identità del carico di lavoro è abilitata per impostazione predefinita.

Utilizza le autorizzazioni IAM per GKE per controllare i criteri nelle reti VPC condivise

Quando utilizzi reti VPC condivise, le regole firewall per i bilanciatori del carico vengono create automaticamente nel progetto host. Per evitare di dover creare le regole firewall manualmente, concedi il ruolo Amministratore sicurezza Compute all'account di servizio GKE nel progetto host denominato service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com. Sostituisci HOST_PROJECT_NUMBER con il numero del progetto host per il VPC condiviso.

Inoltre, le regole firewall create da GKE hanno sempre la priorità predefinita, 1000, quindi puoi impedire il flusso di traffico specifico creando regole firewall con una priorità più alta.

Se vuoi limitare la creazione di determinati tipi di bilanciatore del carico, utilizza i criteri organizzativi per limitare la creazione del bilanciatore del carico.

Usa i cluster a livello di regione e distribuisci i carichi di lavoro per l'alta disponibilità

I cluster a livello di area geografica possono aumentare la disponibilità delle applicazioni in un cluster poiché il piano di controllo e i nodi sono distribuiti in più zone.

Tuttavia, per garantire la migliore esperienza utente possibile in caso di errore di una zona, utilizza il gestore della scalabilità automatica del cluster per assicurarti che il cluster possa gestire il carico richiesto in qualsiasi momento. Utilizza anche l'anti-affinità pod per assicurarti che i pod di un determinato servizio siano pianificati in più zone. Per ulteriori informazioni su come configurare queste impostazioni per l'alta disponibilità e le ottimizzazioni dei costi, consulta le best practice per i cluster GKE ad alta disponibilità.

Usa Cloud Operations for GKE e il logging dei criteri di rete

Sebbene ciascuna organizzazione abbia requisiti diversi per la visibilità e il controllo, consigliamo di attivare il logging dei criteri di rete (beta). Questa funzionalità è disponibile solo con GKE Dataplane v2 (anche beta). Il logging dei criteri di rete offre visibilità sull'applicazione dei criteri e sui pattern di traffico dei pod. Tieni presente che sono previsti costi per il logging dei criteri di rete.

Per i cluster GKE che utilizzano la versione 1.14 o successive, Cloud Operations for GKE abilita sia il monitoraggio che il logging per impostazione predefinita e fornisce una dashboard per i tuoi cluster GKE. Inoltre, abilita le annotazioni GKE per i log di flusso VPC. Per impostazione predefinita, Cloud Operations for GKE raccoglie i log per tutti i carichi di lavoro di cui è stato eseguito il deployment nel cluster, ma esiste anche un'opzione dei log solo del sistema. Utilizza la dashboard di Cloud Operations for GKE per osservare e impostare gli avvisi. Tieni presente che sono previsti costi per la suite operativa di Google Cloud. Per i cluster creati in modalità Autopilot, Cloud Operations for GKE è abilitato automaticamente e non configurabile.

Riepilogo elenco di controllo

La tabella seguente riassume le best practice per configurare le opzioni di networking per i cluster GKE.

Area Esercitati
Progettazione VPC
Strategie di gestione degli indirizzi IP
Sicurezza
Scalabilità
Applicazioni di distribuzione
Operazioni e amministrazione

Passaggi successivi