Best practice per il networking di GKE

Questa pagina illustra le best practice per la configurazione delle opzioni di networking per i cluster Google Kubernetes Engine (GKE). È pensata come guida alla progettazione dell'architettura per cloud architect e ingegneri di rete con consigli per la configurazione dei cluster applicabili alla maggior parte dei cluster GKE. Prima di creare i cluster GKE, ti consigliamo di esaminare tutte le sezioni di questa pagina per comprendere le opzioni di networking supportate da GKE e le relative implicazioni.

Le opzioni di networking che scegli influiscono sull'architettura dei tuoi cluster GKE. Alcune di queste opzioni non possono essere modificate una volta configurate senza ricreare il cluster.

Prima di leggere questa pagina, assicurati di conoscere la terminologia e i concetti di networking di Kubernetes, un certo livello di concetti di networking generale e la rete Kubernetes. Per ulteriori informazioni, consulta la panoramica della rete GKE.

Quando esamini queste best practice, tieni presente quanto segue:

• Come prevedi di esporre i carichi di lavoro internamente alla tua rete VPC (Virtual Private Cloud), ad altri carichi di lavoro nel cluster, ad altri cluster GKE o esternamente a internet.
• Come prevedi di scalare i carichi di lavoro.
• I tipi di servizi Google che vuoi utilizzare.

Per un elenco di controllo riepilogativo di tutte le best practice, consulta il riepilogo dell'elenco di controllo.

Progettazione VPC

Quando progetti le tue reti VPC, segui le best practice per la progettazione delle reti VPC.

La sezione seguente fornisce alcuni consigli specifici per GKE per la progettazione della rete VPC.

Utilizzare i cluster nativi di VPC

Ti consigliamo di utilizzare i cluster nativi VPC. I cluster VPC nativi utilizzano intervalli di indirizzi IP alias sui nodi GKE e sono obbligatori per i cluster basati sul peering di rete VPC, per i cluster su VPC condivise e offrono molti altri vantaggi. Per i cluster creati in modalità Autopilot, la modalità nativa VPC è sempre attiva e non può essere disattivata.

I cluster nativi VPC si scalano più facilmente dei cluster basati su route senza utilizzare le route di Google Cloud e sono quindi meno soggetti a superare i limiti di routing.

I vantaggi dell'utilizzo di cluster nativi VPC vanno di pari passo con il supporto degli IP alias. Ad esempio, i gruppi di endpoint di rete (NEG) possono essere utilizzati solo con indirizzi IP secondari, pertanto sono supportati solo nei cluster VPC nativi.

Utilizzare le reti VPC condivise

I cluster GKE richiedono un'attenta pianificazione degli indirizzi IP. La maggior parte delle organizzazioni tende ad avere una struttura di gestione centralizzata con un team di amministrazione di rete che può allocare lo spazio degli indirizzi IP per i cluster e un amministratore della piattaforma per gestire i cluster. Questo tipo di struttura dell'organizzazione funziona bene con l'architettura della rete VPC condiviso di Google Cloud. Nell'architettura di rete VPC condiviso, un amministratore di rete può creare subnet e condividerle con i VPC. Puoi creare cluster GKE in un progetto di servizio e utilizzare le subnet condivise dal VPC condiviso nel progetto host. Il componente dell'indirizzo IP rimane nel progetto host e gli altri componenti del cluster nel progetto di servizio.

In generale, una rete VPC condiviso è un'architettura di uso frequente che è adatta alla maggior parte delle organizzazioni con un team di gestione centralizzato. Ti consigliamo di utilizzare le reti VPC condiviso per creare le subnet per i tuoi cluster GKE ed evitare conflitti di indirizzi IP all'interno della tua organizzazione. Potresti anche utilizzare le VPC condivise per la governance delle funzioni operative. Ad esempio, puoi avere un team di rete che si occupa solo di componenti e affidabilità della rete e un altro team che si occupa di GKE.

Strategie di gestione degli indirizzi IP

