Pianifica gli indirizzi IP durante la migrazione a GKE

Questo documento descrive come gestire l'utilizzo dell'indirizzo IP su Google Kubernetes Engine (GKE) e come utilizzare modelli di rete alternativi in GKE quando 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 modelli di networking alternativi possono essere implementati a GKE quando architettura del cluster non soddisfa i requisiti della tua organizzazione.

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

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

Questo documento non illustra le strategie di gestione per il intervallo di indirizzi utilizzato per gli indirizzi IP dei servizi. Il numero di indirizzi richiesti per i servizi è molto inferiore a quello per i pod 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 nel modo in cui l'IP dei pod raggiungibili in tutta la rete. Queste differenze hanno un impatto sulle strategie di gestione degli indirizzi IP utilizzabili. Per maggiori informazioni e informazioni dettagliate su questi modelli e di rete, vedi Confronto dei modelli di rete utilizzati da GKE e di 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 valuta attentamente quanti indirizzi IP univoci ti servono.

Il numero di indirizzi univoci che ti servono influisce sulla necessità di ridurre l'utilizzo degli indirizzi IP nel seguente modo:

  • 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, ridurre l'utilizzo degli indirizzi IP è utile per individuare 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, considera la le seguenti opzioni:

  • Modifica l'impostazione Pod per nodo. Per impostazione predefinita, GKE Standard di cluster prenotano Subnet /24 per ogni nodo, con un massimo di 110 pod per nodo. Se prevedi di o non usare più di 64 pod per nodo, regolare il numero massimo di pod per nodo e quindi dimezzare o più l'utilizzo degli indirizzi IP dei pod. Pilota automatico consentono 32 pod per nodo e questa impostazione non può essere modificata.
  • Utilizza più intervalli di indirizzi IP del pod. Utilizzo Routing inter-dominio senza classe multi-pod discontinuo (CIDR), puoi aggiungere intervalli secondari di indirizzi IP dei pod 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 ogni pool ti consente di conservativo durante l'allocazione dello spazio iniziale di indirizzi IP del pod, di far crescere il tuo cluster.

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

    Se utilizzi già lo spazio RFC 6598 altrove nel Enterprise, puoi utilizzare Classe E/RFC 5735 (240.0.0.0/4) per gli indirizzi IP dei pod. Tuttavia, il traffico proveniente da questi indirizzi IP vengono bloccati sugli host Windows e dell'hardware on-premise. Per evitare di bloccare gli indirizzi RFC 5735, valuta la possibilità mascherare il traffico verso queste destinazioni esterne, come descritto in sezione Nascondi gli indirizzi IP dei pod solo dalle reti on-premise. Tuttavia, perderai alcuni dati di telemetria indirizzati verso reti on-premise quando esegui il mascheramento del traffico verso destinazioni esterne.

Se la tua organizzazione dispone di un ampio spazio di indirizzi IP pubblici, puoi utilizzare anche 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 nella Modello di networking di GKE illustra il funzionamento dei cluster standard in GKE, inclusi il 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. Conoscendo il funzionamento del modello di networking di GKE ridurre gli indirizzi IP interni è fondamentale per qualsiasi modello di rete che usi in GKE.

Tuttavia, conoscere e applicare questi concetti potrebbe non fornirti una un'implementazione di rete che soddisfi le tue esigenze. La al 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.

L'albero decisionale inizia sempre con la creazione di GKE Cluster standard basati su un modello di rete completamente integrato. Il passaggio successivo nella struttura ad albero consiste nel ridurre l'utilizzo dell'indirizzo IP applicando tutte le 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 sfruttare i vantaggi del modello di rete completamente integrato, di mantenere i cluster GKE nello stesso come le 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 pattern di architetture alternative creano una modalità operativa GKE è simile al modello di rete in modalità isola in modalità isolata.

Ogni pattern di architettura alternativa 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 delle reti on-premise utilizza una combinazione dei seguenti obiettivi di routing:

  • Fai in modo che i cluster GKE su Google Cloud assegnino i pod Indirizzi IP instradati durante il deployment di 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 l'indirizzo IP di classe E/RFC 5735 perché questo spazio include molti indirizzi IP. Avere così tanti indirizzi IP disponibili 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 la specifica 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 una sovrapposizione di indirizzi IP tra quelli 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, lo spazio di classe E/RFC 5735 è in uso.
  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 tuo cluster GKE utilizzando l'IP secondario come routing tra domini (CIDR) senza classe per il pod. Tu puoi usare le strategie descritte in Riduci l'utilizzo degli indirizzi IP interni in GKE per ridurre l'utilizzo degli indirizzi IP.

  4. Aggiungi i seguenti indirizzi IP a l'elenco nonMasqueradeCIDRs dell'agente mascherato:

    • L'intervallo di indirizzi IP che hai 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 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 disponi per i carichi di lavoro Windows in Google Cloud, mantienili in subnet separate non includere nemmeno questi intervalli.

