Best practice per il networking GKE

Questo documento illustra le best practice per configurare le 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 tuoi cluster GKE, ti consigliamo di rivedi tutte le sezioni di questo documento per comprendere il networking le opzioni supportate da GKE e le relative implicazioni.

Le opzioni di networking che scegli influenzano l'architettura del tuo cluster GKE. Alcune di queste opzioni non possono essere modificate una volta configurato senza ricreare il cluster.

Questo documento non è pensato per introdurre i concetti di networking di Kubernetes o terminologia e presuppone che tu abbia già un certo livello di e la conoscenza del networking di Kubernetes. Per ulteriori informazioni, consulta Rete GKE Panoramica.

Durante la revisione di questo documento, considera i seguenti aspetti:

  • 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 tuoi carichi di lavoro.
  • I tipi di servizi Google che vuoi utilizzare.

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

Progettazione del VPC

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

La seguente sezione fornisce alcuni suggerimenti specifici per GKE per la progettazione di reti VPC.

Best practice:

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

Usa cluster nativi di VPC

Ti consigliamo di usare VPC-native cluster. Nativo di VPC i cluster utilizzano intervalli di indirizzi IP alias su GKE nodi e sono necessari per i cluster GKE privati e per la creazione in cluster su VPC condivisi e hanno molti altri vantaggi. Per i cluster creati nel 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 consumare route di Google Cloud e quindi sono meno suscettibili raggiungendo 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 indirizzo IP attento pianificazione. Più alta le organizzazioni tendono ad avere una struttura di gestione centralizzata con una di amministrazione che può allocare uno spazio di indirizzi IP per i cluster amministratore di piattaforma per il funzionamento dei 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 può creare subnet e condividerle con i VPC. Tu possono creare cluster GKE in un servizio progetto e utilizza subnet condivise dal VPC condiviso sull'host progetto. L'IP indirizzo rimane nel progetto host, mentre gli altri componenti del cluster dal 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. Me consigliamo di utilizzare le reti VPC condiviso per creare le subnet per cluster GKE ed evitare conflitti di indirizzi IP su dell'organizzazione. Potresti anche voler utilizzare i VPC condivisi per la governance funzioni operative. Ad esempio, un team di rete che lavora solo sui componenti di rete e sull'affidabilità e un altro team che lavora con 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 saperne di più, consulta Modello di networking di GKE.

In GKE, tutti questi indirizzi IP sono instradabili in tutta rete VPC. Pertanto, la pianificazione dell'indirizzo IP è necessaria gli indirizzi non possono sovrapporsi allo spazio di indirizzi IP interni utilizzato on-premise e 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 nodo: la subnet con l'intervallo di indirizzi IP principali che vuoi allocare per tutti i nodi nel tuo cluster. Servizi di tipo Anche i LoadBalancer che utilizzano l'annotazione cloud.google.com/load-balancer-type: "Internal" usano questa subnet per impostazione predefinita. Puoi anche utilizzare una subnet dedicata per il carico interno bilanciatori del carico.
  • Intervallo di indirizzi IP dei pod: l'intervallo IP allocato per tutti i pod nel tuo in un cluster Kubernetes. 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 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 Piano di controllo gestito da GKE che risiede in un tenant gestito da Google progetto in peering con il tuo VPC. Questo intervallo di indirizzi IP non deve si sovrappongono a qualsiasi indirizzo IP nel gruppo di peering VPC perché GKE importa questa route nel tuo 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 e deve esistere prima della sua creazione. 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 lo gestore della scalabilità automatica dei cluster limita il numero massimo di nodi.

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

Scegli intervalli di indirizzi IP sufficientemente ampi in modo da poter ospitare tutti i nodi, e servizi per la cluster.

Considera le seguenti limitazioni:

Utilizza più di 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. Ti consigliamo di utilizzare la parte 100.64.0.0/10 di il documento RFC di indirizzi IP perché Class Lo spazio di indirizzi E può presentare problemi di interoperabilità con l'hardware on-premise. Puoi usare queste risorse IP pubblici (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 funzionalità Network Address Translation di origine (SNAT) in un cluster con traffico da pod a pod e da pod a servizio. Questo spezza Networking Kubernetes modello.

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

