Pianifica gli indirizzi IP durante la migrazione a GKE

Questo documento descrive come gestire l'utilizzo degli indirizzi IP su Google Kubernetes Engine (GKE) e come utilizzare modelli di rete alternativi in GKE, se necessario. Questo documento illustra i seguenti concetti:

  • Come ridurre l'utilizzo degli indirizzi IP dei pod in GKE in modo che GKE soddisfi le esigenze di indirizzi IP della maggior parte delle organizzazioni.
  • In che modo è possibile implementare modelli di rete alternativi su GKE quando l'architettura del cluster non soddisfa i requisiti della tua organizzazione.

Questo documento è rivolto ad architetti cloud, ingegneri delle operazioni e ingegneri di rete che pianificano di eseguire la migrazione dei cluster Kubernetes da altri ambienti a GKE. Segui le indicazioni riportate in questo documento se la tua organizzazione ha difficoltà ad assegnare indirizzi IP interni sufficienti per l'utilizzo previsto di GKE.

Questo documento assume che tu abbia familiarità con Kubernetes e il suo modello di rete. Inoltre, devi conoscere i concetti di networking come l'indirizzamento IP, la Network Address Translation (NAT), i firewall e i proxy.

Questo documento non tratta le strategie di gestione per l'intervallo di indirizzi utilizzato per gli indirizzi IP del servizio. Il numero di indirizzi richiesti per i servizi è molto inferiore a quello per i pod e le opzioni per ridurre questo numero sono limitate. Su GKE, l'intervallo di indirizzi IP dei servizi è fisso per tutta la durata del cluster. Pertanto, l'intervallo di indirizzi IP dei servizi deve essere dimensionato in base al numero più elevato di servizi previsto. Poiché gli indirizzi IP dei servizi non sono raggiungibili al di fuori del cluster, puoi riutilizzarli in altre reti.

Questo documento fa riferimento anche a diversi modelli di rete Kubernetes: completamente integrato, in modalità isola e isolato. Questi modelli differiscono per il modo in cui gli indirizzi IP dei pod possono essere raggiunti in tutta la rete. Queste differenze influiscono sulle strategie di gestione degli indirizzi IP che possono essere utilizzate. Per informazioni più dettagliate su questi modelli e sul modello di rete GKE, consulta Confronto dei modelli di rete utilizzati da GKE e da altre implementazioni di Kubernetes.

Ridurre l'utilizzo degli indirizzi IP interni in GKE

GKE utilizza un modello di rete completamente integrato in cui i cluster vengono di cui vengono eseguiti il deployment in una rete VPC che può contenere anche altre applicazioni. Il modello GKE offre molti vantaggi. Tuttavia, questo tipo di modello non consente di riutilizzare gli indirizzi IP dei pod. Questa mancanza di riutilizzo richiede l'utilizzo di indirizzi IP dei pod che siano unici nell'intera rete VPC. Pertanto, devi valutare attentamente quanti indirizzi IP univoci ti servono.

Il numero di indirizzi univoci di cui hai bisogno influisce sulla necessità di ridurre l'utilizzo degli indirizzi IP, come segue:

  • Se disponi di uno spazio indirizzi sufficiente per le tue esigenze di indirizzi IP, non necessariamente devi adottare misure per ridurre l'utilizzo degli indirizzi IP. Tuttavia, sapere come ridurre l'utilizzo degli indirizzi IP è utile per identificare il numero minimo di indirizzi IP da utilizzare.
  • Se non disponi di uno spazio indirizzi sufficiente, devi ridurre l'utilizzo degli indirizzi IP per creare cluster GKE che si adattino ai vincoli del tuo spazio indirizzi.

