Gestire la migrazione degli indirizzi IP in 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 soddisfi le esigenze di indirizzi IP della maggior parte delle organizzazioni.
  • Come implementare modelli di networking alternativi su GKE quando l'architettura del cluster non soddisfa i requisiti della tua organizzazione.

Questo documento è destinato ad architetti cloud, ingegneri delle operazioni e ingegneri di rete che pianificano di eseguire la migrazione dei cluster Kubernetes da altri ambienti a GKE. Utilizza le indicazioni riportate in questo documento quando la tua organizzazione ha difficoltà ad 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 networking. Devi inoltre conoscere i concetti di networking come l'indirizzamento IP, la traduzione degli indirizzi di rete (NAT), i firewall e i proxy.

Questo documento non tratta le strategie di gestione per l'intervallo di indirizzi utilizzato per gli indirizzi IP del servizio. Il numero di indirizzi richiesti per i servizi è molto inferiore a quello per i pod e le opzioni per ridurre questo numero sono limitate. Su GKE, l'intervallo di indirizzi IP del servizio è fisso per tutta la durata del cluster. Pertanto, l'intervallo di indirizzi IP del servizio deve essere dimensionato in base al numero massimo previsto di servizi. Poiché gli indirizzi IP del servizio 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à isolata e isolato. Questi modelli differiscono nel modo in cui è possibile raggiungere gli indirizzi IP dei pod nella rete. Queste differenze influiscono sulle strategie di gestione degli indirizzi IP che possono essere utilizzate. Per informazioni più dettagliate su questi modelli e sul modello di rete GKE, consulta Confronto tra i modelli di rete utilizzati da GKE e 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 implementati in una rete VPC che può contenere anche altre applicazioni. Il modello GKE offre 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 del pod unici in tutta la rete VPC. Pertanto, devi valutare attentamente il numero di indirizzi IP univoci di cui hai bisogno.

Il numero di indirizzi unici necessari influisce sulla necessità di ridurre l'utilizzo degli indirizzi IP, come segue:

  • Se hai spazio di indirizzamento sufficiente per le tue esigenze di indirizzi 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 spazio di indirizzamento sufficiente, devi ridurre l'utilizzo degli indirizzi IP per creare cluster GKE che rientrino nei vincoli dello spazio di indirizzamento.

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

  • Modifica l'impostazione Pod per nodo. Per impostazione predefinita, i cluster GKE Standard riservano un intervallo di subnet /24 per ogni nodo e consentono fino a 110 pod per nodo. Se prevedi di utilizzare solo 64 o meno pod per nodo, puoi modificare il numero massimo di pod per nodo e quindi ridurre l'utilizzo degli indirizzi IP dei pod della metà o più. I cluster Autopilot consentono 32 pod per nodo e questa impostazione non può essere modificata.
  • Utilizza più intervalli di indirizzi IP del pod. Utilizzando il CIDR (Classless Inter-Domain Routing) multi-pod discontiguo, puoi aggiungere intervalli di indirizzi IP secondari dei pod ai cluster esistenti. Puoi selezionare l'intervallo di indirizzi IP del pod che ogni pool di nodi utilizza. Se selezioni l'intervallo di indirizzi IP utilizzato da ogni pool, puoi essere conservativo durante l'allocazione dello spazio iniziale degli indirizzi IP dei pod, pur potendo aumentare le dimensioni del cluster.
  • Utilizza indirizzi IP non RFC 1918. La tua rete aziendale potrebbe non avere indirizzi IP RFC 1918 non allocati sufficienti da utilizzare per gli indirizzi IP dei pod. Se non hai abbastanza indirizzi IP RFC 1918 non allocati, puoi utilizzare indirizzi non RFC 1918, come gli indirizzi 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 Classe E/RFC 5735 (240.0.0.0/4) per gli indirizzi IP dei pod. Tuttavia, il traffico proveniente da questi indirizzi IP viene bloccato sugli host Windows e su alcuni hardware on-premise. Per evitare di bloccare gli indirizzi RFC 5735, valuta la possibilità di mascherare il traffico verso queste destinazioni esterne come descritto nella sezione Nascondere gli indirizzi IP dei pod dalle reti on-premise. Tuttavia, quando mascheri il traffico verso destinazioni esterne, perdi 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 indirizzi PUPI, devi includerli nell'elenco nonMasqueradeCIDRs per avere connettività all'esterno del cluster senza utilizzare NAT.

Scegliere un modello di rete in GKE

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

Tuttavia, la semplice conoscenza e applicazione di questi concetti potrebbe non fornirti 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.

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

Se hai ridotto al massimo l'utilizzo degli indirizzi IP e non hai ancora spazio di indirizzamento sufficiente 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. A seconda del tuo caso d'uso specifico, potresti comunque preferire un altro modello in base ai vantaggi e agli svantaggi di ciascun modello. Spesso, più modelli sono fattibili e puoi scegliere l'approccio più adatto alla tua organizzazione.