Quando segui i passaggi precedenti per impostare questo pattern, devi configurare di avere i seguenti comportamenti:

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

Affinché questo pattern alternativo emula completamente il modello di rete in modalità isola, devi modificare l'elenco nonMasqueradeCIDRs dell'agente mascherato in un elenco contenente solo gli intervalli di indirizzi IP di nodi e 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 dati di telemetria a livello di pod all'interno del VPC in ogni rete.

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 alle reti esterne. Come mostrato in questo diagramma, i pod all'interno di Google Cloud comunicare direttamente tra loro, anche tra cluster. Questo pod è simile 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 NAT di origine (SNAT) viene applicata 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.

Nascondere gli indirizzi IP dei pod dalle reti on-premise comporta quanto segue: vantaggi:

  • Puoi comunque sfruttare il modello di rete completamente integrato in Google Cloud, ad esempio utilizzare i firewall e raccogliere i dati di telemetria in base agli indirizzi IP dei pod. Inoltre, puoi connetterti ai pod direttamente a scopo 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 dei pod o dei servizi per diversi cluster in Google Cloud.
  • Potrebbe essere necessario gestire due diversi insiemi 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 da pod a pod nelle reti mesh di servizi multi-cluster che si estendono sia su Google Cloud sia sul tuo ambiente on-premise o di altri fornitori di servizi cloud. Quando, ad esempio, usi Istio, la comunicazione deve 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 cluster GKE.
  • I cluster GKE possono funzionare in modo indipendente richiedono la comunicazione in uscita verso molte applicazioni 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 da altre reti VPC.

I passaggi seguenti spiegano come configurare questo modello 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 tuo cluster che deve essere accessibili 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 di nascondere l'indirizzo IP utilizzando 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, le comunicazioni consentite avvengono tramite Endpoint Private Service Connect anziché tramite IP pubblico indirizzi IP esterni. 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 del servizio nella rete VPC del cluster. Anche la comunicazione tra cluster passa attraverso Endpoint Private Service Connect e servizio di un producer di servizi allegato.

L'uso di Private Service Connect per nascondere gli indirizzi IP dei pod 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 un solo indirizzo IP per servizio al che utilizzano la rete VPC.
  • Proteggere il cluster è più semplice perché questo modello definisce chiaramente quale sono esposti e solo quei servizi esposti sono raggiungibili il 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 sono in grado di stabilire la comunicazione privata all'esterno nel cluster. I pod possono comunicare solo con i servizi pubblici (quando i pod connettività 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 provider di servizi interni creano collegamenti ai servizi. Quindi, l'uso Private Service Connect funziona solo se il numero di questi sono limitati 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 rete La rete VPC stessa, non dal VPC in peering reti o reti connesse tramite Cloud VPN e 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 questa separazione, le funzioni di rete risultanti funzionano in modo simile modello di rete in modalità isola. Come nel caso del modello in modalità isola, questo pattern offre il vantaggio di riutilizzare Intervalli di indirizzi IP dei servizi tra i cluster. Il riutilizzo è possibile perché la comunicazione con le applicazioni esterne al cluster usa SNAT. I nodi utilizza SNAT per mappare gli indirizzi IP dei pod al proprio indirizzo IP del nodo prima il traffico esce 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. Dimensioni di questi intervalli di indirizzi IP in base alle esigenze 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 uno o entrambi i pod e i servizi di indirizzi IP per altre applicazioni. Se l'intervallo di indirizzi IP è in uso e non possono essere riservate, assicurati che le applicazioni che usano tali indirizzi IP non devono comunicare con GKE in un cluster Kubernetes.

  2. Per il cluster appena creato, configura l'elenco nonMasqueradeCIDRs dell'agente mascherato in un elenco contenente gli intervalli di indirizzi IP di nodi e pod del cluster. Questo elenco restituisce i risultati in GKE mascherando sempre il traffico in uscita dal cluster verso l'indirizzo IP del nodo, anche all'interno in Google 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 ciascun nodo.

  6. Se disponi di connettività alle reti on-premise tramite Cloud VPN o Cloud Interconnect, utilizza route annunciate 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 a quello della modalità isola di rete. Come mostrato nel diagramma, ogni cluster GKE viene dotato di una propria rete VPC separata. Ogni rete ha un IP nodo di indirizzi IP diverso, ma che 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.