Per aiutarti a ridurre l'utilizzo degli indirizzi IP in GKE, valuta le seguenti opzioni:

  • Modifica l'impostazione Pod per nodo. Per impostazione predefinita, i cluster GKE Standard riservano un intervallo di /24 subnet per ogni nodo e consentono fino a 110 pod per nodo. Se prevedi di utilizzare solo 64 pod o meno per nodo, puoi modificare il numero massimo di pod per nodo e quindi ridurre l'utilizzo degli indirizzi IP dei pod della metà o più. I cluster Autopilot consentono 32 pod per nodo e questa impostazione non può essere modificata.
  • Utilizza più intervalli di indirizzi IP del pod. Utilizzando il routing interdominio senza classi (CIDR) multi-pod disgiunto, puoi aggiungere intervalli di indirizzi IP dei pod secondari ai cluster esistenti. Puoi selezionare l'intervallo di indirizzi IP del pod utilizzato da ciascun pool di nodi. La selezione dell'intervallo di indirizzi IP utilizzato da ciascun pool ti consente di essere conservativo durante l'allocazione dello spazio degli indirizzi IP del pod iniziale, pur avendo la possibilità di far crescere il cluster.

  • Utilizzare indirizzi IP non RFC 1918. La rete aziendale potrebbe non avere un numero sufficiente di indirizzi IP RFC 1918 non allocati da utilizzare per gli indirizzi IP del pod. Se non disponi di indirizzi IP RFC 1918 non allocati sufficienti, puoi utilizzare indirizzi non RFC 1918, come quelli nello spazio di indirizzi RFC 6598 (100.64.0.0/10).

    Se utilizzi già lo spazio RFC 6598 in un'altra parte della rete aziendale, puoi utilizzare lo spazio indirizzi Classe E/RFC 5735 (240.0.0.0/4) per gli indirizzi IP dei pod. Tuttavia, il traffico proveniente da questi indirizzi IP viene bloccato sugli host Windows e su alcuni hardware on-premise. Per evitare di bloccare gli indirizzi RFC 5735, valuta la possibilità di eseguire il masquerading del traffico verso queste destinazioni esterne come descritto nella sezione Nascondere gli indirizzi IP dei pod solo dalle reti on-premise. Tuttavia, quando camuffi il traffico verso destinazioni esterne, perdi alcuni dati di telemetria diretti alle applicazioni on-premise.

Se la tua organizzazione dispone di uno spazio di indirizzi IP pubblici di grandi dimensioni, puoi anche utilizzare indirizzi pubblici utilizzati privatamente (PUPI). Quando utilizzi indirizzi PUPI, devi includere gli indirizzi PUPI nell'elenco nonMasqueradeCIDRs per avere connettività all'esterno del cluster senza utilizzare NAT.

Scegliere un modello di rete in GKE

Il documento sul modello di networking di GKE spiega come funzionano i cluster standard in GKE, inclusi gli indirizzi IP dei pod coinvolti. In questo documento, la sezione Ridurre l'utilizzo degli indirizzi IP interni in GKE descrive come ridurre il numero di indirizzi IP interni necessari in questi cluster. È fondamentale conoscere sia il funzionamento del modello di rete GKE sia come ridurre gli indirizzi IP interni per qualsiasi modello di rete utilizzato in GKE.

Tuttavia, conoscere e applicare questi concetti potrebbe non fornirti un'implementazione di rete che soddisfi le tue esigenze. La seguente struttura decisionale può aiutarti a decidere come implementare il modello di rete GKE più adatto alle tue esigenze:

Albero decisionale per le strategie di migrazione degli indirizzi IP in GKE.

L'albero decisionale inizia sempre con la creazione di cluster GKE standard basati su un modello di rete completamente integrato. Il passaggio successivo dell'albero consiste nel ridurre l'utilizzo degli indirizzi IP applicando tutte le opzioni descritte in questo documento.

Se hai ridotto al massimo l'utilizzo degli indirizzi IP e non hai ancora uno spazio indirizzi sufficiente per i tuoi cluster GKE, hai bisogno di un modello di rete alternativo. L'albero decisionale ti aiuta a decidere quale dei seguenti modelli di rete alternativi utilizzare:

Ricorda che questo albero decisionale deve essere utilizzato solo come guida. In base al tuo caso d'uso specifico, potresti comunque preferire un altro modello in base ai vantaggi e agli svantaggi di ciascun modello. Spesso sono possibili più modelli e puoi scegliere l'approccio più adatto alla tua organizzazione.

In alcuni rari casi, i modelli alternativi presentati nell'albero decisionale non soddisfano le tue esigenze. Per questi rari casi, potresti essere in grado di utilizzare il modello descritto in Utilizzare istanze con più NIC per nascondere gli indirizzi del cluster.

Emula modelli di rete alternativi

