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 tratta i seguenti concetti:

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

Questo documento è rivolto ai Cloud Architect, Operations Engineer e Network Engineer che hanno in programma di eseguire la migrazione dei cluster Kubernetes da altri ambienti a GKE. Utilizza le indicazioni in questo documento quando per la tua organizzazione è difficile assegnare un numero sufficiente di indirizzi IP interni per l'utilizzo previsto di GKE.

Questo documento presuppone che tu conosca Kubernetes e il suo modello di rete. Dovresti anche avere familiarità con concetti di networking come gli indirizzi IP, il NAT (Network Address Translation), 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 ridurlo sono limitate. In GKE, l'intervallo di indirizzi IP del servizio è fisso per 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 del servizio non sono raggiungibili all'esterno del cluster, puoi riutilizzarli in altre reti.

Questo documento fa riferimento anche a diversi modelli di rete Kubernetes: completamente integrati, in modalità isola e isolati. Questi modelli differiscono nel modo in cui gli indirizzi IP dei pod possono essere raggiunti attraverso la rete. Queste differenze hanno un impatto sulle strategie di gestione degli indirizzi IP utilizzabili. Per informazioni più dettagliate su questi modelli e sul modello di rete GKE, consulta il confronto dei modelli di rete utilizzati da GKE e da altre implementazioni Kubernetes.

Riduci l'utilizzo degli indirizzi IP interni in GKE

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

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

  • Se disponi di spazio di indirizzi sufficiente per le esigenze dell'indirizzo IP, non devi necessariamente 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 hai abbastanza spazio di indirizzi, devi ridurre l'utilizzo degli indirizzi IP per creare cluster GKE che si adattino ai vincoli del tuo spazio di indirizzi.

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

  • Modifica l'impostazione dei pod per nodo. Per impostazione predefinita, i cluster GKE Standard prenotano un intervallo di subnet /24 per ogni nodo e consentono fino a 110 pod per nodo. Se prevedi di utilizzare solo 64 pod per nodo, puoi regolare il numero massimo di pod per nodo e quindi dimezzare o più l'utilizzo degli indirizzi IP dei pod. I cluster Autopilot consentono 32 pod per nodo e questa impostazione non può essere modificata.
  • Utilizza più intervalli di indirizzi IP dei pod. Utilizzando il routing tra domini diversi senza classe di pod (CIDR multi-Pod), puoi aggiungere intervalli di indirizzi IP dei pod secondari ai cluster esistenti. Puoi selezionare l'intervallo di indirizzi IP dei pod utilizzato da ciascun pool di nodi. La selezione dell'intervallo di indirizzi IP utilizzato da ogni pool ti consente di essere conservativo nell'allocazione dello spazio di indirizzi IP del pod iniziale, pur continuando a far crescere il cluster.

  • Utilizza indirizzi IP non conformi alla RFC 1918. La tua rete aziendale potrebbe non avere un numero sufficiente di indirizzi IP RFC 1918 non allocati da utilizzare per gli indirizzi IP dei pod. Se non disponi di un numero sufficiente di indirizzi IP RFC 1918 non allocati, puoi utilizzare indirizzi non RFC 1918, ad esempio quelli nello spazio di indirizzi RFC 6598 (100.64.0.0/10).

    Se utilizzi già lo spazio RFC 6598 altrove nella tua rete aziendale, puoi utilizzare lo spazio di indirizzi Class E/RFC 5735 (240.0.0.0/4) per gli indirizzi IP dei pod. Tuttavia, il traffico 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 mascherare il traffico verso queste destinazioni esterne come descritto nella sezione Nascondi gli indirizzi IP dei pod solo dalle reti on-premise. Tuttavia, quando nascondi il traffico verso destinazioni esterne, perderai alcuni dati di telemetria indirizzati alle applicazioni on-premise.

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