Tutti i cluster Kubernetes, inclusi i cluster GKE, richiedono un indirizzo IP univoco per ogni pod.

In GKE, tutti questi indirizzi IP sono instradabili in tutta la rete VPC. Pertanto, è necessaria la pianificazione degli indirizzi IP perché non possono sovrapporsi allo spazio di indirizzi IP interno utilizzato on-premise o in altri ambienti connessi. Le sezioni seguenti suggeriscono strategie per la gestione degli indirizzi IP con GKE.

Pianifica l'allocazione degli indirizzi IP richiesti

Ti consigliamo di utilizzare i cluster nativi VPC con Private Service Connect (PSC). I cluster che utilizzano il peering di rete VPC devono essere cluster VPC nativi.

I cluster nativi di VPC richiedono i seguenti intervalli di indirizzi IP:

• Intervallo di indirizzi IP del piano di controllo: utilizza una subnet /28 all'interno degli intervalli di indirizzi IP privati inclusi nel documento RFC 1918. Devi assicurarti che questa subnet non si sovrapponga ad altri routing interdominio senza classi (CIDR) nella rete VPC.
• Subnet del nodo: la subnet con l'intervallo di indirizzi IP principale da allocare per tutti i nodi del cluster. Anche i servizi di tipo LoadBalancer che utilizzano l'annotazione cloud.google.com/load-balancer-type: "Internal" utilizzano questa subnet per impostazione predefinita. Puoi anche utilizzare una subnet dedicata per i bilanciatori del carico interni.
• Intervallo di indirizzi IP del pod: l'intervallo IP che assegni a tutti i pod nel cluster. GKE esegue il provisioning di questo intervallo come alias della subnet. Per saperne di più, consulta Intervalli di indirizzi IP per i cluster VPC-native
• Intervallo di indirizzi IP di servizio: l'intervallo di indirizzi IP che assegni a tutti i servizi nel cluster. GKE esegue il provisioning di questo intervallo come alias della subnet.

Quando configuri la rete del cluster, devi definire una subnet dei nodi, un intervallo di indirizzi IP dei pod e un intervallo di indirizzi IP 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 non deve sovrapporsi ad alcun indirizzo IP nel gruppo di peering VPC perché GKE importa questa route nel progetto. Ciò significa che se nel tuo progetto hai route allo stesso CIDR, potresti riscontrare problemi di routing.

Quando crei un cluster, la subnet ha un intervallo principale per i nodi del cluster e deve esistere prima della creazione del cluster. La subnet deve essere in grado di supportare il numero massimo di nodi previsto nel cluster e gli indirizzi IP del bilanciatore del carico interno nel cluster che utilizza la subnet.

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 VPC.

Scegli intervalli di indirizzi IP sufficientemente ampi per includere tutti i nodi, i pod e i servizi del cluster.

Tieni presenti le seguenti limitazioni:

• Puoi estendere gli intervalli di indirizzi IP principali, ma non puoi ridurli. Questi intervalli di indirizzi IP non possono essere discontinui.
• Puoi ampliare l'intervallo dei pod aggiungendo altri intervalli dei pod al cluster o creando nuovi pool di nodi con altri intervalli dei pod secondari.
• L'intervallo di indirizzi IP secondario per i servizi non può essere espanso o modificato durante la vita del cluster.
• Esamina le limitazioni relative all'intervallo di indirizzi IP secondario per i pod e i servizi.

Utilizzare più indirizzi IP RFC 1918 privati

Per alcuni ambienti, lo spazio RFC 1918 in blocchi CIDR contigui di grandi dimensioni potrebbe essere già allocato in un'organizzazione. Puoi utilizzare lo spazio non RFC 1918 per gli indirizzi CIDR aggiuntivi per i cluster GKE, se non si sovrappongono agli indirizzi IP pubblici di proprietà di Google. Consigliamo di utilizzare la parte 100.64.0.0/10 dello spazio di indirizzi RFC perché lo spazio di indirizzi Classe E può presentare problemi di interoperabilità con l'hardware on-premise. Puoi utilizzare IP pubblici riutilizzati privatamente (PUPI).