Per usufruire dei vantaggi del modello di rete completamente integrato, ti consigliamo di mantenere i cluster GKE nella stessa rete logica delle altre risorse cloud. Tuttavia, potresti non essere in grado di seguire questo consiglio. Potresti non avere spazio di indirizzi IP sufficiente o potrebbe essere necessario nascondere gli indirizzi IP dei pod dalla rete più grande della tua organizzazione.

Questa sezione fornisce opzioni per l'utilizzo del modello di rete completamente integrato descrivendo diversi pattern di architettura che simulano vari modelli di rete alternativi su GKE. Questi schemi di architettura alternativa creano una modalità di funzionamento per GKE simile al modello di rete in modalità isola o al modello di rete in modalità isolata.

Ogni pattern di architettura alternativa include le seguenti informazioni:

Nascondere gli indirizzi IP dei pod solo dalle reti on-premise

Il pattern di architettura in cui nascondi gli indirizzi IP delle reti on-premise utilizza una combinazione dei seguenti obiettivi di routing:

  • I cluster GKE su Google Cloud devono assegnare agli indirizzi IP dei pod percorsi all'interno del deployment Google Cloud .
  • Impedisci che questi indirizzi IP vengano instradati senza NAT alle risorse on-premise o ad altri ambienti cloud tramite Cloud VPN o Cloud Interconnect.

Questo pattern di architettura viene comunemente utilizzato con lo spazio di indirizzi IP di classe E/RFC 5735 perché include molti indirizzi IP. La disponibilità di così tanti indirizzi IP consente di soddisfare la necessità di fornire indirizzi IP univoci a ogni pod. Tuttavia, gli indirizzi IP di classe E/RFC 5735 non possono essere facilmente instradati alle risorse on-premise perché molti fornitori di hardware di rete bloccano questo traffico.

Anziché utilizzare lo spazio di indirizzi IP di classe E/RFC 5735, puoi utilizzare indirizzi IP RFC 1918 o un insieme interno di indirizzi IP non RFC 1918. Se utilizzi uno di questi altri insiemi di indirizzi IP, determina se esiste un'eventuale sovrapposizione tra gli indirizzi IP utilizzati per i pod e quelli utilizzati nelle reti on-premise. In caso di sovrapposizione, assicurati che non esista mai alcuna comunicazione tra i cluster che utilizzano questi indirizzi e le applicazioni on-premise che utilizzano gli stessi indirizzi.

I passaggi riportati di seguito descrivono come configurare questo pattern di architettura:

  1. Crea un intervallo di indirizzi IP secondario per la subnet del pod. Come descritto in precedenza in questa sezione, puoi creare questo intervallo di indirizzi dallo spazio di classe E/RFC 5735, dallo spazio RFC 1918 o da un insieme interno di indirizzi IP non RFC 1918. In genere viene utilizzato lo spazio di classe E/RFC 5735.
  2. Utilizza route pubblici personalizzati e rimuovi l'intervallo di indirizzi IP del pod dagli annunci sui router Cloud. La rimozione di questi indirizzi contribuisce ad assicurare che gli intervalli IP dei pod non vengano annunciati tramite il Border Gateway Protocol (BGP) ai router on-premise.
  3. Crea il cluster GKE utilizzando l'intervallo di indirizzi IP secondario come Classless Inter-Domain Routing (CIDR) per il pod. Puoi utilizzare le strategie descritte in Ridurre l'utilizzo degli indirizzi IP interni in GKE per ridurre l'utilizzo degli indirizzi IP.

  4. Aggiungi i seguenti indirizzi IP all'elenco nonMasqueradeCIDRs nell'agente di scambio di identità:

    • L'intervallo di indirizzi IP utilizzato per i pod.
    • L'intervallo di indirizzi IP utilizzato per i nodi.
    • Altri indirizzi IP utilizzati solo su Google Cloud, ad esempio gli intervalli di indirizzi IP principali utilizzati su Google Cloud.

    Non includere gli intervalli di indirizzi IP interni utilizzati in ambienti on-premise o in altri ambienti cloud. Se hai carichi di lavoro Windows in Google Cloud, mantienili in sottoreti separate e non includere nemmeno questi intervalli.