Se utilizzi un indirizzo IP non RFC 1918 per il tuo Cluster GKE, per i cluster Standard, è necessario disabilitare esplicitamente SEGNAPOSTO 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 sono necessari passaggi aggiuntivi.

Usa la modalità subnet personalizzata

Quando configuri la rete, selezioni anche la modalità della subnet: auto (predefinita) o custom (consigliato). La modalità auto lascia l'allocazione delle subnet fino a Google ed è una buona opzione per iniziare senza pianificare l'indirizzo IP. Tuttavia, ti consigliamo di selezionare la modalità custom perché questa modalità ti consente di scegliere IP che non si sovrappongano 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 lo spazio di indirizzi dei pod nella subnet e consente un massimo di 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 regolare il numero massimo di pod per nodo per conservare lo spazio di indirizzi IP nella subnet 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 in Autopilot cluster.

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 possono condividere le route, rendendo la gestione degli indirizzi IP on-premise è importante 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 un bilanciatore del carico separato subnet per esporre con bilanciamento del carico TCP/UDP interno. Se viene usato un bilanciatore del carico non viene utilizzata, questi servizi vengono esposti utilizzando un indirizzo IP di altri nodi, il che può comportare l'utilizzo di tutto lo spazio allocato in quella subnet prima del previsto e può impedirti di scalare GKE con il numero previsto di nodi.

Se usi una subnet del bilanciatore del carico separata, puoi anche filtrare il traffico e dai nodi GKE separatamente ai servizi esposti il bilanciamento del carico TCP/UDP interno, che consente di impostare una sicurezza più restrittiva confini.

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

Puoi utilizzare il cluster gestore della scalabilità automatica aggiungere e rimuovere nodi nel cluster in modo da poter controllare i costi e migliorare all'utilizzo delle risorse. Tuttavia, quando utilizzi il gestore della scalabilità automatica dei cluster, assicurati che la pianificazione degli indirizzi IP per la dimensione massima di tutti i pool di nodi. Ciascuna nuovo nodo richiede il proprio indirizzo IP del nodo e il proprio set allocabile di Indirizzi IP dei pod in base ai pod configurati per nodo. Il numero di pod per che il 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 pool di nodi. Dovresti considerare i tipi di carichi di lavoro e assegnarli a carichi pool di nodi per un'allocazione ottimale degli indirizzi IP.

Valuta la possibilità di utilizzare node il provisioning automatico, il gestore della scalabilità automatica dei cluster, in particolare se utilizzi cluster. Per ulteriori informazioni, consulta Limitazione dei nodi più intervalli.

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. Tu possono ridurre l'esaurimento degli IP creando tre intervalli per pod, servizi e nodi, per poi riutilizzarle o condividerle, in particolare in un modello VPC condiviso. Questo può inoltre semplificare la gestione degli indirizzi IP da parte degli amministratori di rete evitando di creare subnet specifiche per ogni cluster.

Considera quanto segue:

  • Come best practice, usa subnet e intervalli di indirizzi IP separati per tutti cluster.
  • Puoi condividere l'intervallo di indirizzi IP del pod secondario, ma questa operazione è sconsigliata perché un cluster potrebbe utilizzare tutti gli indirizzi IP.
  • Puoi condividere intervalli di indirizzi IP del servizio secondari, ma questa funzionalità non lavorare con Cloud DNS con l'ambito VPC 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, vedi Condivisi IP.

Opzioni di sicurezza di rete

In questa sezione sono descritti alcuni suggerimenti 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.

Usa GKE Dataplane V2