Esistono rari casi in cui 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 Utilizzo di istanze multi-NIC per nascondere gli indirizzi del cluster.

Emulare 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 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 imitano vari modelli di rete alternativi su GKE. Questi pattern di architettura alternativi creano una modalità di funzionamento per GKE simile al modello di rete in modalità isolata 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 Google Cloud assegnino indirizzi IP pod instradabili in tutto il Google Cloud deployment.
  • Impedisci l'instradamento di questi indirizzi IP senza NAT a risorse on-premise o ad altri ambienti cloud tramite Cloud VPN o Cloud Interconnect.

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

Anziché utilizzare lo spazio di indirizzi IP di classe E/RFC 5735, puoi utilizzare indirizzi IP RFC 1918 o un insieme interno di indirizzi IP non RFC 1918. Se utilizzi uno di questi altri set 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 ci sia mai comunicazione tra i cluster che utilizzano questi indirizzi e le applicazioni on-premise che utilizzano gli stessi indirizzi.

I seguenti passaggi 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 Classe E/RFC 5735, dallo spazio RFC 1918 o da un insieme interno di indirizzi IP non RFC 1918. In genere, viene utilizzato lo spazio di classe E/RFC 5735.
  2. Utilizza route personalizzate annunciate e rimuovi l'intervallo di indirizzi IP del pod dagli annunci sui tuoi router Cloud. La rimozione di questi indirizzi contribuisce a garantire che gli intervalli IP dei pod non vengano annunciati tramite Border Gateway Protocol (BGP) ai router on-premise.
  3. Crea il cluster GKE utilizzando l'intervallo di indirizzi IP secondari come Classless Inter-Domain Routing (CIDR) per il pod. Puoi utilizzare le strategie descritte in Ridurre l'utilizzo di indirizzi IP interni in GKE per ridurre l'utilizzo di indirizzi IP.
  4. Aggiungi i seguenti indirizzi IP all'elenco nonMasqueradeCIDRs nell'agente di mascheramento:

    • 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 di indirizzi IP primari 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 configurare questo pattern, configuri i cluster in modo che abbiano i seguenti comportamenti:

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

Per fare in modo che questo pattern alternativo emuli completamente il modello di rete in modalità isolata, devi modificare l'elenco nonMasqueradeCIDRs nell'agente di mascheramento in modo che contenga solo gli intervalli di indirizzi IP del nodo e del pod del cluster. La creazione di un elenco di questo tipo comporta sempre la mascheratura del traffico al di fuori 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 dell'occultamento dell'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 all'interno di Google Cloud possono comunicare direttamente tra loro, anche tra cluster. Questa comunicazione tra pod è simile al modello GKE. Tieni presente che il diagramma mostra anche i pod che utilizzano indirizzi nello spazio Classe E/RFC 5735.

Per il traffico inviato al di fuori dei cluster, il diagramma mostra come viene applicato il source NAT (SNAT) a questo 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 è 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 firewall e raccogliendo dati di telemetria in base agli indirizzi IP dei pod. Inoltre, puoi connetterti direttamente ai pod per il debug da Google Cloud.
  • Puoi comunque utilizzare i service mesh multicluster con gli 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.
  • Potresti dover gestire due diversi insiemi di regole firewall: uno per il traffico tra le reti on-premise e uno per il traffico completamente all'interno di Google Cloud.
  • Non puoi avere una comunicazione diretta da pod a pod in mesh di servizi multicluster che si estendono sia a Google Cloud sia al tuo ambiente on-premise o di altri fornitori di servizi cloud. Quando utilizzi Istio, ad esempio, tutta la comunicazione deve avvenire tra i gateway Istio.

Nascondere gli indirizzi IP dei pod utilizzando Private Service Connect

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

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

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

I seguenti passaggi descrivono come configurare questo pattern di architettura:

  1. In una rete VPC separata, crea un cluster GKE. La rete VPC deve contenere solo quel cluster.
  2. Per ogni servizio GKE nel cluster che deve essere accessibile da altri cluster o applicazioni in un'altra rete VPC, crea un bilanciatore del carico di rete pass-through interno con Private Service Connect.
  3. (Facoltativo) Se il cluster GKE deve comunicare in uscita con alcune applicazioni nella rete aziendale, esponi queste applicazioni pubblicando i servizi tramite Private Service Connect.

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

