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 con GKE quando 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 di indirizzo 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 di cluster Kubernetes da altri ambienti cloud-native 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 presuppone che tu abbia familiarità con Kubernetes e le relative modello di networking. 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, di indirizzi IP del servizio è fisso per tutta la durata del cluster. Pertanto, l'intervallo di indirizzi IP del servizio deve essere dimensionato secondo le dimensioni massime di Google Cloud. Perché gli indirizzi IP del servizio non sono raggiungibili all'esterno del cluster, puoi riutilizzarli in altre reti.

Questo documento fa anche riferimento a diversi modelli di rete di Kubernetes: completamente integrato, a 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 ulteriori informazioni informazioni dettagliate su questi modelli e su GKE di rete, vedi Confronto dei modelli di rete utilizzati da GKE e di altre implementazioni di Kubernetes.

Riduci l'utilizzo degli indirizzi IP interni in GKE

GKE utilizza un cluster un modello di rete completamente integrato in cui viene eseguito il deployment dei cluster in una rete VPC contengono anche altre applicazioni. Il modello GKE ha molti vantaggi. Tuttavia, questo tipo di modello non consente agli indirizzi IP dei pod di essere riutilizzate. Questo mancato riutilizzo richiede l'uso di indirizzi IP dei pod univoci in tutta la 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 di indirizzi sufficiente per le esigenze del tuo indirizzo IP, non devono necessariamente adottare misure per ridurre l'utilizzo dell'indirizzo IP. Tuttavia, ridurre l'utilizzo degli indirizzi IP è utile per individuare il numero minimo di indirizzi IP da utilizzare.
  • Se non hai abbastanza spazio di indirizzi, devi ridurre gli indirizzi IP per creare GKE cluster che si adattano ai vincoli dello spazio degli indirizzi.

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

  • Cambia 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 seleziona quale intervallo di indirizzi IP dei pod pool di nodi utilizzi. 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 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 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 usi gli indirizzi PUPI, devi Includi 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 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 Riduci l'utilizzo degli indirizzi IP interni in GKE descrive come ridurre il numero di indirizzi IP interni necessari in quelle 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 utilizzi il più possibile gli indirizzi IP e continui a non di uno spazio di indirizzi sufficiente per i tuoi cluster GKE, un modello di rete alternativo. L'albero decisionale ti aiuta a decidere quale seguenti modelli di rete alternativi da utilizzare:

Ricorda che questo albero decisionale deve essere utilizzato solo come guida. Secondo al tuo caso d'uso specifico, potresti comunque preferire un altro modello basato vantaggi e svantaggi di ogni modello. Spesso vengono utilizzati più modelli sono attuabili e potrai scegliere l'approccio più adatto alla tua organizzazione.

In rari casi i modelli alternativi presentati nella decisione non soddisfano le tue esigenze. In questi rari casi, potresti essere in grado di utilizzare descritto in precedenza Utilizzo di istanze con più NIC per nascondere gli indirizzi dei 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 segui questo consiglio. Potresti non avere abbastanza spazio per gli indirizzi IP oppure potrebbe essere necessario nascondere gli indirizzi IP dei pod in ogni rete.

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 architetture alternative creano una modalità operativa GKE è simile al modello di rete in modalità isola in modalità isolata.

Ogni modello 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 i pod Indirizzi IP instradati durante il deployment di Google Cloud.
  • Impedisci a questi indirizzi IP di essere instradati senza NAT verso on-premise alle tue risorse o ad altri ambienti cloud 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 disponibile consente di soddisfare la necessità di fornire indirizzi IP univoci in ogni pod. Tuttavia, gli indirizzi IP di classe E/RFC 5735 non possono essere facilmente indirizzati delle 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 dei seguenti da questi altri insiemi di indirizzi IP, determinano se c'è sovrapposizione di IP gli indirizzi tra gli indirizzi utilizzati per i pod e quelli utilizzati nelle reti on-premise. In caso di sovrapposizione, assicurati che non vi siano mai comunicazione tra cluster che utilizzano questi indirizzi e che utilizzano gli stessi indirizzi.

I passaggi seguenti spiegano come configurare questo modello di architettura:

  1. Crea un intervallo di indirizzi IP secondari per la subnet del pod. Come in precedenza descritto in questa sezione, puoi creare questo indirizzo lo spazio Class E/RFC 5735, lo spazio RFC 1918 o uno spazio interno un insieme di indirizzi IP non RFC 1918. In genere, lo spazio di classe E/RFC 5735 è in uso.
  2. Utilizza le funzionalità di route annunciate personalizzate e rimuoveremo l'intervallo di indirizzi IP del pod dagli annunci i router Cloud. La rimozione di questi indirizzi contribuisce a garantire che l'IP del pod non vengono annunciati tramite 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, come 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 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:

  • Funziona come un modello di rete completamente integrato all'interno di 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. Questo elenco 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 da indirizzi IP esterni reti. Come mostrato in questo diagramma, i pod all'interno di Google Cloud comunicare direttamente tra loro, anche tra cluster. Questo pod è simile Modello GKE. Nota che il diagramma mostra anche i pod che utilizzano indirizzi nella classe spazio E/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 utilizzata indipendentemente che il traffico venga instradato tramite Cloud VPN a on-premise. applicazioni 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 è mascherato solo quando è indirizzato verso per applicazioni on-premise o altri ambienti cloud. Anche se non riesci a connetterti a I 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 all'interno di Google Cloud, ad esempio utilizzando firewall e raccogliendo dati di telemetria e i dati 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 gli indirizzi IP dei pod all'interno di Google Cloud.