Quando utilizzi indirizzi IP pubblici utilizzati privatamente, attieniti a questa opzione con cautela e valuta la possibilità di controllare gli annunci di route nelle reti on-premise verso internet.

Non devi utilizzare la traduzione dell'Network Address Translation (SNAT) in un cluster con traffico pod-to-pod e pod-to-service. Ciò viola il modello di networking di Kubernetes.

Kubernetes presuppone che tutti gli indirizzi IP non RFC 1918 siano indirizzi IP pubblici riutilizzati privatamente e utilizza SNAT per tutto il traffico proveniente da questi indirizzi.

Se utilizzi un indirizzo IP non RFC 1918 per il tuo cluster GKE, per i cluster standard dovrai disattivare esplicitamente SNAT o configurare l'agente di mascheramento IP per escludere gli indirizzi IP dei pod e gli intervalli di indirizzi IP secondari per i servizi dal SNAT. Per i cluster Autopilot, non è necessario alcun passaggio aggiuntivo.

Utilizza la modalità di subnet personalizzata

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

Il seguente esempio crea una rete denominata my-net-1 con modalità personalizzata per le subnet:

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

Pianifica la densità dei pod per nodo

Per impostazione predefinita, i cluster standard riservano un intervallo /24 per ogni nodo dello spazio 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 meno 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 sottorete del pod.

Se prevedi di eseguire più dei 110 pod per nodo predefiniti, 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, 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.

Evita sovrapposizioni con gli indirizzi IP utilizzati in altri ambienti

Puoi connettere la tua rete VPC a un ambiente on-premise o ad altri fornitori di servizi cloud tramite Cloud VPN o Cloud Interconnect. Questi ambienti possono condividere route, il che rende importante lo schema di gestione degli indirizzi IP on-premise 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 sottorete bilanciatore del carico distinta, questi servizi vengono esposti utilizzando un indirizzo IP della sottorete del nodo, il che può portare all'utilizzo di tutto lo spazio allocato in quella sottorete prima del previsto e può impedirti di eseguire il ridimensionamento del tuo cluster GKE al numero di nodi previsto.

L'utilizzo di una sottorete del bilanciatore del carico separata ti consente inoltre di filtrare il traffico verso e dai nodi GKE separatamente per i servizi esposti dal bilanciamento del carico TCP/UDP interno, il che ti consente di impostare confini di sicurezza più rigidi.

Riserva spazio IP sufficiente per il ridimensionamento automatico del cluster

Puoi utilizzare l'autoscaling del cluster per aggiungere e rimuovere dinamicamente i nodi nel cluster in modo da controllare i costi e migliorare l'utilizzo. Tuttavia, quando utilizzi lo strumento di scalabilità automatica del cluster, assicurati che la pianificazione degli indirizzi IP tenga conto della dimensione massima di tutti i pool di nodi. Ogni nuovo nodo richiede il proprio indirizzo IP e il proprio insieme di indirizzi IP allocabili per i pod in base ai pod configurati per nodo. Il numero di pod per nodo può essere configurato in modo diverso rispetto a quanto configurato a livello di cluster. Non puoi modificare il numero di pod per nodo dopo aver creato il cluster o il pool di nodi. Devi considerare i tipi di carichi di lavoro e assegnarli a pool di nodi distinti per un'allocazione ottimale degli indirizzi IP.

Valuta la possibilità di utilizzare il provisioning automatico dei nodi con il gestore della scalabilità automatica del cluster, in particolare se utilizzi cluster nativi VPC. Per ulteriori informazioni, consulta Intervalli di limitazione dei nodi.

Condividere gli indirizzi IP tra i cluster

Potresti dover condividere gli indirizzi IP tra i cluster se hai un team centralizzato che gestisce l'infrastruttura per i cluster. Per condividere gli indirizzi IP tra i cluster GKE, consulta Condividere intervalli di indirizzi IP tra i cluster GKE. Puoi ridurre l'esaurimento degli IP creando tre intervalli, per pod, servizi e nodi, e riutilizzandoli o condividendoli, in particolare in un modello VPC condiviso. Questa configurazione può anche semplificare la gestione degli indirizzi IP da parte degli amministratori di rete, poiché non è necessario creare subnet specifiche per ogni cluster.