GKE Dataplane V2 si basa su eBPF e fornisce una rete integrata un'esperienza di sicurezza e visibilità. Quando crei un cluster GKE Dataplane V2 non è necessario abilitare esplicitamente i criteri di rete GKE Dataplane V2 gestisce il routing dei servizi, l'applicazione dei criteri di rete e log. Abilita il nuovo piano dati con Google Cloud CLI Opzione --enable-dataplane-v2 durante la creazione di un cluster. Dopo i criteri di rete è configurato un oggetto CRD NetworkLogging predefinito configurato 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 sia privati che pubblici sui nodi e solo un dell'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 privato o pubblico per i nodi del piano di controllo (che possono essere ulteriormente isolati ed è di cui abbiamo parlato in Ridurre a icona il piano di controllo del cluster esposizione). Nei cluster privati, possono ancora accedere alle API di Google 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 utilizzando il bilanciamento del carico e Cloud NAT, trattati in connettività 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. Client on-premise possa connettersi al cluster con il client kubectl. L'accesso ai servizi Google è forniti mediante l'accesso privato Google e la comunicazione a internet disponibile solo mediante Cloud NAT.

Per ulteriori informazioni, consulta requisiti, restrizioni e 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 un pubblico o privato. Puoi decidere quale endpoint usare per per creare 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 abilitare un endpoint privato quando per creare un cluster, utilizza --enable-private-endpoint flag.

Autorizza l'accesso al piano di controllo

Le reti autorizzate possono aiutarti a determinare a quali indirizzi IP possono accedere le subnet dai nodi del piano di controllo GKE. Dopo aver abilitato queste reti, può limitare l'accesso a specifici intervalli di indirizzi IP di origine. Se l'endpoint pubblico è disabilitato, questi intervalli di indirizzi IP di origine devono essere privati. Se un utente è abilitato, 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à al piano di controllo

Alcuni pod di sistema su ogni nodo worker dovranno raggiungere servizi come Server API Kubernetes (kube-apiserver), API di Google o server dei metadati. kube-apiserver deve anche comunicare con alcuni pod di sistema, ad esempio event-exporter in particolare. Questa comunicazione è consentita per impostazione predefinita. Se eseguire il deployment delle regole firewall VPC all'interno dei progetti (maggiori dettagli in nella sezione Limita il traffico del cluster), assicurati che questi pod possono continuare a comunicare con kube-apiserver su quelle di livello inferiore.

Esegui il deployment dei proxy per l'accesso al piano di controllo dalle reti in peering

L'accesso al piano di controllo per i cluster GKE privati avviene tramite 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 in peering o da on-premise, utilizzando un hub e spoke dell'architettura, per 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 regole firewall VPC, criteri firewall gerarchici e i criteri di rete di Kubernetes. le regole firewall VPC I criteri firewall gerarchici si applicano a livello di macchina virtuale (VM), nodi worker su cui si trovano i pod del cluster GKE. I criteri di rete di Kubernetes si applicano a livello di pod per applicare il traffico tra pod e pod percorsi di addestramento.

Se implementi firewall VPC, puoi interrompere l'impostazione predefinita la comunicazione richiesta dal piano di controllo, ad esempio la comunicazione kubelet il piano di controllo. GKE crea il firewall richiesto predefinite per impostazione predefinita, ma possono verranno sovrascritti. Alcuni deployment potrebbero richiedere il piano di controllo per raggiungere 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 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 .

Abilita i criteri di sicurezza di Google Cloud Armor per il traffico in entrata

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. Nel GKE, abilita i criteri di sicurezza di Google Cloud Armor per le applicazioni utilizzando Ingress per bilanciatori del carico delle applicazioni esterni e l'aggiunta di un criteri di sicurezza 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 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 abilitare Identity-Aware Proxy per GKE, segui i passaggi di configurazione per aggiungere Identity-Aware Proxy come parte di BackendConfig per il servizio Ingress. Identity-Aware Proxy può essere combinato con Google Cloud Armor.

Usa 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 usare vincoli per limitare la creazione del bilanciatore del carico a determinate come il carico interno, di fatturazione.

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.
Abilitare NodeLocal DNSCache.
Utilizza Cloud NAT per l'accesso a internet dai 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 elimina l'overhead associato alla gestione di un server DNS ospitato in un cluster e non richiede scalabilità, monitoraggio o gestione delle istanze DNS, un servizio Google in hosting.

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 dei 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 Autopilot, NodeLocal DNSCache è abilitato per impostazione predefinita e non può eseguire l'override.

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