Quando utilizzi i passaggi precedenti per configurare questo pattern, configuri i cluster in modo che abbiano i seguenti comportamenti:

  • Agisce come un modello di rete completamente integrato in Google Cloud.
  • Agisce come un modello di rete in modalità isola quando interagisce con le reti on-premise.

Per fare in modo che questo pattern alternativo emuli completamente il modello di rete in modalità isola, devi modificare l'elenco nonMasqueradeCIDRs nell'agente di mascheramento in un elenco contenente solo gli intervalli di indirizzi IP del nodo e del pod del cluster. La creazione di un elenco di questo tipo comporta sempre il mascheramento del traffico all'esterno del cluster all'indirizzo IP del nodo, anche all'interno di Google Cloud. Tuttavia, dopo aver apportato questa modifica, non puoi raccogliere i dati di telemetria a livello di pod all'interno della rete VPC.

Il seguente diagramma mostra un'implementazione di questo pattern di architettura:

Diagramma di rete che mostra l'implementazione dell'occultamento dell'indirizzo IP solo dalle reti on-premise.

Il diagramma precedente mostra come nascondere gli indirizzi IP dei pod alle reti esterne. Come mostrato in questo diagramma, i pod all'interno di Google Cloud possono comunicare direttamente tra loro, anche tra cluster. Questa comunicazione tra pod è simile al modello GKE. Tieni presente che il diagramma mostra anche i pod che utilizzano indirizzi nello spazio ClassE/RFC 5735.

Per il traffico inviato all'esterno dei cluster, il diagramma mostra come viene applicato il source NAT (SNAT) al traffico quando esce dal nodo. SNAT viene utilizzato indipendentemente dal fatto che il traffico venga instradato tramite Cloud VPN alle applicazioni on-premise o tramite Cloud NAT alle applicazioni esterne.

Questo pattern di architettura utilizza gli indirizzi IP dei pod per la comunicazione all'interno di Google Cloud. Il traffico viene mascherato solo quando è indirizzato a applicazioni on-premise o ad altri ambienti cloud. Anche se non puoi connetterti ai pod direttamente dalle applicazioni on-premise, puoi connetterti ai servizi esposti tramite il bilanciamento del carico interno.

La disattivazione degli indirizzi IP dei pod dalle reti on-premise presenta i seguenti vantaggi:

  • Puoi comunque sfruttare il modello di rete completamente integrato in Google Cloud, ad esempio utilizzando i firewall e raccogliendo i dati di telemetria in base agli indirizzi IP dei pod. Inoltre, puoi connetterti ai pod direttamente per scopi di debug dall'interno di Google Cloud.
  • Puoi comunque utilizzare mesh di servizi multi-cluster con indirizzi IP dei pod in Google Cloud.

Tuttavia, la disattivazione degli indirizzi IP dei pod per le reti esterne presenta i seguenti svantaggi:

  • Non puoi riutilizzare gli intervalli di indirizzi IP di pod o servizi per diversi cluster in Google Cloud.
  • Potresti dover gestire due diversi insiemi di regole firewall: uno per il traffico tra le reti on-premise e uno per il traffico completamente all'interno di Google Cloud.
  • Non puoi avere una comunicazione diretta da pod a pod nelle reti mesh di servizi multi-cluster che si estendono sia su Google Cloud sia nel tuo ambiente on-premise o di altri fornitori di servizi cloud. Ad esempio, quando utilizzi Istio, tutta la comunicazione deve avvenire tra i gateway Istio.

Nascondere gli indirizzi IP dei pod utilizzando Private Service Connect

Questo pattern di architettura utilizza Private Service Connect per nascondere gli indirizzi IP dei pod. Utilizza questo pattern di architettura se hai le seguenti esigenze:

  • Devi esporre solo un numero limitato di servizi dai tuoi cluster GKE.
  • I tuoi cluster GKE possono funzionare in modo indipendente e non richiedono comunicazioni in uscita con molte applicazioni nella tua rete aziendale.

Private Service Connect fornisce un modo per pubblicare i servizi da utilizzare da altre reti. Puoi esporre i tuoi servizi GKE utilizzando un bilanciatore del carico di rete passthrough interno e i collegamenti di servizio e utilizzarli tramite un endpoint di altre reti VPC.