Considera quanto segue:

• Come best practice, utilizza subnet e intervalli di indirizzi IP distinti per tutti i cluster.
• Puoi condividere l'intervallo di indirizzi IP del pod secondario, ma non è consigliabile perché un cluster potrebbe utilizzare tutti gli indirizzi IP.
• Puoi condividere intervalli di indirizzi IP di servizio secondari, ma questa funzionalità non funziona con Cloud DNS a livello di VPC per GKE.

Se non hai più indirizzi IP, puoi creare altri intervalli di indirizzi IP dei pod utilizzando il CIDR multi-pod disgiunto.

Condividere gli indirizzi IP per i servizi LoadBalancer interni

Puoi condividere un singolo indirizzo IP con un massimo di 50 backend utilizzando porte diverse. In questo modo puoi ridurre il numero di indirizzi IP necessari per i servizi LoadBalancer interni.

Per ulteriori informazioni, consulta IP condiviso.

Opzioni di sicurezza di rete

In questa sezione sono riportati alcuni consigli chiave per l'isolamento del cluster. La sicurezza di rete per i cluster GKE è una responsabilità condivisa tra Google e gli amministratori del cluster.

Utilizzare GKE Dataplane V2

GKE Dataplane V2 si basa su eBPF e offre un'esperienza di visibilità e sicurezza di rete integrata. Quando crei un cluster utilizzando GKE Dataplane V2, non devi abilitare esplicitamente i criteri di rete perché GKE Dataplane V2 gestisce il routing dei servizi, l'applicazione dei criteri di rete e il logging. Attiva il nuovo dataplane con l'opzione --enable-dataplane-v2 di Google Cloud CLI 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. Ti consigliamo di creare cluster con GKE Dataplane V2 per sfruttare appieno le funzionalità integrate, come il logging delle norme di rete.

Riduci al minimo l'esposizione dei nodi

In un cluster con solo nodi privati, i pod sono isolati dalle comunicazioni in entrata e in uscita (il perimetro del cluster). Puoi controllare questiflussi direzionali esponendo i servizi utilizzando il bilanciamento del carico e Cloud NAT, discussi nella sezione Connettività del cluster di questo documento. Il seguente diagramma mostra questo tipo di configurazione:

Questo diagramma mostra come può comunicare un cluster con nodi privati. 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.

Riduci al minimo l'esposizione del control plane del cluster

Il control plane ha due tipi di endpoint per l'accesso al cluster:

• Endpoint basato su DNS
• Endpoint basati su IP

L'endpoint DNS è accessibile da qualsiasi rete raggiungibile dalle API Google Cloud, incluse le reti on-premise o di altri cloud. Per attivare l'endpoint basato su DNS, utilizza il flag --enable-dns-access.

Il server API GKE può essere esposto anche come endpoint pubblico o privato basato su IP. Puoi decidere quale endpoint utilizzare quando crei il cluster. Puoi controllare l'accesso con le reti autorizzate, in cui sia gli endpoint pubblici sia quelli privati consentono per impostazione predefinita tutte le comunicazioni tra il pod e gli indirizzi IP dei nodi nel cluster. Per attivare un endpoint privato quando crei un cluster, utilizza il flag --enable-private-endpoint.

Autorizza l'accesso al control plane

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

Il seguente diagramma mostra la connettività tipica del control plane che utilizza reti autorizzate:

Questo diagramma mostra che gli utenti attendibili possono comunicare con il control plane GKE tramite l'endpoint pubblico perché fanno parte di reti autorizzate, mentre l'accesso da parte di utenti non attendibili è bloccato. La comunicazione verso e dal cluster GKE avviene tramite l'endpoint privato del piano di controllo.

Consenti la connettività del control plane

