Questo documento descrive le best practice per la configurazione delle opzioni di networking per i cluster Google Kubernetes Engine (GKE). È una guida alla pianificazione dell'architettura per Cloud Architect e Network Engineer con suggerimenti di configurazione dei cluster applicabili alla maggior parte dei cluster GKE. Prima di creare i tuoi cluster GKE, ti consigliamo di rivedere tutte le sezioni di questo documento 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 dopo la configurazione senza ricreare il cluster.
Questo documento non ha lo scopo di introdurre i concetti o la terminologia di networking di Kubernetes e presuppone che tu abbia già un certo livello di concetti generali di networking e una conoscenza del networking di Kubernetes. Per ulteriori informazioni, consulta la panoramica della rete GKE.
Durante la revisione del documento, tieni presente quanto segue:
- Come prevedi di esporre i carichi di lavoro internamente alla rete Virtual Private Cloud (VPC), 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
Durante la progettazione delle reti VPC, segui le best practice per la progettazione dei VPC.
Questa sezione fornisce alcuni suggerimenti specifici per GKE per la progettazione di reti VPC.
Usa cluster nativi di VPC
Ti consigliamo di utilizzare cluster nativi di VPC. I cluster nativi di VPC utilizzano intervalli di indirizzi IP alias sui nodi GKE e sono necessari per i cluster GKE privati e per creare cluster su VPC condivisi e hanno molti altri vantaggi. Per i cluster creati in modalità Autopilot, la modalità nativa di VPC è sempre attiva e non può essere disattivata.
I cluster nativi di VPC scalano più facilmente rispetto ai cluster basati su route senza utilizzare route di Google Cloud, quindi sono meno soggetti a raggiungere i limiti di routing.
I vantaggi dell'utilizzo di cluster nativi di 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, per cui sono supportati solo sui cluster nativi di VPC.
Utilizza 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 della rete che può allocare lo spazio di indirizzi IP per i cluster e un amministratore della piattaforma per il funzionamento dei cluster. Questo tipo di struttura organizzativa funziona bene con l'architettura di 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, mentre gli altri componenti del cluster risiedono nel progetto di servizio.
In generale, una rete VPC condiviso è un'architettura utilizzata di frequente ed è 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 cluster GKE ed evitare conflitti di indirizzi IP nella tua organizzazione. Potresti anche voler utilizzare i VPC condivisi per la governance delle funzioni operative. Ad esempio, puoi avere un team di rete che si occupa esclusivamente di componenti di rete e affidabilità 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.
Per saperne di più, consulta la pagina relativa al modello di networking di GKE.In GKE, tutti questi indirizzi IP sono instradabili in tutta la rete VPC. Pertanto, è necessaria la pianificazione degli indirizzi IP perché gli indirizzi non possono sovrapporsi allo spazio di indirizzi IP interni utilizzato on-premise o in altri ambienti connessi. Le sezioni seguenti suggeriscono strategie per la gestione degli indirizzi IP con GKE.
Best practice:
Pianifica l'allocazione degli indirizzi IP richiesta.Se necessario, utilizza uno spazio non conforme alla RFC 1918.
Utilizza la modalità subnet personalizzata.
Pianifica la densità dei pod per nodo.
Evita sovrapposizioni con gli indirizzi IP utilizzati in altri ambienti.
Crea una subnet del bilanciatore del carico.
Prenota spazio di indirizzi IP sufficiente per il gestore della scalabilità automatica dei cluster.
Condividi gli indirizzi IP tra i cluster.
Condividi gli indirizzi IP per i servizi LoadBalancer interni.
Pianifica l'allocazione richiesta degli indirizzi IP
I cluster privati sono consigliati e sono ulteriormente discussi nella sezione Sicurezza di rete. Nel contesto dei cluster privati, sono supportati solo i cluster nativi di VPC e richiedono i seguenti intervalli di indirizzi IP:
- Intervallo di indirizzi IP del piano di controllo: utilizza una subnet /28 negli intervalli privati di indirizzi IP inclusi nella documentazione RFC 1918. Devi assicurarti che questa subnet non si sovrapponga ad altri routing tra domini senza classe (CIDR) nella rete VPC.
- Subnet del nodo: la subnet con l'intervallo di indirizzi IP principali che vuoi allocare per tutti i nodi nel cluster. Anche i servizi di tipo
LoadBalancerche utilizzano l'annotazionecloud.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 dei pod: l'intervallo IP allocato per tutti i pod nel cluster. GKE esegue il provisioning di questo intervallo come alias della subnet. Per maggiori informazioni, consulta Intervalli di indirizzi IP per cluster nativi VPC
- Intervallo di indirizzi IP dei servizi: l'intervallo di indirizzi IP allocati per tutti i servizi nel cluster. GKE esegue il provisioning di questo intervallo come alias della subnet.
Per i cluster privati, devi definire una subnet dei nodi, un intervallo di indirizzi IP dei pod e un intervallo di indirizzi IP del servizio.
Se vuoi utilizzare lo spazio di indirizzi IP in modo più efficiente, consulta Ridurre l'utilizzo degli indirizzi IP interni in GKE.L'intervallo di indirizzi IP del piano di controllo è dedicato al piano di controllo gestito da GKE che risiede in un progetto tenant gestito da Google e connesso in peering con il tuo VPC. Questo intervallo di indirizzi IP non deve sovrapporsi agli indirizzi IP nel gruppo di peering VPC perché GKE importa questa route nel tuo progetto. Ciò significa che se nel tuo progetto sono presenti route allo stesso CIDR, potresti riscontrare problemi di routing.
Quando crei un cluster, la subnet ha un intervallo primario per i nodi del cluster e deve esistere prima della creazione del cluster. La subnet deve contenere il numero massimo di nodi previsto nel cluster e gli indirizzi IP del bilanciatore del carico interno nel cluster utilizzando la subnet.
Puoi utilizzare il gestore della scalabilità automatica dei cluster per limitare il numero massimo di nodi.Gli intervalli di indirizzi IP di pod e servizio sono rappresentati come intervalli secondari distinti della subnet, implementati come indirizzi IP alias nei cluster nativi di VPC.
Scegli intervalli di indirizzi IP sufficientemente ampi in modo da ospitare tutti i nodi, pod e servizi per il cluster.
Considera le seguenti limitazioni:
- Puoi espandere gli intervalli di indirizzi IP principali, ma non puoi ridurli. Questi intervalli di indirizzi IP non possono essere discontinui.
- Puoi espandere l'intervallo di pod aggiungendo intervalli di pod aggiuntivi al cluster o creando nuovi pool di nodi con altri intervalli di pod secondari.
- L'intervallo di indirizzi IP secondari per i servizi non può essere espanso o modificato durante la vita del cluster.
- Esamina le limitazioni per l'intervallo di indirizzi IP secondari per pod e servizi.
Utilizza 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 spazio non conforme alla RFC 1918 per altri CIDR per i cluster GKE, a condizione che non si sovrappongano agli indirizzi IP pubblici di proprietà di Google. Ti consigliamo di utilizzare la parte 100.64.0.0/10 dello spazio di indirizzi RFC perché lo spazio di indirizzi di Classe E può presentare problemi di interoperabilità con l'hardware on-premise. Puoi utilizzare IP pubblici riutilizzati privatamente (PUPI).
Se utilizzi indirizzi IP pubblici riutilizzati privatamente, scegli con cautela e valuta la possibilità di controllare gli annunci di route nelle reti on-premise verso internet quando scegli questa opzione.
Non dovresti utilizzare la funzione SNAT (Network Address Translation) di origine in un cluster con traffico da pod a pod e da pod a servizio. Questo rompe il modello di networking di Kubernetes.
Kubernetes presuppone che tutti gli indirizzi IP non conformi alla 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 conforme alla RFC 1918 per il cluster GKE, per i cluster Standard dovrai disabilitare esplicitamente SNAT o configurare l'agente configurare l'agente di mascheramento IP per escludere gli indirizzi IP dei pod del cluster e gli intervalli di indirizzi IP secondari per i servizi da SNAT. Per i cluster Autopilot, questa operazione non richiede passaggi aggiuntivi.
Usa modalità subnet personalizzata
Quando configuri la rete, selezioni anche la modalità della subnet: auto (predefinita)
o custom (consigliata). La modalità auto lascia l'allocazione delle subnet a Google ed è una buona opzione per iniziare senza pianificare l'indirizzo IP. Tuttavia, ti consigliamo di selezionare la modalità custom perché consente di scegliere intervalli di indirizzi IP che non si sovrapporranno ad altri intervalli nel tuo ambiente. Se utilizzi un VPC condiviso, sia un amministratore dell'organizzazione che un amministratore di rete può selezionare questa modalità.
L'esempio seguente crea una rete denominata my-net-1 in modalità subnet personalizzata:
gcloud compute networks create my-net-1 --subnet-mode custom
Pianifica la densità dei pod per nodo
Per impostazione predefinita, i cluster standard prenotano un intervallo /24 per ogni nodo al di fuori dello spazio di 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 tuoi 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 in modo da preservare lo spazio di indirizzi IP nella subnet dei pod.
Se prevedi di eseguire più di 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 almeno 16 core 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 gli indirizzi IP utilizzati in altri ambienti
Puoi connettere la tua rete VPC a un ambiente on-premise o ad altri provider di servizi cloud tramite Cloud VPN o Cloud Interconnect. Questi ambienti possono condividere le 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 agli indirizzi IP 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 vengono esposti utilizzando un indirizzo IP dalla subnet del nodo, il che può comportare l'utilizzo di tutto lo spazio allocato in quella subnet prima del previsto e può impedirti di scalare il tuo cluster GKE fino al numero previsto di nodi.
Se utilizzi una subnet del bilanciatore del carico separata, puoi anche filtrare il traffico da e verso i nodi GKE separatamente ai servizi esposti dal bilanciamento del carico TCP/UDP interno, che ti consente di impostare limiti di sicurezza più rigidi.
Prenota spazio di indirizzi IP sufficiente per il gestore della scalabilità automatica dei cluster
Puoi utilizzare il gestore della scalabilità automatica del cluster per aggiungere e rimuovere dinamicamente i nodi nel cluster, 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 della dimensione massima di tutti i pool di nodi. Ogni nuovo nodo richiede un proprio indirizzo IP e un proprio set allocabile di indirizzi IP dei pod in base ai pod configurati per nodo. Il numero di pod per nodo può essere configurato in modo diverso rispetto a quanto viene configurato a livello di cluster. Non puoi modificare il numero di pod per nodo dopo aver creato il cluster o il pool di nodi. Dovresti prendere in considerazione 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 dei cluster, in particolare se usi cluster nativi di VPC. Per ulteriori informazioni, consulta Intervalli di limitazione dei nodi.
Condividi gli indirizzi IP tra i cluster
Potrebbe essere necessario 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 Condivisione di intervalli di indirizzi IP tra cluster GKE. Puoi ridurre l'esaurimento degli indirizzi IP creando tre intervalli, per pod, servizi e nodi, e riutilizzandoli o condividendoli, soprattutto in un modello VPC condiviso. Questa configurazione può inoltre semplificare la gestione degli indirizzi IP da parte degli amministratori di rete, perché non è necessario creare subnet specifiche per ogni cluster.
Considera quanto segue:
- Come best practice, utilizza subnet e intervalli di indirizzi IP separati per tutti i cluster.
- Puoi condividere l'intervallo di indirizzi IP del pod secondario, ma è sconsigliato perché un cluster potrebbe utilizzare tutti gli indirizzi IP.
- Puoi condividere intervalli di indirizzi IP secondari del servizio, ma questa funzionalità non funziona con Cloud DNS per GKE con ambito VPC.
Se esaurisci gli indirizzi IP, puoi creare intervalli di indirizzi IP dei pod aggiuntivi utilizzando il CIDR di più pod discontinui.
Condividi gli indirizzi IP per i servizi LoadBalancer interni
Puoi condividere un singolo indirizzo IP con un massimo di 50 backend che utilizzano 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 della rete
In questa sezione sono 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 tuo cluster.
Best practice:
Utilizza GKE Dataplane V2.Scegli un tipo di cluster privato.
Riduci al minimo l'esposizione al piano di controllo del cluster.
Autorizza l'accesso al piano di controllo.
Consenti la connettività del piano di controllo.
Esegui il deployment dei proxy per l'accesso al piano di controllo da reti in peering.
Limita il traffico del cluster utilizzando i criteri di rete.
Abilita i criteri di sicurezza di Google Cloud Armor per Ingress.
Utilizza Identity-Aware Proxy per fornire l'autenticazione per le applicazioni con utenti IAM.
Utilizza i vincoli dei criteri dell'organizzazione per migliorare ulteriormente la sicurezza.
Utilizza GKE Dataplane V2
GKE Dataplane V2 è basato su eBPF e offre un'esperienza integrata di sicurezza e visibilità di rete. Quando crei un cluster utilizzando GKE Dataplane V2, non è necessario abilitare esplicitamente i criteri di rete poiché 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 --enable-dataplane-v2 dell'interfaccia a riga di comando di Google Cloud CLI durante la creazione di un cluster. Dopo aver configurato i criteri di rete, è possibile configurare un oggetto CRD predefinito di NetworkLogging 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 dei criteri di rete.
Scegli un tipo di cluster privato
I cluster pubblici hanno indirizzi IP sia privati che pubblici sui nodi e solo un endpoint pubblico per i nodi del piano di controllo. I cluster privati offrono un maggiore isolamento avendo solo indirizzi IP interni sui nodi e avendo endpoint privati o pubblici per i nodi del piano di controllo (che possono essere ulteriormente isolati e vengono esaminati 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. Ti consigliamo di scegliere cluster privati.
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 tramite il bilanciamento del carico e Cloud NAT, come descritto nella sezione relativa alla connettività dei cluster di questo documento. Il seguente diagramma mostra questo tipo di configurazione:
Questo diagramma mostra come può comunicare un cluster privato. 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 a internet è disponibile solo utilizzando Cloud NAT.
Per ulteriori informazioni, esamina i requisiti, le restrizioni e le limitazioni dei cluster privati.
Riduci al minimo l'esposizione al piano di controllo del cluster
In un cluster privato, il server API GKE può essere esposto come endpoint pubblico o privato. Puoi decidere quale endpoint usare
quando crei il cluster. Puoi controllare l'accesso con reti autorizzate, dove sia gli endpoint pubblici che privati consentono per impostazione predefinita tutte le comunicazioni tra il pod e gli indirizzi IP dei nodi nel cluster. Per abilitare un endpoint privato quando crei un cluster, utilizza il flag --enable-private-endpoint.
Autorizza l'accesso al piano di controllo
Le reti autorizzate possono aiutare a determinare quali subnet di indirizzi 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, questi intervalli di indirizzi IP di origine devono essere privati. Se è abilitato un endpoint pubblico, puoi consentire intervalli di indirizzi IP pubblici o interni.
Configura gli pubblicità con route personalizzate per consentire all'endpoint privato del piano di controllo del cluster di essere raggiungibile da un ambiente on-premise. Puoi rendere l'endpoint privato dell'API GKE
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 mediante reti autorizzate:
Questo diagramma mostra che gli utenti attendibili sono in grado di comunicare con il piano di controllo GKE tramite l'endpoint pubblico in quanto fanno parte di reti autorizzate, mentre l'accesso da parte di utenti non attendibili è bloccato. La comunicazione da e verso il cluster GKE avviene tramite l'endpoint privato del piano di controllo.
Consenti la connettività del piano di controllo
Alcuni pod di sistema su ogni nodo worker dovranno raggiungere servizi quali
il server API Kubernetes (kube-apiserver), le API di Google o il server dei metadati.
kube-apiserver deve anche comunicare con alcuni pod di sistema, come
event-exporter in particolare. 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 quei pod possano continuare a comunicare con kube-apiserver e con le API di Google.
Esegui il deployment dei proxy per l'accesso al piano di controllo da reti in peering
L'accesso al piano di controllo per i cluster GKE privati avviene tramite il peering di rete VPC. Il peering di rete VPC non è transitorio, pertanto non è possibile 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 e spoke, esegui il deployment dei proxy per il traffico del piano di controllo.
Limita il traffico del cluster utilizzando i criteri di rete
Sono possibili più livelli di sicurezza di rete per i carichi di lavoro dei cluster 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 i nodi worker su cui risiedono i pod del cluster GKE. I criteri di rete di Kubernetes si applicano a livello di pod per applicare i percorsi di traffico tra pod e pod.
L'implementazione dei firewall VPC può interrompere la comunicazione predefinita necessaria sul piano di controllo, ad esempio la comunicazione kubelet con il piano di controllo. GKE crea le regole firewall richieste per impostazione predefinita, ma possono essere sovrascritte. Alcuni deployment potrebbero richiedere il piano di controllo per raggiungere il cluster sul servizio. Puoi usare i firewall VPC per configurare un criterio in entrata che renda il servizio accessibile.
I criteri di rete di GKE sono configurati tramite l'API
Network Policy di Kubernetes per applicare la comunicazione tra i pod di un 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 del progetto base per la limitazione del traffico di Anthos.
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 usano Application Load Balancer esterni da attacchi DDoS e altri attacchi basati sul web bloccando il traffico sul perimetro della rete. In GKE, abilita i criteri di sicurezza di Google Cloud Armor per le applicazioni utilizzando Ingress per i bilanciatori del carico delle applicazioni esterni e aggiungendo un criterio di sicurezza a BackendConfig collegato all'oggetto Ingress.
Utilizza Identity-Aware Proxy per fornire l'autenticazione per le applicazioni con utenti IAM
Se vuoi eseguire il deployment di servizi accessibili solo agli utenti all'interno dell'organizzazione, ma senza dover utilizzare la rete aziendale, puoi utilizzare Identity-Aware Proxy per creare un livello di autenticazione per queste applicazioni. Per abilitare 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 i vincoli dei criteri organizzativi, puoi impostare criteri per migliorare ulteriormente la strategia di sicurezza. Ad esempio, puoi utilizzare i vincoli per limitare la creazione del bilanciatore del carico a determinati tipi, ad esempio solo i bilanciatori del carico interni.
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.
Best practice:
Utilizza Cloud DNS per GKE.Abilita NodeLocal DNSCache.
Utilizza Cloud NAT per l'accesso a internet dai cluster privati.
Utilizzare l'accesso privato Google per accedere ai servizi Google.
Utilizza Cloud DNS per GKE
Puoi utilizzare Cloud DNS per GKE per fornire una risoluzione DNS di pod e servizio con DNS gestito senza un provider DNS ospitato nel cluster. Cloud DNS elimina l'overhead associato alla gestione di un server DNS ospitato nel cluster e non richiede scalabilità, monitoraggio o 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 come 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 non richiede modifiche alla configurazione del 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 di nomi host esterni vengono inoltrate a Cloud DNS, mentre tutte le altre query DNS vanno a kube-dns.
Abilita NodeLocal DNSCache per tempi di ricerca delle query DNS più coerenti e una migliore scalabilità dei cluster. Per i cluster Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita e non può essere sostituito.
La seguente opzione di Google Cloud CLI abilita 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 (che termina il nome host con un punto) o disabilita l'espansione del percorso di ricerca tramite l'opzione manifest Pod.dnsConfig.
Usa 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 connettersi a internet, abilita Cloud NAT per ogni regione. Abilita Cloud NAT come minimo 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.
Usa le seguenti best practice per la configurazione del gateway Cloud NAT quando utilizzi Cloud NAT per i cluster privati:
- Quando crei il gateway Cloud NAT, abilitalo solo per gli intervalli di subnet utilizzati dai tuoi cluster. Contando tutti i nodi in tutti i cluster, puoi determinare il numero di VM consumer NAT presenti nel progetto.
Utilizza l'allocazione dinamica delle porte per allocare un numero diverso di porte per VM, in base all'utilizzo della VM. Inizia con un numero minimo di porte pari a 64 e un massimo di 2048.
Se devi gestire molte connessioni simultanee alla stessa destinazione a 3 tuple, abbassa il timeout TCP
TIME_WAITdal valore predefinito di120sa5s. Per ulteriori informazioni, consulta Specificare timeout diversi per NAT.Abilita il logging degli errori di Cloud NAT per controllare i log correlati.
Controlla i log del gateway Cloud NAT dopo aver configurato il gateway. Per ridurre i problemi di eliminazione dello stato di allocazione, potrebbe essere necessario aumentare il numero massimo di porte per VM.
Dovresti evitare SNAT doppio per il traffico dei pod (prima SNAT sul nodo GKE e poi di nuovo con Cloud NAT). A meno che tu non abbia bisogno di SNAT di nascondere gli indirizzi IP dei pod nelle reti on-premise connesse da Cloud VPN o Cloud Interconnect, disable-default-snat e trasferire il monitoraggio SNAT a Cloud NAT per la scalabilità. Questa soluzione funziona per tutti gli intervalli IP di subnet principali e secondarie. Utilizza i criteri di rete per limitare il traffico esterno dopo aver abilitato Cloud NAT. Cloud NAT non è necessario 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, compresi i servizi e le API di 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 privati, ad eccezione dei cluster VPC condiviso.
Gestione delle applicazioni
Quando crei applicazioni raggiungibili esternamente o all'interno della tua organizzazione, assicurati di utilizzare le opzioni e il tipo di bilanciatore del carico appropriati. Questa sezione fornisce alcuni suggerimenti su come esporre e scalare le applicazioni con Cloud Load Balancing.
Best practice:
Utilizza il bilanciamento del carico nativo del container.Scegli la risorsa GKE corretta per esporre l'applicazione.
Creare controlli di integrità basati su BackendConfig.
Utilizza i criteri relativi al traffico locale per preservare gli indirizzi IP originali.
Utilizza Private Service Connect.
Utilizza il bilanciamento del carico nativo del container
Utilizza il bilanciamento del carico nativo del container durante l'esposizione dei servizi tramite HTTP(S) all'esterno. Il bilanciamento del carico nativo del container consente meno hop di rete, minore latenza e una distribuzione più precisa del traffico. Inoltre, aumenta la visibilità nel tempo di round trip e 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 client (interno, esterno o anche interno del cluster), della regione dell'applicazione e dei protocolli che utilizzi, puoi scegliere di utilizzare diverse risorse GKE per esporre la tua applicazione. La panoramica sul networking dei 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.
Crea controlli di integrità basati su BackendConfig
Se utilizzi una risorsa Ingress per esporre i servizi, utilizza una configurazione del controllo di integrità in una CRD BackendConfig per usare la funzionalità di controllo di integrità dell'Application Load Balancer esterno. Puoi indirizzare il controllo di integrità all'endpoint appropriato e impostare le tue soglie. Senza un CRD BackendConfig, i controlli di integrità vengono dedotti dai parametri del probe di idoneità oppure utilizzano 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, quindi utilizza 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.
Utilizza Private Service Connect
Puoi utilizzare Private Service Connect per condividere i servizi di bilanciatore del carico di rete passthrough interno su altre reti VPC. Questa funzionalità è utile per i servizi ospitati sui cluster GKE, ma che forniscono servizi ai clienti in esecuzione in progetti diversi e in 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
Best practice:
Utilizza le autorizzazioni IAM per GKE per controllare i criteri nelle VPC condiviso condivise.Utilizza cluster a livello di regione e distribuisci i carichi di lavoro per l'alta disponibilità.
Utilizza Cloud Logging e Cloud Monitoring e abilita il logging dei criteri di rete.
Le seguenti sezioni contengono best practice operative che consentono di garantire opzioni di autorizzazione granulari per i carichi di lavoro. Per evitare di creare regole firewall manuali, segui le best practice operative riportate in questa sezione. Include inoltre suggerimenti per la distribuzione dei carichi di lavoro e per il monitoraggio e il logging in GKE.
Utilizza le autorizzazioni IAM per GKE per controllare i criteri nelle reti VPC condiviso
Quando si utilizzano 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 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 host per il VPC condiviso.
Il ruolo personalizzato creato deve avere le seguenti autorizzazioni:
compute.firewalls.createcompute.firewalls.getcompute.firewalls.listcompute.firewalls.delete
Inoltre, la priorità predefinita delle regole firewall create da GKE è 1000, per cui puoi impedire il flusso di traffico specifico creando regole firewall con una priorità più elevata.
Se vuoi limitare la creazione di determinati tipi di bilanciatori del carico, utilizza i criteri dell'organizzazione per limitare la creazione del bilanciatore del carico.
Usa cluster a livello di regione e distribuisci i carichi di lavoro per l'alta disponibilità
I cluster a livello di regione possono aumentare la disponibilità di applicazioni in un cluster perché il piano di controllo e i nodi del cluster 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 sia in grado di gestire il carico richiesto in qualsiasi momento.Puoi anche utilizzare l'anti-affinità dei 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 l'ottimizzazione dei costi, consulta le best practice per i cluster GKE ad alta disponibilità.
Usa Cloud Logging e Cloud Monitoring e abilita il logging dei criteri di rete
Sebbene ogni organizzazione abbia requisiti diversi in termini di visibilità e controllo, consigliamo di abilitare il logging dei criteri di rete. Questa funzionalità è disponibile solo con GKE Dataplane V2. Il logging dei criteri di rete offre visibilità sull'applicazione dei criteri e sui modelli di traffico dei pod. Tieni presente che sono previsti costi per la registrazione ai criteri della rete.
Per i cluster GKE che utilizzano la versione 1.14 o successive, Logging e Monitoring sono entrambi abilitati per impostazione predefinita. Monitoring fornisce una dashboard per i cluster GKE. Logging abilita inoltre 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 il logging sono abilitati automaticamente e non configurabili.
Tieni presente che sono previsti costi per l'osservabilità di Google Cloud.