Scegli 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. Sapere come funziona il modello di networking GKE e come ridurre gli indirizzi IP interni è fondamentale per qualsiasi modello di rete che utilizzi in GKE.

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

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

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

Se hai ridotto il più possibile l'utilizzo degli indirizzi IP e continui a non disporre di sufficiente spazio di indirizzi per i tuoi cluster GKE, hai bisogno di un modello di rete alternativo. La struttura 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 ognuno. Spesso è possibile lavorare più con più modelli e scegliere l'approccio più adatto alla tua organizzazione.

In rari casi, i modelli alternativi presentati nella struttura decisionale non soddisfano le tue esigenze. In questi rari casi, potresti essere in grado di utilizzare il modello descritto in Utilizzo di istanze multi-NIC per nascondere gli indirizzi del cluster.

Emula modelli di rete alternativi

Per sfruttare i 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 riuscire a seguire questo consiglio. Potresti non disporre di spazio di indirizzi IP sufficiente o potresti dover nascondere gli indirizzi IP dei pod dalla rete più grande della tua organizzazione.

Questa sezione fornisce opzioni per utilizzare il modello di rete completamente integrato descrivendo diversi pattern di architettura che imitano vari modelli di rete alternativi su GKE. Questi pattern di architettura alternativi creano una modalità operativa per GKE simile al modello di rete in modalità isola o al modello di rete in modalità isolata.

Ogni pattern di architettura alternativo include le seguenti informazioni:

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

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

  • Fai in modo che i cluster GKE su Google Cloud assegnino indirizzi IP dei pod che vengono instradati tramite il deployment di Google Cloud.
  • Impedisci il routing di questi indirizzi IP senza NAT verso risorse on-premise o verso 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é questo spazio include molti indirizzi IP. La disponibilità di un numero così elevato di indirizzi IP aiuta a soddisfare la necessità di fornire indirizzi IP univoci a ogni pod. Tuttavia, non è facile instradare facilmente gli indirizzi IP di classe E/RFC 5735 a 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 set interno di indirizzi IP non RFC 1918. Se utilizzi uno di questi altri insiemi di indirizzi IP, determina se esiste una sovrapposizione di indirizzi IP tra gli indirizzi utilizzati per i pod e quelli utilizzati nelle reti on-premise. In caso di sovrapposizione, assicurati che non ci sia mai alcuna comunicazione tra i cluster che utilizzano quegli indirizzi e le applicazioni on-premise che utilizzano quegli stessi indirizzi.

I passaggi seguenti spiegano come configurare questo pattern di architettura:

  1. Crea un intervallo di indirizzi IP secondari per la subnet del pod. Come descritto in precedenza in questa sezione, puoi creare questo intervallo di indirizzi dallo spazio Classe E/RFC 5735, dallo spazio RFC 1918 o da un set interno di indirizzi IP non RFC 1918. In genere, viene utilizzato lo spazio di classe E/RFC 5735.
  2. Utilizza gli annunci di route personalizzate e rimuovi l'intervallo IP dei pod dagli annunci sui router Cloud. La rimozione di questi indirizzi garantisce che gli intervalli IP dei pod non vengano annunciati tramite il Border Gateway Protocol (BGP) ai router on-premise.
  3. Crea il tuo cluster GKE utilizzando l'intervallo di indirizzi IP secondari come routing CIDR (Classless Inter-Domain Routing) 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 mascheramento:

    • 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 subnet separate e non includere neanche questi intervalli.

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

  • Agire come un modello di rete completamente integrato all'interno di Google Cloud.
  • Agire come un modello di rete in modalità isola quando interagisci con le reti on-premise.

Affinché questo pattern alternativo emuli completamente il modello di rete in modalità isola, devi sostituire l'elenco nonMasqueradeCIDRs nell'agente di mascheramento in un elenco contenente solo gli intervalli di indirizzi IP dei pod e dei nodi del cluster. La creazione di un elenco di questo tipo comporta sempre il mascheramento del traffico dall'esterno del cluster all'indirizzo IP del nodo, anche all'interno di Google Cloud. Tuttavia, dopo aver apportato questa modifica, non puoi raccogliere 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 di nascondere l'indirizzo IP solo dalle reti on-premise.