Alcuni pod di sistema su ogni nodo di lavoro dovranno raggiungere servizi come il server API Kubernetes (kube-apiserver), le API di Google o il server dei metadati. kube-apiserverdeve anche comunicare con alcuni pod di sistema, come event-exporter in particolare. Questa comunicazione è consentita per impostazione predefinita. Se implementi regole firewall VPC all'interno dei progetti (maggiori dettagli nella sezione Limitare il traffico del cluster), assicurati che i pod possano continuare a comunicare con kube-apiserver e con le API di Google.

Esegui il deployment di proxy per l'accesso al control plane da reti connesse in peering

Se il tuo cluster utilizza il peering di rete VPC, non puoi accedere al control plane del cluster da un'altra rete connessa in peering.

Se vuoi l'accesso diretto da un'altra rete connessa in peering o da un ambiente on-premise quando utilizzi un'architettura hub and spoke, esegui il deployment di proxy per il traffico del piano di controllo.

Limitare il traffico del cluster utilizzando i criteri di rete

Per i carichi di lavoro del cluster sono possibili più livelli di sicurezza di rete che possono essere combinati: regole firewall VPC, criteri firewall gerarchici e criteri di rete Kubernetes. Le regole firewall VPC e i criteri firewall gerarchici si applicano a livello di macchina virtuale (VM), ovvero ai nodi di lavoro su cui risiedono i pod del cluster GKE. I criteri di rete di Kubernetes vengono applicati a livello di pod per applicare i percorsi di traffico da pod a pod.

Se implementi i firewall VPC, la comunicazione obbligatoria del piano di controllo predefinita potrebbe essere interrotta, ad esempio la comunicazione del kubelet con il piano di controllo. GKE crea regole di firewall obbligatorie per impostazione predefinita, ma possono essere sovrascritte. Per alcuni implementazioni potrebbe essere necessario che il piano di controllo raggiunga il cluster sul servizio. Puoi utilizzare i firewall VPC per configurare un criterio di ingresso che renda accessibile il servizio.

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

Attiva i criteri di sicurezza di Google Cloud Armor per Ingress

Utilizzando i criteri di sicurezza di Google Cloud Armor, puoi proteggere le applicazioni che utilizzano bilanciatori del carico delle applicazioni esterni da attacchi DDoS e altri attacchi basati sul web bloccando questo traffico all'edge della rete. In GKE, attiva i criteri di sicurezza di Google Cloud Armor per le applicazioni utilizzando Ingress per bilanciatori del carico delle applicazioni esterni e aggiungendo un criterio di sicurezza a BackendConfig associato all'oggetto Ingress.

Utilizzare Identity-Aware Proxy per fornire l'autenticazione per le applicazioni con utenti IAM

Se vuoi implementare servizi a cui possono accedere solo gli utenti all'interno dell'organizzazione, ma senza che debbano essere sulla 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 tuo servizio Ingress. Identity-Aware Proxy può essere combinato con Google Cloud Armor.

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

Utilizzando le limitazioni dei criteri dell'organizzazione, puoi impostare criteri per migliorare ulteriormente la tua security posture. Ad esempio, puoi utilizzare i vincoli per limitare la creazione di bilanciatori del carico a determinati tipi, ad esempio solo bilanciatori del carico interni.

Scalabilità della connettività del cluster

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

Utilizzare Cloud DNS per GKE

Puoi utilizzare Cloud DNS per GKE per fornire la risoluzione DNS dei pod e dei servizi con DNS gestito senza un provider DNS ospitato nel cluster. Cloud DNS rimuove il sovraccarico della gestione di un server DNS ospitato in un cluster e non richiede la scalabilità, il monitoraggio o la gestione delle istanze DNS perché è un servizio Google ospitato.

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 nel cluster in funzione del numero totale di core e nodi nel cluster.

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

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

La seguente opzione Google Cloud CLI attiva NodeLocal DNSCache quando crei un cluster: --addons NodeLocalDNS.

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

Utilizzare Cloud NAT per l'accesso a internet dai cluster