I passaggi riportati di seguito descrivono come configurare questo pattern di architettura:

  1. In una rete VPC separata, crea un cluster GKE. La rete VPC deve contenere solo quel cluster.
  2. Per ogni servizio GKE nel cluster che deve essere accessibile da altri cluster o applicazioni in un'altra rete VPC, crea un bilanciatore del carico di rete passthrough interno con Private Service Connect.

  3. (Facoltativo) Se il tuo cluster GKE ha bisogno di comunicazioni in uscita con alcune applicazioni nella rete aziendale, esponi queste applicazioni pubblicando i servizi tramite Private Service Connect.

    Il seguente diagramma mostra un'implementazione di questo pattern di architettura:

Diagramma di rete che mostra l'implementazione dell'occultamento dell'indirizzo IP mediante Private Service Connect.

Il diagramma precedente mostra come la comunicazione all'interno e tra i cluster nel modello Private Service Connect sia simile a un modello di rete isolata. Tuttavia, la comunicazione consentita avviene tramite gli endpoint Private Service Connect anziché tramite gli indirizzi IP pubblici. Come mostrato in questo diagramma, ogni cluster ha una propria rete VPC separata. Inoltre, ogni rete VPC può condividere lo stesso indirizzo IP e ogni cluster può condividere lo stesso spazio degli indirizzi IP. Solo i pod all'interno di un cluster possono comunicare tra loro direttamente.

Per la comunicazione dall'esterno del cluster, il diagramma mostra come un'applicazione esterna può raggiungere il cluster tramite un endpoint Private Service Connect. Questo endpoint si connette al collegamento del servizio fornito dal producer di servizi nella rete VPC del cluster. La comunicazione tra i cluster passa anche per un endpoint Private Service Connect e per un aggancio del servizio di un producer di servizi.

L'utilizzo di Private Service Connect per nascondere gli indirizzi IP dei pod presenta i seguenti vantaggi:

  • Non devi pianificare gli indirizzi IP perché lo spazio degli indirizzi IP del cluster GKE è nascosto al resto della rete. Questo approccio espone solo un singolo indirizzo IP per servizio alla rete VPC di destinazione.
  • La protezione del cluster è più semplice perché questo modello definisce chiaramente quali servizi sono esposti e solo questi servizi possono essere raggiunti dal resto della rete VPC.

Tuttavia, l'utilizzo di Private Service Connect per nascondere gli indirizzi IP dei pod presenta i seguenti svantaggi:

  • I pod all'interno del cluster non possono stabilire comunicazioni private al di fuori del cluster. I pod possono comunicare solo con servizi pubblici (se dispongono di connettività a internet) o API di Google (utilizzando l'accesso privato Google). Se i servizi esterni al cluster sono esposti tramite Private Service Connect, anche i pod possono raggiungerli. Tuttavia, non tutti i fornitori di servizi interni creano collegamenti a servizi. Pertanto, l'utilizzo di Private Service Connect funziona solo se il numero di questi servizi è limitato ai fornitori che forniscono allegati.
  • Gli endpoint possono essere raggiunti solo dalla stessa regione in cui si trova il servizio. Inoltre, questi endpoint possono essere raggiunti solo dalla stessa rete VPC collegata, non dalle reti VPC con peering o dalle reti collegate tramite Cloud VPN o Cloud Interconnect.

Nascondere gli indirizzi IP dei pod utilizzando Cloud VPN

Questo pattern di architettura utilizza Cloud VPN per creare una separazione tra i cluster GKE e la rete VPC principale. Quando crei questa separazione, la rete risultante funziona in modo simile al modello di rete in modalità isola. Come il modello in modalità isola, questo pattern offre il vantaggio di riutilizzare gli intervalli di indirizzi IP di pod e servizi tra i cluster. Il riutilizzo è possibile perché la comunicazione con le applicazioni esterne al cluster utilizza SNAT. I nodi utilizzano la SNAT per mappare gli indirizzi IP dei pod al proprio indirizzo IP del nodo prima che il traffico esca dal nodo.