Il diagramma precedente mostra come nascondere gli indirizzi IP dei pod dalle reti esterne. Come mostrato in questo diagramma, i pod in Google Cloud possono comunicare direttamente tra loro, anche tra cluster. Questa comunicazione con i pod è simile al modello GKE. Nota che il diagramma mostra anche i pod che utilizzano indirizzi nello spazio Classe E/RFC 5735.

Per il traffico inviato all'esterno dei cluster, il diagramma mostra in che modo la NAT (SNAT) di origine viene applicata al traffico quando esce dal nodo. SNAT viene utilizzato indipendentemente dal fatto che il traffico venga instradato tramite Cloud VPN ad applicazioni on-premise o tramite Cloud NAT verso 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 se diretto verso applicazioni on-premise o 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.

Nascondere gli 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 dati di telemetria basati sugli indirizzi IP dei pod. Puoi anche connetterti ai pod direttamente per scopi di debug da Google Cloud.
  • Puoi comunque utilizzare mesh di servizi multi-cluster con indirizzi IP dei pod all'interno di Google Cloud.

Tuttavia, nascondere gli indirizzi IP dei pod dalle reti esterne presenta i seguenti svantaggi:

  • Non puoi riutilizzare gli intervalli di indirizzi IP di pod o servizi per cluster diversi all'interno di Google Cloud.
  • Potrebbe essere necessario gestire due diversi set di regole firewall: uno per il traffico tra reti on-premise e uno per il traffico completamente all'interno di Google Cloud.
  • Non puoi avere una comunicazione diretta tra pod in reti di servizi multi-cluster che coprono sia Google Cloud che il tuo ambiente on-premise o di altri fornitori di servizi cloud. Ad esempio, quando si utilizza Istio, tutte le comunicazioni devono avvenire tra i gateway Istio.

Nascondi 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 dei cluster GKE.
  • I cluster GKE possono funzionare in modo indipendente e non richiedono la comunicazione in uscita con molte applicazioni nella tua rete aziendale.

Private Service Connect consente di pubblicare i servizi che devono essere utilizzati da altre reti. Puoi esporre i tuoi servizi GKE utilizzando un bilanciatore del carico di rete passthrough interno e i collegamenti ai servizi e utilizzare questi servizi utilizzando un endpoint da altre reti VPC.

I passaggi seguenti spiegano come configurare questo pattern di architettura:

  1. Crea un cluster GKE in una rete VPC separata. La rete VPC deve contenere solo quel cluster.
  2. Per ogni servizio GKE nel tuo 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 cluster GKE ha bisogno di comunicazione in uscita verso alcune applicazioni nella rete aziendale, esponi tali applicazioni pubblicando servizi tramite Private Service Connect.

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

Diagramma di rete che mostra l'implementazione di nascondere l'indirizzo IP utilizzando Private Service Connect.

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

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

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

  • Non è necessario pianificare gli indirizzi IP perché lo spazio di indirizzi IP del cluster GKE è nascosto al resto della rete. Questo approccio espone un solo indirizzo IP per servizio alla rete VPC che utilizza.
  • Proteggere il cluster è più semplice perché questo modello definisce chiaramente quali servizi sono esposti e solo quelli esposti 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 una comunicazione privata all'esterno del cluster. I pod possono comunicare solo con servizi pubblici (se i pod sono connessi 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 ai servizi. Pertanto, l'utilizzo di Private Service Connect funziona solo quando il numero di questi servizi è limitato ai fornitori che forniscono allegati.
  • Gli endpoint sono raggiungibili solo dalla stessa regione in cui si trova il servizio. Inoltre, questi endpoint sono raggiungibili solo dalla rete VPC connessa, non da reti VPC in peering o reti connesse tramite Cloud VPN o Cloud Interconnect.