Per impostazione predefinita, i cluster con nodi privati abilitati non hanno accesso a internet. Per consentire ai pod di accedere a internet, abilita Cloud NAT per ogni regione. Come minimo, abilita Cloud NAT per gli intervalli principali e secondari nella subnet GKE. Assicurati di allocare indirizzi IP per Cloud NAT e porte per VM sufficienti.

Utilizza le seguenti best practice per la configurazione del gateway Cloud NAT quando utilizzi Cloud NAT per i cluster:

• Quando crei il gateway Cloud NAT, attivalo solo per gli intervalli di subnet utilizzati dai tuoi cluster. Contando tutti i nodi in tutti i cluster, puoi determinare quante VM consumer NAT sono presenti nel progetto.

• Utilizza l'allocazione dinamica delle porte per assegnare numeri diversi di porte per VM in base all'utilizzo della VM. Inizia con un numero minimo di porte pari a 64 e un numero massimo di porte pari a 2048.

• Se devi gestire molte connessioni simultanee alla stessa tripletta di destinazione, abbassa il timeout TIME_WAIT TCP dal valore predefinito 120s a 5s. Per ulteriori informazioni, consulta Specificare timeout diversi per il NAT.

• Abilita il logging degli errori di Cloud NAT per controllare i log correlati.

• Controlla i log del gateway Cloud NAT dopo averlo configurato. Per ridurre i problemi di stato di allocazione persi, potrebbe essere necessario aumentare il numero massimo di porte per VM.

Devi evitare il doppio SNAT per il traffico dei pod (prima SNAT sul nodo GKE e poi di nuovo con Cloud NAT). A meno che non sia necessario SNAT per nascondere gli indirizzi IP del pod alle reti on-premise collegate da Cloud VPN o Cloud Interconnect, disable-default-snat e scaricare il monitoraggio SNAT su Cloud NAT per la scalabilità. Questa soluzione funziona per tutti gli intervalli IP delle subnet principali e secondarie. Utilizza i criteri di rete per limitare il traffico esterno dopo aver attivato Cloud NAT. Cloud NAT non è obbligatorio per accedere ai servizi Google.

Utilizzare l'accesso privato Google per accedere ai servizi Google

Nei cluster con nodi privati, i pod non hanno indirizzi IP pubblici per raggiungere i servizi pubblici, incluse le API e i servizi Google. L'accesso privato Google consente alle risorse private Google Cloud di raggiungere i servizi Google.

L'accesso privato Google è abilitato per impostazione predefinita nei cluster con nodi privati, ad eccezione dei cluster VPC condiviso.

Pubblicazione di applicazioni

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

Utilizzare il bilanciamento del carico nativo del container

Utilizza il bilanciamento del carico nativo del container quando esponi i servizi utilizzando HTTP(S) esternamente. Il bilanciamento del carico nativo del container consente meno hop di rete, una latenza inferiore e una distribuzione del traffico più esatta. Inoltre, aumenta la visibilità nel tempo di round trip e ti consente di utilizzare funzionalità di bilanciamento del carico come Google Cloud Armor.

Scegli la risorsa GKE corretta per esporre l'applicazione

A seconda dell'ambito dei tuoi client (interni, esterni o anche all'interno del cluster), della regionalità della tua applicazione e dei protocolli che utilizzi, puoi scegliere tra diverse risorse GKE da utilizzare per esporre la tua applicazione. La Panoramica della rete di servizi spiega queste opzioni e può aiutarti a scegliere la risorsa migliore per esporre ogni parte della tua applicazione utilizzando le opzioni di bilanciamento del carico di Google Cloud.

Creare controlli di integrità in base a BackendConfig

Se utilizzi un Ingress per esporre i servizi, utilizza una configurazione del controllo di integrità in un CRD BackendConfig per utilizzare la funzionalità di controllo di integrità del bilanciatore del carico delle applicazioni esterno. Puoi indirizzare il controllo di integrità all'endpoint appropriato e impostare le tue soglie. Senza un'entità CRD BackendConfig, i controlli di integrità vengono dedotti dai parametri del probe di idoneità o utilizzano i parametri predefiniti.