I passaggi riportati di seguito descrivono come configurare questo modello:

  1. In una rete VPC separata, crea un cluster GKE. La rete VPC deve contenere solo quel cluster.

    Per il cluster, utilizza la parte non utilizzata dell'assegnazione dell'indirizzo IP pubblico per definire due intervalli di indirizzi IP: uno per i pod e uno per i servizi. Definisci le dimensioni di questi intervalli di indirizzi IP in base alle esigenze del cluster GKE più grande che prevedi di utilizzare. Riserva ciascuno di questi intervalli per uso esclusivo in GKE. Puoi anche riutilizzare questi intervalli per tutti i cluster GKE della tua organizzazione.

    A volte, non è possibile prenotare un intervallo di indirizzi IP così ampio. La tua organizzazione potrebbe già utilizzare una o entrambe le gamme di indirizzi IP di pod e servizi per altre applicazioni. Se l'intervallo di indirizzi IP è in uso e non può essere prenotato, assicurati che le applicazioni che utilizzano questi indirizzi IP non debbano comunicare con il cluster GKE.

  2. Per il cluster appena creato, configura l'elenco nonMasqueradeCIDRs nell'agente di scambio di identità su un elenco contenente gli intervalli di indirizzi IP dei nodi e dei pod del cluster. Questo elenco fa sì che GKE mascheri sempre il traffico in uscita dal cluster all'indirizzo IP del nodo, anche all'interno diGoogle Cloud.

  3. Utilizza Cloud VPN per connettere la rete VPC contenente il cluster GKE alla rete VPC esistente (principale).

  4. Utilizza route pubblicizzati personalizzati per impedire alla rete VPC del cluster di pubblicizzare gli intervalli di indirizzi IP di pod e servizi indirizzati alla tua rete VPC principale.

  5. Ripeti i passaggi 1-4 per gli altri cluster GKE di cui hai bisogno. Per tutti i cluster, utilizza gli stessi intervalli di indirizzi IP per i pod e i servizi. Tuttavia, utilizza indirizzi IP distinti per ogni nodo.

  6. Se hai connettività alle reti on-premise tramite Cloud VPN o Cloud Interconnect, utilizza le route pubblicizzate personalizzate per pubblicizzare manualmente gli intervalli IP dei nodi.

  7. Se hai altre reti connesse alla tua rete VPC principale tramite il peering di rete VPC, esporta le route personalizzate su questi peering per assicurarti che i nodi del cluster GKE possano raggiungere le reti con peering.

Il seguente diagramma mostra un'implementazione dell'utilizzo di Cloud VPN per nascondere gli indirizzi IP dei pod:

Diagramma di rete che mostra l'implementazione dell'occultamento dell'indirizzo IP mediante Cloud VPN.

Il diagramma precedente mostra come nascondere gli indirizzi IP dei pod utilizzando Cloud VPN, che crea un approccio simile al modello di rete in modalità isola. Come mostrato nel diagramma, ogni cluster GKE viene dotato di una propria rete VPC separata. Ogni rete ha uno spazio di indirizzi IP del nodo distinto, ma utilizza lo stesso spazio di indirizzi IP del pod. I tunnel Cloud VPN connettono queste reti VPC tra loro e alla rete aziendale e lo spazio degli indirizzi IP dei pod non viene pubblicizzato dalle reti VPC che contengono i cluster.

Nel diagramma, tieni presente che solo i pod all'interno di un cluster possono comunicare tra loro direttamente. Il nodo utilizza SNAT per mascherare lo spazio degli indirizzi IP del pod quando comunica al di fuori del cluster con un altro cluster, con la rete aziendale o con una rete on-premise collegata. I pod non possono essere raggiunti direttamente da altri cluster o dalla rete aziendale. Solo i servizi di cluster esposti con un bilanciatore del carico interno possono essere raggiunti tramite le connessioni Cloud VPN.

L'utilizzo di Cloud VPN per nascondere gli indirizzi IP dei pod presenta i seguenti vantaggi:

  • Come descritto nel modello di rete in modalità isola, puoi riutilizzare gli intervalli di indirizzi IP di pod e servizi tra i cluster.
  • I firewall potrebbero richiedere meno configurazione perché gli indirizzi IP dei pod non possono essere raggiunti direttamente dalla rete VPC principale e dalle reti collegate. Di conseguenza, non è necessario configurare regole firewall esplicite per bloccare la comunicazione con i pod.