Diagramma di rete che mostra l'implementazione dell'occultamento dell'indirizzo IP 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, la comunicazione consentita avviene tramite endpoint Private Service Connect anziché tramite indirizzi IP pubblici. 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 può condividere lo stesso spazio di indirizzi IP. Solo i pod all'interno di un cluster possono comunicare direttamente tra loro.

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 dalproducer di servizio nella rete VPC del cluster. Anche la comunicazione tra i cluster passa attraverso un endpoint Private Service Connect e un service attachment di un producer di servizi.

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

  • Non devi pianificare gli indirizzi IP perché lo spazio degli indirizzi IP del cluster GKE è nascosto al resto della rete. Questo approccio espone solo un singolo indirizzo IP per servizio alla rete VPC di consumo.
  • Proteggere il cluster è più semplice perché questo modello definisce chiaramente quali servizi sono esposti e solo questi 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 (quando hanno connettività internet) o con le API di Google (utilizzando l'accesso privato Google). Se i servizi esterni al cluster vengono esposti tramite Private Service Connect, anche i pod possono raggiungere questi servizi. Tuttavia, non tutti i fornitori di servizi interni creano collegamenti ai servizi. Pertanto, l'utilizzo di Private Service Connect funziona solo se il numero di questi servizi è limitato ai provider che forniscono allegati.
  • Gli endpoint sono raggiungibili solo dalla stessa regione in cui si trova il servizio. Inoltre, questi endpoint possono essere raggiunti solo dalla rete VPC connessa, non dalle reti VPC con peering o dalle reti connesse tramite Cloud VPN o Cloud Interconnect.

Nascondere gli indirizzi IP dei pod utilizzando Cloud VPN

Questo pattern di architettura utilizza Cloud VPN per creare una separazione tra i cluster GKE e la rete VPC principale. Quando crei questa separazione, la rete risultante funziona in modo simile al modello di rete in modalità isolata. Come il modello in modalità isolata, questo pattern offre il vantaggio di riutilizzare gli intervalli di indirizzi IP di pod e servizi tra i cluster. Il riutilizzo è possibile perché la comunicazione con le applicazioni al di fuori del 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 seguenti passaggi 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. Dimensiona questi intervalli di indirizzi IP in base alle esigenze del cluster GKE più grande che prevedi di utilizzare. Riserva ciascuno di questi intervalli per l'uso esclusivo in GKE. Riutilizzi questi intervalli per tutti i cluster GKE della tua organizzazione.

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

  2. Per il cluster che hai appena creato, configura l'elenco nonMasqueradeCIDRs nell'agente di mascheramento con un elenco contenente gli intervalli di indirizzi IP dei nodi e dei pod del cluster. Questo elenco fa sì che GKE mascheri sempre il traffico in uscita dal cluster con l'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 esistente (principale).

  4. Utilizza route pubblicizzate 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 ogni nodo.

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

  7. Se hai altre reti connesse alla tua rete VPC principale tramite il peering di rete VPC, esporta 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 dell'occultamento dell'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à isolata. Come mostrato nel diagramma, ogni cluster GKE ha la propria rete VPC separata. Ogni rete ha uno spazio di indirizzi IP dei nodi distinto, ma utilizza lo stesso spazio di indirizzi IP dei 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 cluster.

Nel diagramma, nota che solo i pod all'interno di un cluster possono comunicare direttamente tra loro. Il nodo utilizza SNAT per mascherare lo spazio degli indirizzi IP del pod quando comunica all'esterno del cluster con un altro cluster, con la rete aziendale o con una rete on-premise connessa. I pod non sono raggiungibili 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à isolata, puoi riutilizzare gli intervalli di indirizzi IP di pod e servizi tra i cluster.
  • I firewall potrebbero richiedere meno configurazione perché gli indirizzi IP dei pod non sono 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 presenta i seguenti svantaggi:

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 pattern di architettura che assomiglia a un modello di rete in modalità isolata ma tramite l'utilizzo 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 la separazione tra il cluster GKE e la rete principale.

I seguenti passaggi 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. Dimensiona questi intervalli di indirizzi IP in base alle esigenze del cluster GKE più grande che prevedi di utilizzare. Riserva ciascuno di questi intervalli per l'uso esclusivo in GKE. Riutilizzi questi intervalli per tutti i cluster GKE della tua organizzazione.

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

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

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

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

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

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

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

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

Solo i pod all'interno di un cluster possono comunicare direttamente tra loro. Il nodo utilizza SNAT per mascherare lo spazio IP del pod quando comunica al di fuori del cluster con un altro cluster, con la rete aziendale o con una rete on-premise connessa. Non è possibile raggiungere i pod 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 comporta 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 perché il peering non richiede i gateway e l'elaborazione necessari per Cloud VPN.

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

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

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

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

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

Puoi utilizzare questo pattern quando devi ispezionare, trasformare o filtrare 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 con più NIC per nascondere gli indirizzi del cluster presenta i seguenti vantaggi:

  • Lo spazio di indirizzi IP del cluster GKE è nascosto al resto della rete. Solo un singolo indirizzo IP per servizio viene esposto alla rete VPC consumer.
  • I servizi sono raggiungibili a livello globale, dalle reti on-premise connesse e dalle reti in peering.

Tuttavia, l'utilizzo di istanze con più interfacce di rete 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 con più NIC.
  • Le istanze con più 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