Utilizza i criteri di traffico locale per preservare gli indirizzi IP originali

Quando utilizzi un bilanciatore del carico di rete passthrough interno con GKE, imposta l'opzione externalTrafficPolicy su Local per preservare 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ò portare a una distribuzione del carico meno ottimale, pertanto utilizza questa funzionalità solo se 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.

Utilizzare Private Service Connect

Puoi utilizzare Private Service Connect per condividere i servizi di bilanciamento del carico di rete passthrough interni in altre reti VPC. Questo è utile per i servizi ospitati su cluster GKE, ma che servono clienti in progetti e VPC diversi.

Puoi utilizzare Private Service Connect per ridurre il consumo di indirizzi IP fornendo connettività tra VPC con indirizzi IP sovrapposti.

Operazioni e amministrazione

Le sezioni seguenti contengono best practice operative che ti aiutano a garantire opzioni di autorizzazione granulari per i tuoi carichi di lavoro. Per evitare di creare regole firewall manuali, segui le best practice operative riportate in questa sezione. Inoltre, include consigli per la distribuzione dei carichi di lavoro e per il monitoraggio e il logging in GKE.

Utilizzare IAM per le autorizzazioni GKE per controllare i criteri nelle reti VPC condiviso

Quando utilizzi le reti VPC condivise, le regole firewall per i bilanciatori del carico vengono create automaticamente nel progetto host.

Per evitare di dover creare manualmente le regole del firewall, assegna un ruolo personalizzato con privilegi minimi 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 del progetto host per la VPC condiviso.

Il ruolo personalizzato che crei deve disporre delle seguenti autorizzazioni:

• compute.firewalls.create
• compute.firewalls.get
• compute.firewalls.list
• compute.firewalls.delete

Inoltre, le regole firewall create da GKE hanno sempre la priorità predefinita di 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 bilanciatori del carico, utilizza i criteri dell'organizzazione per limitare la creazione dei bilanciatori del carico.

Utilizza i cluster regionali e distribuisci i carichi di lavoro per garantire una disponibilità elevata

I cluster a livello di regione possono aumentare la disponibilità delle applicazioni in un cluster perché il piano di controllo e i nodi del cluster sono distribuiti su più zone.

Puoi anche utilizzare l'anti-affinità dei pod per assicurarti che i pod di un determinato servizio vengano 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 altamente disponibili.

Utilizza Cloud Logging e Cloud Monitoring e abilita il logging dei criteri di rete

Sebbene ogni organizzazione abbia requisiti diversi per la visibilità e il controllo, consigliamo di attivare il logging delle norme di rete. Questa funzionalità è disponibile solo con GKE Dataplane V2. Il logging dei criteri di rete fornisce visibilità sull'applicazione dei criteri e sui pattern di traffico dei pod. Tieni conto che il logging delle norme di rete comporta dei costi.

Per i cluster GKE che utilizzano la versione 1.14 o successive, Logging e monitoring sono entrambi abilitati per impostazione predefinita. Il monitoraggio fornisce una dashboard per i tuoi cluster GKE. Il logging consente inoltre di attivare le annotazioni GKE per i log di flusso VPC. Per impostazione predefinita, Logging raccoglie i log per tutti i carichi di lavoro di cui è stato eseguito il deployment nel cluster, ma esiste anche un'opzione per i log solo di sistema. Utilizza la dashboard GKE per osservare e impostare gli avvisi. Per i cluster creati in modalità Autopilot, il monitoraggio e la registrazione sono abilitati automaticamente e non sono configurabili.

Tieni presente che sono previsti costi per Google Cloud Observability.

Riepilogo elenco di controllo

Passaggi successivi

• Approfondimenti sulle best practice di GKE

• Best practice per l'architettura multi-tenancy aziendale

• Esposizione delle applicazioni GKE tramite Ingress e Services

• Best practice e architetture di riferimento per la progettazione di VPC