Best practice per il networking GKE

Questa pagina illustra le best practice per la configurazione delle opzioni di networking per di Google Kubernetes Engine (GKE). È destinata a essere un'architettura guida alla pianificazione per cloud architect e network engineer con cluster di configurazione consigliati applicabili alla maggior parte dei cluster GKE cluster. Prima di creare i cluster GKE, ti consigliamo di esaminare tutte le sezioni di questa pagina per comprendere le opzioni di rete supportate da GKE e le relative implicazioni.

Le opzioni di rete 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 internamente i carichi di lavoro al tuo Virtual Private Cloud (VPC) rete, altri carichi di lavoro nel cluster, 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 seguente sezione fornisce alcuni suggerimenti specifici per GKE per la progettazione di reti VPC.

Best practice:

Utilizza i cluster nativi di VPC.
Utilizza le reti VPC condivise.

Usa 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 GKE privati e per la creazione di cluster su VPC condivise. Offrono inoltre molti altri vantaggi. Per i cluster creati in modalità Autopilot, la modalità nativa VPC è sempre attiva e non può essere disattivata.

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

La vantaggi per l'utilizzo I cluster nativi di VPC vanno di pari passo con l'IP alias assistenza. Ad esempio: i gruppi di endpoint di rete (NEG) possono essere utilizzati solo con indirizzi IP secondari, quindi sono supportati di cluster VPC nativi.

Usa 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 organizzazione della struttura funzioni bene con la rete VPC condiviso di Google Cloud dell'architettura. 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 utilizzata spesso è 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 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'istruzione e l'indirizzo IP di ogni pod.

Per scoprire di più, consulta il modello di networking GKE.

In GKE, tutti questi indirizzi IP sono instradabili in tutta 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 l'IP la gestione degli indirizzi con GKE.

Best practice:

Pianifica l'allocazione degli indirizzi IP richiesta.
Utilizza uno spazio non RFC 1918, se necessario.
Utilizza la modalità subnet personalizzata.
Pianifica la densità dei pod per nodo.
Evita sovrapposizioni con indirizzi IP utilizzati in altri ambienti.
Crea una subnet del bilanciatore del carico.
Prenota uno 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 degli indirizzi IP richiesta

I cluster privati sono consigliati e vengono ulteriormente discussi nella sezione dedicata. Nel contesto dei cluster privati, solo I cluster nativi di VPC sono supportati e richiedono il seguente indirizzo IP intervalli di indirizzi:

  • Intervallo di indirizzi IP del piano di controllo: utilizza una subnet /28 all'interno dell'indirizzo IP di intervalli privati inclusi nel modulo 1918. Devi Assicurati che questa subnet non si sovrapponga ad altri routing tra domini 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 maggiori informazioni, vedi Intervalli di indirizzi IP per VPC nativo cluster
  • Intervallo di indirizzi IP del servizio: l'intervallo di indirizzi IP allocati per tutti servizi nel tuo cluster. GKE esegue il provisioning di questo intervallo come alias della subnet.

Per i cluster privati, devi definire una subnet di nodi, un intervallo di indirizzi IP del pod un intervallo di indirizzi IP di servizio.

Per utilizzare lo spazio di indirizzi IP in modo più efficiente, consulta Riduci 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 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 alcune route allo stesso CIDR del tuo progetto, potresti riscontrare che le applicazioni presentino problemi di prestazioni.

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 il numero massimo di nodi che aspettavo nel cluster e gli indirizzi IP del bilanciatore del carico interno nel cluster utilizzando la subnet.

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

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

Considera le seguenti limitazioni:

Utilizzare più indirizzi IP RFC 1918 privati

Per alcuni ambienti, lo spazio RFC 1918 in grandi blocchi CIDR contigui potrebbe sono già allocati in un'organizzazione. Puoi utilizzare contenuti non RFC 1918 spazio per CIDR aggiuntivi per i cluster GKE, se non si sovrappongono 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 l'IP pubblico utilizzato privatamente indirizzi IP, da usare con cautela e valuta la possibilità di controllare gli annunci di route negli ambienti a internet.

Non devi utilizzare la traduzione Network Address Translation origine (SNAT) in un cluster con traffico da pod a pod e tra pod a servizio. 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, è necessario disabilitare esplicitamente SNAT oppure configura il masquerade per escludere gli indirizzi IP dei pod del cluster e l'indirizzo IP secondario per i servizi di 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 utilizzando un VPC condiviso, un amministratore dell'organizzazione o una rete amministratore può selezionare questa modalità.

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

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 per supportare fino a 256 pod per nodo, con un intervallo /23 riservato a ogni nodo. In base alle dimensioni dai nodi e dal profilo dell'applicazione dei tuoi pod, potresti eseguire 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 predefiniti per nodo, puoi aumentare il numero massimo di pod per nodo fino a 256, di cui /23 riservati per ogni nodo. Con questo di configurazione ad alta densità di pod, consigliamo di utilizzare istanze con 16 più core della CPU per garantire la scalabilità e le prestazioni del tuo cluster.

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

Evita sovrapposizioni con indirizzi IP utilizzati in altri ambienti