Se hai il controllo sul nome che le applicazioni vogliono risolvere, esistono modi per migliorare la scalabilità 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 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 allocano un numero diverso di porte per VM in base all'utilizzo. Avvia con un minimo di 64 e un massimo di 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.

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

  • Controlla i log del gateway Cloud NAT dopo la configurazione del gateway. A diminuisci i problemi legati alla diminuzione dello stato di allocazione, potrebbe essere necessario aumentare e 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 richiesto SNAT per nascondere gli indirizzi IP dei pod nelle reti on-premise connesse Cloud VPN o Cloud Interconnect disable-default-snat e l'offload del monitoraggio SNAT in Cloud NAT per la scalabilità. Questa soluzione funziona per tutti gli intervalli IP di subnet primari e secondari. 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.

Utilizza 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 Le risorse Google Cloud raggiungono i servizi Google.

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

Gestione delle 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 suggerimenti sull'esposizione e la scalabilità delle 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 del traffico locale per conservare 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 utilizzando HTTP(S) esternamente. Il bilanciamento del carico nativo del container consente meno hop di rete, minore latenza e una distribuzione più esatta del traffico. Inoltre, aumenta la visibilità del tempo di round trip e 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 vostri clienti (interni, esterni o anche cluster-internal), la regionalità dell'applicazione e i protocolli che utilizzi, ci sono diverse risorse GKE che puoi scegliere 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.

Crea controlli di integrità basati su BackendConfig

Se utilizzi una risorsa Ingress per esporre i servizi, usa una configurazione del controllo di integrità in un BackendConfig CRD da utilizzare la funzionalità di controllo di integrità del bilanciatore del carico delle applicazioni esterno. Puoi controllare lo stato di salute seleziona l'endpoint appropriato e imposta 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.

Usa Private Service Connect

Puoi utilizzare la modalità Private Service Connect a condividono i servizi del bilanciatore del carico di rete passthrough interno tra 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 l'indirizzo IP il consumo eccessivo fornendo la connettività tra i VPC che si sovrappongono.

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 seguenti sezioni contengono best practice operative che ti aiutano a garantire di autorizzazioni 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 si utilizzano le reti VPC condivise, le regole firewall per i bilanciatori del carico vengono creati automaticamente nel progetto host.

Per evitare di dover creare manualmente le regole firewall, assegna un privilegio minimo ruolo personalizzato 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 con 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 tuoi carichi di lavoro per garantire una disponibilità elevata

Cluster a livello di regione può aumentare la disponibilità delle applicazioni in un cluster perché 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 Anti-affinità dei pod assicura che i pod di un determinato servizio siano pianificati in più zone.

Per maggiori informazioni informazioni su come configurare queste impostazioni per l'alta disponibilità e i costi ottimizzabili, consulta le best practice per i modelli GKE ad alta disponibilità cluster.

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, ti consigliamo di abilitare il criterio di rete il logging. Questa funzionalità è disponibile solo con GKE Dataplane V2. Criterio di rete il logging offre visibilità sull'applicazione dei criteri e sui pattern di traffico dei pod. Essere consapevoli che sono previsti costi per i criteri di rete il logging.

Per i cluster GKE che utilizzano la versione 1.14 o successive, Logging e Il monitoraggio sono entrambi abilitati predefinito. Monitoring offre una dashboard cluster GKE. Logging consente inoltre Annotazioni GKE per Flusso VPC Log. Per impostazione predefinita, Logging raccoglie log per tutti i carichi di lavoro di cui è stato eseguito il deployment nel cluster, ma quelli solo di sistema opzione esiste. Utilizza la classe di archiviazione GKE dashboard per osservare e impostare gli avvisi. Per i cluster creati La modalità Autopilot, il monitoraggio e il logging sono abilitati automaticamente non configurabile.

Tieni presente che sono previsti costi per Observability di Google Cloud.

Riepilogo elenco di controllo

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

Passaggi successivi