Tuttavia, nascondere gli indirizzi IP dei pod dalle reti esterne comporta quanto segue: svantaggi:

  • Non puoi riutilizzare intervalli di indirizzi IP di pod o servizi per diversi 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 la comunicazione diretta tra pod nel servizio multi-cluster che coprono sia Google Cloud che la tua rete on-premise dell'ambiente dei provider 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 quando 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 offre un modo per pubblicare e i servizi che devono essere consumati da altre reti. Puoi esporre i servizi GKE mediante un bilanciatore del carico di rete passthrough interno collegamenti ai servizi, e consumare questi servizi tramite 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 cluster GKE richiede il traffico in uscita comunicazione con alcune applicazioni nella tua rete aziendale, le applicazioni di pubblicazione 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 Il modello Private Service Connect è simile a un modello di rete isolato. 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 la propria rete VPC separata. Inoltre, ogni rete VPC può condividere lo stesso indirizzo IP e ogni cluster possono condividere lo stesso spazio di indirizzi IP. Solo i pod all'interno di un cluster possono comunicare l'una con l'altra.

Per le comunicazioni dall'esterno del cluster, il diagramma mostra come un'applicazione esterna può raggiungere il cluster attraverso Endpoint Private Service Connect. Questo endpoint si connette collegamento al servizio fornito dal producer di servizi nel cluster rete VPC. 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 è necessario pianificare gli indirizzi IP perché lo spazio degli indirizzi IP il cluster GKE è nascosto al resto dei in ogni rete. Questo approccio espone un solo indirizzo IP per servizio alla 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 I pod possono anche raggiungere quei servizi. 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 in. 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 seguenti passaggi spiegano 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 per un uso esclusivo in GKE. Riutilizzi anche 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 che contiene Cluster GKE alla rete VPC esistente (principale).

  4. Utilizza le funzionalità di route annunciate personalizzate per impedire alla rete VPC del cluster di pubblicizzare l'IP di pod e servizi di indirizzi IP diretti verso la 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 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 altre reti sono connesse alla rete VPC principale tramite Peering di rete VPC, esportare route personalizzate su questi peering per garantire che i nodi del cluster GKE a raggiungere le reti in peering.

Il seguente diagramma mostra un'implementazione dell'utilizzo di Cloud VPN per nascondi 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 a quello della modalità isola di rete. Come mostrato nel diagramma, ogni cluster GKE ottiene la 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 a ogni alla rete aziendale e lo spazio di indirizzi IP del pod non è 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 altre connessioni.

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 networking GKE predefinito, questo pattern comporta costi aggiuntivi derivanti i costi associati ai tunnel Cloud VPN e addebiti per il trasferimento di dati.
  • Cloud VPN ha limite di larghezza di banda per tunnel VPN. Se raggiungi questo limite di larghezza di banda, puoi configurare più i tunnel Cloud VPN e distribuiscono il traffico utilizzando 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, configurare i tunnel Cloud VPN e creare annunci personalizzati su questi tunnel e alle 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 un modello architetturale che ricorda modello di rete in modalità isola ma attraverso l'uso privato di questo spazio di indirizzi IP pubblici. Questa architettura è simile al che utilizza Cloud VPN ma utilizza Peering di rete VPC per creare la separazione tra il cluster GKE e l'istanza principale in ogni rete.

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.

    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. Riutilizzi anche 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, Sconsiglia vivamente questa configurazione perché gli indirizzi IP potrebbero essere venduti o utilizzati pubblicamente in qualsiasi momento. La vendita o l'utilizzo degli indirizzi ha contribuito a garantire la sicurezza e problemi di connettività durante l'utilizzo di servizi pubblici su internet.

  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 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, Impostare il flag --no-export-subnet-routes-with-public-ip durante la configurazione e il 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 di connettività alle reti on-premise tramite Cloud VPN o Cloud Interconnect, utilizza annunci di route personalizzati annuncia 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 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. Il VPC le reti si connettono tra loro e ad applicazioni non Kubernetes Google Cloud tramite 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 è integrate nelle reti software-defined di Google. Pertanto, Il peering di rete VPC potrebbe fornire una latenza leggermente inferiore rispetto Cloud VPN perché il peering non richiede i gateway l'elaborazione richiesta da 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 modello di architettura è costituito dai seguenti componenti e tecnologie per creare un modello di rete simile a un modello di 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.

Potresti usare questo pattern per ispezionare, trasformare o filtrare specifico che entra o esce dai cluster GKE. Se devi eseguire questo tipo di ispezione, trasformazione o filtro, utilizza la di istanze Compute Engine di cui è stato eseguito il deployment per eseguire queste attività.

L'uso di istanze con più NIC per nascondere gli indirizzi dei cluster ha quanto segue 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 dei cluster ha quanto segue svantaggi:

  • Questo modello è più complesso da implementare rispetto ad altri approcci perché non solo richiede l'implementazione del modello, ma anche il monitoraggio e il logging delle istanze con più NIC.
  • Le istanze con più NIC hanno limitazioni della larghezza di banda e sono soggetti alle Prezzi delle istanze VM.
  • Devi gestire ed eseguire l'upgrade delle istanze con più NIC.

Passaggi successivi