Puoi connettere la tua rete VPC a un ambiente on-premise oppure con altri provider di servizi cloud 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. I nostri suggerimenti facendo in modo che gli indirizzi IP non si sovrappongano a quelli utilizzati nella 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 previsto di nodi.

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.

Prenota spazio sufficiente di indirizzi IP per il gestore della scalabilità automatica dei 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 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 il proprio indirizzo IP e il proprio insieme di indirizzi IP di pod allocabili 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.

Condividi gli indirizzi IP tra i cluster

Potresti dover condividere gli indirizzi IP tra i cluster se disponi di un che gestisce l'infrastruttura per i cluster. Condividere gli indirizzi IP nei cluster GKE, consulta Condivisione di intervalli di indirizzi IP in GKE cluster. 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 esaurisci gli indirizzi IP, puoi creare intervalli di indirizzi IP dei pod aggiuntivi usando multi-pod discontinui CIDR.

Condividi gli indirizzi IP per i servizi LoadBalancer interni

Puoi condividere un singolo indirizzo IP con un massimo di 50 backend utilizzando porte diverse. Questo consente di ridurre il numero di indirizzi IP necessari per le Servizi LoadBalancer.

Per ulteriori informazioni, consulta Indirizzo IP condiviso.

Opzioni di sicurezza di rete

In questa sezione vengono descritti 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.

Best practice:

Utilizza GKE Dataplane V2.
Scegli un tipo di cluster privato.
Riduci al minimo l'esposizione del 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 dalle 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.

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 della CLI Google Cloud 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. Consigliamo di creare cluster con GKE Dataplane V2 per sfruttare al meglio le funzionalità integrate come logging dei criteri di rete.