Tuttavia, l'utilizzo di Cloud VPN per nascondere gli indirizzi IP dei pod presenta i seguenti inconvenienti:

  • Si applicano gli stessi svantaggi descritti nel modello di rete in modalità isola. Ad esempio, non puoi impostare regole firewall a livello di pod. Inoltre, non puoi raccogliere i dati di telemetria a livello di pod nella rete VPC principale o nella rete collegata.
  • Rispetto al modello di rete GKE predefinito, questo schema comporta costi aggiuntivi derivanti da costi associati ai tunnel Cloud VPN e da addebiti per il trasferimento di dati.
  • Cloud VPN ha un limite di larghezza di banda per tunnel VPN. Se raggiungi questo limite di larghezza di banda, puoi configurare più tunnel Cloud VPN e distribuire il traffico utilizzando il protocollo ECMP (Equal-cost multipath). Tuttavia, l'esecuzione di queste azioni aumenta la complessità della configurazione e della manutenzione dell'implementazione di GKE.
  • Mantenere sincronizzati gli annunci di percorso aggiunge complessità alla creazione del cluster. Ogni volta che crei nuovi cluster GKE, devi configurare i tunnel Cloud VPN e creare route pubblicizzati personalizzati su questi tunnel e per le applicazioni on-premise.

Nascondi gli indirizzi IP dei pod utilizzando indirizzi IP pubblici utilizzati internamente e il peering di rete VPC

Se la tua organizzazione possiede indirizzi IP pubblici inutilizzati, puoi utilizzare questo schema di architettura simile a un modello di rete in modalità isola, ma tramite l'utilizzo privato di questo spazio indirizzo IP pubblico. Questa architettura è simile al modello che utilizza Cloud VPN, ma utilizza il peering di rete VPC per creare la separazione tra il cluster GKE e la rete principale.

I passaggi riportati di seguito descrivono come configurare questo pattern di architettura:

  1. In una rete VPC separata, crea un cluster GKE. La rete VPC deve contenere solo quel cluster.

    Per il cluster, utilizza la parte non utilizzata dell'assegnazione dell'indirizzo IP pubblico per definire due intervalli di indirizzi IP: uno per i pod e uno per i servizi. Definisci le dimensioni di questi intervalli di indirizzi IP in base alle esigenze del cluster GKE più grande che prevedi di utilizzare. Riserva ciascuno di questi intervalli per uso esclusivo in GKE. Puoi anche riutilizzare questi intervalli per tutti i cluster GKE della tua organizzazione.

    Anziché utilizzare l'assegnazione dell'indirizzo IP pubblico, è teoricamente possibile utilizzare blocchi di indirizzi IP pubblici più grandi e inutilizzati di proprietà di terze parti. Tuttavia, sconsigliamo vivamente una configurazione di questo tipo perché questi indirizzi IP potrebbero essere venduti o utilizzati pubblicamente in qualsiasi momento. La vendita o l'utilizzo di indirizzi ha causato problemi di sicurezza e connettività durante l'utilizzo di servizi pubblici su internet.

  2. Per il cluster appena creato, configura l'elenco nonMasqueradeCIDRs nell'agente di scambio di identità su un elenco contenente gli intervalli di indirizzi IP dei nodi e dei pod del cluster. Questo elenco determina che GKE mascheri sempre il traffico in uscita dal cluster all'indirizzo IP del nodo, anche all'interno di Google Cloud.

  3. Utilizza il peering di rete VPC per connettere la rete VPC che contiene il cluster GKE alla rete VPC esistente (principale). Poiché non vuoi che gli indirizzi PUPI vengano scambiati in questo modello, imposta il flag --no-export-subnet-routes-with-public-ip durante la configurazione del peering.

  4. Ripeti i passaggi 1-3 per gli altri cluster GKE di cui hai bisogno. Per tutti i cluster, utilizza lo stesso intervallo di indirizzi IP per i pod e i servizi. Tuttavia, utilizza un indirizzo IP distinto per ogni nodo.

  5. Se hai connettività alle reti on-premise tramite Cloud VPN o Cloud Interconnect, utilizza gli annunci di route personalizzati per annunciare manualmente gli intervalli di indirizzi IP dei nodi.

Il seguente diagramma mostra un'implementazione di questo pattern di architettura:

Diagramma di rete che mostra l'implementazione dell'occultamento degli indirizzi IP mediante PUPI e il peering di rete VPC.