Nota nel diagramma che solo i pod all'interno di un cluster possono comunicare direttamente una con l'altra. Il nodo utilizza SNAT per mascherare lo spazio di indirizzi IP del pod quando comunicano dall'esterno di un cluster a un altro, con l'azienda o a una rete on-premise connessa. Impossibile raggiungere direttamente i pod da altri cluster o dalla rete aziendale. Solo i servizi del cluster esposti con un bilanciatore del carico interno può essere raggiunto tramite Cloud VPN e connessioni a Internet.

L'utilizzo di Cloud VPN per nascondere gli indirizzi IP dei pod prevede quanto segue: vantaggi:

  • Come descritto nei 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 configurazioni perché gli indirizzi IP dei pod raggiungibili 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 comporta quanto segue: svantaggi:

  • Gli stessi svantaggi menzionati nel modello di rete in modalità isola . Ad esempio, non puoi impostare regole firewall a livello di pod. Inoltre impossibile raccogliere dati di telemetria a livello di pod nel VPC principale o una rete connessa.
  • Rispetto al modello di rete GKE predefinito, questo schema comporta costi aggiuntivi derivanti da costi associati ai tunnel VPN Cloud 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, eseguire queste azioni complica l'impostazione per l'impostazione e la gestione dell'implementazione di GKE.
  • Mantenere sincronizzati gli annunci di route aggiunge complessità al cluster per la creazione di contenuti. 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.

Nascondere 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 che assomiglia a un modello di rete in modalità isola, ma tramite l'utilizzo privato di questo spazio di indirizzi IP pubblici. 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. Dimensioni di questi intervalli di indirizzi IP in base alle esigenze che prevedi di utilizzare. Prenota ciascuno di questi intervalli per per un uso esclusivo in GKE. Puoi anche riutilizzare questi intervalli per tutti i cluster GKE della tua organizzazione.

    In teoria, anziché utilizzare l'assegnazione dell'indirizzo IP pubblico, possibile utilizzare l'indirizzo IP pubblico inutilizzato, più grande 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 il traffico di GKE esegue sempre il mascheramento all'indirizzo IP del nodo, anche all'interno di Google Cloud.

  3. Utilizza il peering di rete VPC per connettere la rete VPC contiene il cluster GKE nell'istanza esistente (principale) rete VPC. 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 ciascun 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 di nascondere gli indirizzi IP utilizzando PUPI e 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 un cluster dispone di una rete VPC separata. Ogni nodo ha un uno spazio di indirizzi IP del nodo distinto, ma utilizza lo stesso spazio di indirizzi IP del pod che definito dallo spazio di indirizzi PUPI della tua organizzazione. Le reti VPC si connettono tra loro e ad applicazioni non Kubernetes in Google Cloud tramite il peering di rete VPC. Lo spazio degli indirizzi PUPI è non pubblicizzato tra i peering. Le reti VPC si connettono attraverso la 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 una rete on-premise connessa. I pod non possono essere raggiunti direttamente da altri o la rete aziendale. Solo i servizi esposti con un carico interno può essere raggiunto tramite le connessioni di peering di rete VPC.

Questo modello di architettura è simile Approccio Cloud VPN descritto in precedenza, ma presenta i seguenti vantaggi rispetto a questo modello:

  • A differenza del pattern di architettura Cloud VPN,il peering di rete VPC non prevede costi aggiuntivi per i tunnel Cloud VPN di 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 sul modello Cloud VPN:

  • La tua organizzazione richiede uno spazio di indirizzi IP pubblici che sia inutilizzato e sia abbastanza grande per lo spazio di indirizzi IP del pod necessario il cluster GKE che prevedi di avere.
  • Il peering di rete VPC non è transitivo. Per questo motivo, collegati tramite peering di rete VPC alla rete VPC La rete VPC non può comunicare direttamente tra loro o con delle applicazioni nelle reti VPC in peering in un VPC. ma devi collegare direttamente queste reti Peering di rete VPC per abilitare questa comunicazione o utilizzare una VM proxy la rete VPC principale.

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

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

  • Utilizza istanze di Compute Engine con più schede di interfaccia di rete (multi-NIC) per creare un livello di separazione tra GKE cluster e alla 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 filtro, utilizza di istanze Compute Engine di cui è stato eseguito il deployment per eseguire queste attività.

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

  • Lo spazio di indirizzi IP del cluster GKE è nascosti al resto della rete. Un solo indirizzo IP per ogni servizio sia esposta alla rete VPC che utilizza.
  • I servizi possono essere raggiunti a livello globale da on-premise connessi da reti e da reti in peering.

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 ed eseguire l'upgrade delle istanze con più NIC.

Passaggi successivi