Scegli un tipo di cluster 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 offrono un maggiore isolamento poiché hanno solo indirizzi IP interni sui nodi e endpoint privati o pubblici per i nodi del control plane (che possono essere ulteriormente isolati e sono discussi nella sezione Minimizzare l'esposizione del control plane del cluster). Nei cluster privati, puoi comunque accedere alle API di Google con 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 utilizzando il bilanciamento del carico e Cloud NAT, descritti nella sezione Connettività del cluster di questo documento. Il seguente diagramma mostra questo tipo di configurazione:

Diagramma 1: comunicazione nel cluster privato

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 con internet è disponibile solo utilizzando Cloud NAT.

Per ulteriori informazioni, 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 endpoint pubblico o privato. Puoi decidere quale endpoint utilizzare quando crei il cluster. Puoi controllare l'accesso con reti, in cui sia per impostazione predefinita, gli endpoint pubblici e privati consentono tutte le comunicazioni 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 determinare a quali indirizzi IP possono accedere le subnet dai nodi del piano di controllo 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 una route personalizzata pubblicità in modo che l'endpoint privato del piano di controllo del cluster sia raggiungibile in un ambiente on-premise. Puoi impostare l'API GKE privata a livello globale mediante l'uso --enable-master-global-access quando crei un cluster.

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

Diagramma 2: connettività del piano di controllo tramite reti autorizzate

Questo diagramma mostra che gli utenti attendibili sono in grado di comunicare con dal piano di controllo GKE tramite l'endpoint pubblico in quanto reti autorizzate, mentre l'accesso da parte di soggetti non attendibili è bloccato. Le comunicazioni da e verso il cluster GKE avvengono 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 dei proxy per l'accesso al piano di controllo dalle reti in peering

L'accesso al control plane per i cluster GKE privati avviene tramite il peering di rete VPC. Il peering di rete VPC è non transitivo, quindi non puoi accedere al piano di controllo del cluster un'altra rete 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 worker 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 il firewall richiesto predefinite per impostazione predefinita, ma possono verranno sovrascritti. Per alcuni implementazioni potrebbe essere necessario che il piano di controllo raggiunga il cluster sul servizio. Puoi utilizzare i firewall VPC per configurare in entrata che rende accessibile il servizio.

I criteri di rete di GKE vengono configurati tramite API Network Policy 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 dei criteri di rete, puoi seguire il progetto per la limitazione del traffico Anthos implementazione .

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 usano bilanciatori del carico delle applicazioni esterni da attacchi DDoS e altri attacchi basati sul web bloccando tale traffico a livello perimetrale 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 eseguire il deployment di servizi accessibili solo agli utenti all'interno del ma senza la necessità di far parte della rete aziendale, puoi utilizzare Identity-Aware Proxy per creare un'istanza livello 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 i criteri dell'organizzazione vincoli, puoi impostare dei criteri per migliorare ulteriormente il tuo livello di sicurezza. 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à dei cluster

Questa sezione illustra le opzioni scalabili per la connettività DNS e in uscita dal tuo a internet e ai servizi Google.

Best practice:

Utilizza Cloud DNS per GKE.
Abilita NodeLocal DNSCache.
Utilizzare Cloud NAT per l'accesso a internet da cluster privati.
Utilizza l'accesso privato Google per accedere ai servizi Google.

Utilizza Cloud DNS per GKE

Puoi utilizzare Cloud DNS per GKE per fornire pod e servizi Risoluzione DNS del servizio con DNS gestito senza un provider DNS ospitato su 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 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 non richiede modifiche alla configurazione del pod. Le ricerche DNS nel servizio di pod locale non creano connessioni aperte che devono essere monitorate sul nodo, per consentire su larga scala. 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 scalabilità dei cluster migliorata. Per i cluster Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita e non può essere sostituito.

La seguente opzione della CLI Google Cloud 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.

Usa Cloud NAT per l'accesso a internet da cluster privati

Per impostazione predefinita, i cluster privati non hanno accesso a internet. Per consentire i pod, per raggiungere internet, abilita Cloud NAT per ogni regione. Presso abilitare Cloud NAT per gli intervalli primari e secondari nella subnet GKE. Assicurati di assegnare un numero sufficiente di indirizzi IP per Cloud NAT e porte per VM.

Segui le seguenti best practice per la configurazione del gateway Cloud NAT durante l'utilizzo Cloud NAT per cluster privati:

  • Quando crei il gateway Cloud NAT, abilitalo solo per la 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 destinazione A 3 tuple, riduci il timeout TIME_WAIT di TCP rispetto al valore predefinito di 120s a 5s. 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 la configurazione del gateway. Per ridurre i problemi di stato di allocazione persi, potrebbe essere necessario aumentare il numero massimo di porte per VM.

Dovresti evitare il doppio della SNAT per il traffico dei pod (SNAT prima nel 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 Limita il traffico esterno dopo l'abilitazione di Cloud NAT. Cloud NAT non è necessaria 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 con cui comunicare al pubblico inclusi 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 in cluster privati, ad eccezione dei cluster VPC condiviso.

Pubblicazione di applicazioni

Quando si creano applicazioni raggiungibili sia dall'esterno che dall'interno della tua organizzazione, assicurati di usare le opzioni e il tipo di bilanciatore del carico corretti. Questa sezione fornisce alcuni consigli 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 la tua applicazione.
Crea controlli di integrità basati su BackendConfig.
Utilizza il criterio di traffico locale per preservare gli indirizzi IP originali.
Utilizza Private Service Connect.

Utilizzare il bilanciamento del carico nativo del container

Utilizza il bilanciamento del carico nativo del container durante l'esposizione utilizzando HTTP(S) esternamente. Il bilanciamento del carico nativo del container consente meno hop di rete, latenza inferiore e distribuzione del traffico più esatta. Inoltre, aumenta la visibilità nel tempo di risposta e ti consente di utilizzare le 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. Il riquadro Networking di Servizi panoramica spiega questi e può aiutarti a scegliere la risorsa migliore per esporre ogni parte un'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 CRD BackendConfig, i controlli di integrità vengono dedotti dai parametri del probe di idoneità usano parametri predefiniti.

Utilizza il criterio del traffico locale per conservare gli indirizzi IP originali

Quando utilizzi un bilanciatore del carico di rete passthrough interno con GKE, imposta il externalTrafficPolicy su Local per conservare l'indirizzo IP di origine delle richieste. Usa questa 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 usa questa funzionalità solo quando necessario. Per i servizi HTTP(S), è possibile utilizzare per controllare i controller Ingress e ottenere l'indirizzo IP originale leggendo il X-Forwarded-For nell'intestazione 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 sono per i clienti in esecuzione in progetti diversi VPC.

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 regionali e distribuisci i tuoi carichi di lavoro per garantire l'alta disponibilità.
Utilizza Cloud Logging, Cloud Monitoring e abilita il logging dei criteri di rete.

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, segui le best practice operative riportate in questa sezione. Inoltre, include consigli per la distribuzione dei carichi di lavoro, nonché per il monitoraggio e log in GKE.

Utilizza le autorizzazioni IAM per 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 di il progetto host per il VPC condiviso.

Il ruolo personalizzato che crei deve avere le seguenti autorizzazioni:

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

Inoltre, le regole firewall create da GKE hanno sempre priorità predefinita di 1000, in modo da poter impedire il flusso di traffico specifico e la creazione di regole firewall a una priorità più elevata.

Se vuoi limitare la creazione di determinati tipi di bilanciatore del carico, utilizza criteri dell'organizzazione per limitare la creazione dei bilanciatori del carico.

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

Cluster a livello di regione possono aumentare la disponibilità delle applicazioni in un cluster, e nodi sono distribuiti in più zone.

Tuttavia, per avere la migliore esperienza utente possibile in caso di errore di una zona, utilizza il cluster gestore della scalabilità automatica per assicurarti in modo che il cluster possa gestire il carico richiesto in qualsiasi momento.

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 in termini di visibilità e controllo, ti consigliamo di abilitare il criterio di rete il logging. 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. Logging consente inoltre Annotazioni GKE per Flusso VPC Log. 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 classe di archiviazione GKE dashboard 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 Observability di Google Cloud.

Riepilogo della lista di controllo

Area Esercitati
Design della VPC
Strategie di gestione degli indirizzi IP
Opzioni di sicurezza di rete
Scalabilità
Pubblicazione delle applicazioni
Operazioni e amministrazione

Passaggi successivi