Il diagramma precedente mostra come nascondere gli indirizzi IP utilizzando il peering di rete VPC. Come mostrato nel diagramma, ogni cluster GKE ha una propria rete VPC separata. Ogni nodo ha uno spazio di indirizzi IP distinto, ma utilizza lo stesso spazio di indirizzi IP del pod definito dallo spazio di indirizzi PUPI della tua organizzazione. Le reti VPC si connettono tra loro e ad applicazioni non Kubernetes inGoogle Cloud tramite il peering di reti VPC. Lo spazio indirizzi PUPI non viene pubblicizzato tra i peering. Le reti VPC si connettono alla rete aziendale tramite i tunnel Cloud VPN.

Solo i pod all'interno di un cluster possono comunicare tra loro direttamente. Il nodo utilizza SNAT per mascherare lo spazio IP del pod quando comunica al di fuori del cluster con un altro cluster, con la rete aziendale o con una rete on-premise collegata. I pod non possono essere raggiunti direttamente da altri cluster o dalla rete aziendale. Solo i servizi esposti con un bilanciatore del carico interno possono essere raggiunti tramite le connessioni in peering della rete VPC.

Questo pattern di architettura è simile all'approccio Cloud VPN descritto in precedenza, ma presenta i seguenti vantaggi rispetto a questo pattern:

  • A differenza del pattern di architettura Cloud VPN,il peering di rete VPC non comporta costi aggiuntivi per i tunnel Cloud VPN o la larghezza di banda tra gli ambienti.
  • Il peering di rete VPC non ha limitazioni di larghezza di banda ed è completamente integrato nelle reti software-defined di Google. Pertanto, il peering di rete VPC potrebbe fornire una latenza leggermente inferiore rispetto a Cloud VPN perché il peering non richiede i gateway e l'elaborazione necessari per Cloud VPN.

Tuttavia, il modello di peering di rete VPC presenta anche i seguenti svantaggi rispetto al modello Cloud VPN:

  • La tua organizzazione richiede uno spazio di indirizzi IP pubblico inutilizzato e sufficientemente grande per lo spazio di indirizzi IP del pod necessario per il cluster GKE più grande che prevedi di avere.
  • Il peering di rete VPC non è transitivo. Pertanto, i cluster GKE collegati tramite il peering di rete VPC alla rete VPC principale non possono comunicare direttamente tra loro o con le applicazioni nelle reti VPC in peering con la VPC principale. Per attivare questa comunicazione, devi collegare direttamente queste reti tramite il peering di rete VPC oppure utilizzare una VM proxy nella rete VPC principale.

Utilizza istanze con più NIC per nascondere gli indirizzi del cluster

Questo pattern di architettura è costituito dai seguenti componenti e tecnologie per creare un modello simile a una rete in modalità isola:

  • Utilizza istanze Compute Engine con più schede di interfaccia di rete (multi-NIC) per creare un livello di separazione tra i cluster GKE e la rete VPC principale.
  • Utilizza NAT sugli indirizzi IP inviati tra questi ambienti.

Puoi utilizzare questo pattern quando devi ispezionare, trasformare o filtrare il traffico specifico che entra o esce dai cluster GKE. Se devi eseguire questo tipo di ispezione, trasformazione o filtraggio, utilizza le istanze Compute Engine di cui è stato eseguito il deployment per svolgere queste attività.

L'utilizzo di istanze con più NIC per nascondere gli indirizzi del cluster presenta i seguenti vantaggi:

  • Lo spazio degli indirizzi IP del cluster GKE è nascosto al resto della rete. Solo un indirizzo IP per servizio è esposto alla rete VPC di destinazione.
  • I servizi possono essere raggiunti a livello globale, da reti on-premise collegate e da reti peer.

Tuttavia, l'utilizzo di istanze con più NIC per nascondere gli indirizzi del cluster presenta i seguenti svantaggi:

  • Questo modello è più complesso da implementare rispetto ad altri approcci perché richiede non solo l'implementazione del modello, ma anche la configurazione del monitoraggio e della registrazione per le istanze multi-NIC.
  • Le istanze multi-NIC hanno limitazioni di larghezza di banda e sono soggette ai prezzi delle istanze VM.
  • Devi gestire e eseguire l'upgrade delle istanze con più NIC.

Passaggi successivi