Nascondi 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 intervalli di indirizzi IP di pod e servizio tra i cluster. Il riutilizzo è possibile perché la comunicazione con le applicazioni esterne al cluster utilizza SNAT. I nodi utilizzano SNAT per mappare gli indirizzi IP dei pod al proprio indirizzo IP del nodo prima che il traffico esca dal nodo.

I passaggi seguenti spiegano come configurare questo modello:

  1. Crea un cluster GKE in una rete VPC separata. 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. Dimensiona questi intervalli di indirizzi IP in base alle esigenze del cluster GKE più grande che pensi di utilizzare. Prenota ciascuno di questi intervalli per un uso esclusivo all'interno di GKE. Potrai 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 uno o entrambi gli intervalli di indirizzi IP per 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 che hai appena creato, configura l'elenco nonMasqueradeCIDRs nell'agente di mascheramento in un elenco contenente gli intervalli di indirizzi IP dei nodi e dei pod del cluster. Da questo elenco, GKE maschera sempre il traffico lasciando il cluster all'indirizzo IP del nodo, anche all'interno di Google Cloud.

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

  4. Utilizza gli annunci di route personalizzate 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 pod e servizi. Tuttavia, utilizza indirizzi IP distinti per ciascun nodo.

  6. Se disponi della connettività alle reti on-premise tramite Cloud VPN o Cloud Interconnect, utilizza gli annunci di route personalizzati per pubblicizzare manualmente gli intervalli IP dei nodi.

  7. Se hai altre reti connesse alla rete VPC principale tramite peering di rete VPC, esporta route personalizzate su questi peering per assicurarti che i nodi del cluster GKE possano raggiungere le reti in 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 di nascondere l'indirizzo IP utilizzando 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 dispone di una propria rete VPC separata. Ogni rete ha uno spazio di indirizzi IP dei nodi distinto, ma che utilizza lo stesso spazio di indirizzi IP del pod. I tunnel Cloud VPN collegano queste reti VPC tra loro e alla rete aziendale e lo spazio di indirizzi IP dei pod non viene pubblicizzato nelle reti VPC che contengono cluster.

Nel diagramma, solo i pod di un cluster possono comunicare direttamente tra loro. Il nodo utilizza SNAT per mascherare lo spazio di indirizzi IP del pod durante la comunicazione all'esterno del cluster con un altro cluster, con la rete aziendale o con una rete on-premise connessa. Non è possibile raggiungere i pod direttamente da altri cluster o dalla rete aziendale. Solo i servizi del 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 servizio tra i cluster.
  • I firewall potrebbero richiedere una configurazione inferiore perché gli indirizzi IP dei pod non possono essere raggiunti direttamente dalla rete VPC principale e dalle reti connesse. Pertanto, 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 svantaggi:

  • Si applicano gli stessi svantaggi menzionati nel modello di rete in modalità isola. Ad esempio, non puoi impostare regole firewall a livello di pod. Inoltre, non puoi raccogliere dati di telemetria a livello di pod nella rete VPC principale o nella rete connessa.
  • Rispetto al modello di networking GKE predefinito, questo pattern comporta costi aggiuntivi derivanti dai costi associati ai tunnel Cloud VPN e dagli 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 ECMP (equal-cost multipath). Tuttavia, eseguire queste azioni aumenta la complessità della configurazione e della gestione dell'implementazione GKE.
  • Mantenere sincronizzati gli annunci di route aggiunge complessità alla creazione dei cluster. Ogni volta che crei nuovi cluster GKE, devi configurare i tunnel Cloud VPN e creare pubblicità di route personalizzate su questi tunnel e verso applicazioni on-premise.

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

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

I passaggi seguenti spiegano come configurare questo pattern di architettura:

  1. Crea un cluster GKE in una rete VPC separata. 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. Dimensiona questi intervalli di indirizzi IP in base alle esigenze del cluster GKE più grande che pensi di utilizzare. Prenota ciascuno di questi intervalli per un uso esclusivo all'interno di GKE. Potrai anche riutilizzare questi intervalli per tutti i cluster GKE della tua organizzazione.

    Anziché utilizzare l'assegnazione dell'indirizzo IP pubblico, in teoria è possibile utilizzare i blocchi di indirizzi IP pubblici più grandi e inutilizzati di proprietà di terze parti. Tuttavia, sconsigliamo vivamente di eseguire questa configurazione, perché questi indirizzi IP potrebbero essere venduti o utilizzati pubblicamente in qualsiasi momento. La vendita o l'utilizzo di indirizzi comporta problemi di sicurezza e connettività quando si utilizzano i servizi pubblici su internet.

  2. Per il cluster che hai appena creato, configura l'elenco nonMasqueradeCIDRs nell'agente di mascheramento in un elenco contenente gli intervalli di indirizzi IP dei nodi e dei pod del cluster. Da questo elenco, GKE maschera sempre il traffico che lascia il 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 (principale) esistente. 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 pod e servizi. Tuttavia, utilizza un indirizzo IP distinto per ciascun nodo.

  5. Se disponi della connettività a reti on-premise tramite Cloud VPN o Cloud Interconnect, utilizza gli annunci di route personalizzate per pubblicizzare 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 di nascondere gli indirizzi IP utilizzando PUPI e il peering di rete VPC.

Il diagramma precedente mostra come nascondere gli indirizzi IP utilizzando il peering di rete VPC. Come illustrato 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 dell'organizzazione. Le reti VPC si connettono tra loro e ad applicazioni non Kubernetes in Google Cloud tramite il peering di rete VPC. Lo spazio di indirizzi PUPI non è pubblicizzato tra i peering. Le reti VPC si connettono alla rete aziendale tramite tunnel Cloud VPN.

Solo i pod all'interno di un cluster possono comunicare direttamente tra loro. Il nodo utilizza SNAT per mascherare lo spazio IP del pod durante la comunicazione dall'esterno del cluster a un altro cluster, alla rete aziendale o a una rete on-premise connessa. 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 di peering di 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 prevede costi aggiuntivi per i tunnel Cloud VPN o per 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, poiché il peering non richiede i gateway e l'elaborazione necessari da 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 pubblici inutilizzato e abbastanza grande da contenere lo spazio di indirizzi IP del pod necessario al cluster GKE più grande che ti aspetti di avere.
  • Il peering di rete VPC è non transitorio. Pertanto, i cluster GKE connessi tramite peering di rete VPC alla rete VPC principale non possono comunicare direttamente tra loro o con le applicazioni nelle reti VPC in peering con il VPC principale. Devi connettere direttamente queste reti tramite peering di rete VPC per abilitare questa comunicazione, oppure utilizzare una VM proxy nella rete VPC principale.

Utilizza istanze multi-NIC per nascondere gli indirizzi del cluster

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

  • Utilizza le istanze di 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 scambiati 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 filtro, utilizza le istanze di Compute Engine di cui è stato eseguito il deployment per eseguire queste attività.

L'utilizzo di istanze multi-NIC per nascondere gli indirizzi del cluster presenta i seguenti vantaggi:

  • Lo spazio di indirizzi IP del cluster GKE è nascosto al resto della rete. Alla rete VPC che utilizza il servizio è esposto un solo indirizzo IP per servizio.
  • I servizi sono raggiungibili a livello globale, da reti on-premise connesse e da reti in peering.

Tuttavia, l'utilizzo di istanze multi-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 del logging 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 ed eseguire l'upgrade delle istanze multi-NIC.

Passaggi successivi