Pianificazione degli indirizzi IP

Questa guida fornisce una panoramica della pianificazione degli indirizzi IP per gli ambienti air-gap di Google Distributed Cloud (GDC). Una gestione efficace degli indirizzi IP è fondamentale per il deployment, il funzionamento e lo scaling riusciti della tua soluzione GDC air-gapped.

Questo documento è destinato a:

• Operatori di infrastruttura (IO): persone o team responsabili della pianificazione, dell'implementazione e del funzionamento complessivi di una zona air-gap GDC, inclusa l'infrastruttura di rete sottostante e la creazione di organizzazioni tenant.

Panoramica del prodotto

Google Distributed Cloud (GDC) con air gap è una soluzione hardware e software integrata che ti consente di eseguire tecnologie cloud in ambienti con rigide restrizioni di sicurezza o sovranità, completamente disconnessi dai cloud pubblici. GDC 1.14 introduce miglioramenti significativi alla progettazione e al networking dei cluster, tra cui un singolo cluster di infrastruttura per organizzazione e funzionalità avanzate di networking Virtual Private Cloud (VPC).

Una pianificazione accurata degli indirizzi IP è essenziale in GDC air-gap per quanto segue:

• Isolamento:corretta segmentazione della rete tra tenant (organizzazioni) diversi e tra piani di gestione e dati.
• Scalabilità:spazio di indirizzi IP sufficiente per i carichi di lavoro attuali e futuri, tra cui VM, container e servizi.
• Connettività:routing e raggiungibilità corretti per tutti i componenti all'interno dell'ambiente air-gap di GDC e per le reti esterne, se necessario.
• Conformità: rispetto di schemi di indirizzamento di rete specifici o limitazioni imposte dal tuo ambiente.

L'architettura GDC utilizza istanze Virtual Routing and Forwarding (VRF) per ottenere l'isolamento e la segmentazione della rete. Comprendere quali spazi di indirizzi IP sono gestiti dall'IO rispetto al PA è fondamentale per una pianificazione efficace.

Pianificazione IP della zona

In qualità di operatore dell'infrastruttura, sei responsabile della pianificazione dello spazio di indirizzi IP di base per l'intera zona air-gap di GDC. Sono incluse le reti per l'infrastruttura di base della zona, i servizi condivisi e i segmenti di rete iniziali necessari per avviare nuove organizzazioni.

Reti di infrastrutture di zona

Le reti dell'infrastruttura di zona vengono sottoposte a provisioning dall'IO durante il bootstrap iniziale della zona e sono fondamentali per il funzionamento dell'ambiente air-gap di GDC. Il loro indirizzamento deve essere univoco a livello globale all'interno dell'universo air-gap di GDC e in genere utilizza lo spazio di indirizzi privati RFC 1918. Queste reti diventano riservate a livello globale e non possono essere utilizzate da nessuna rete dell'organizzazione tenant.

Per il riferimento/le specifiche complete, consulta il modello di raccolta dei requisiti .

Questi indirizzi IP vengono forniti dall'IO durante il bootstrapping di una zona utilizzando il questionario di acquisizione dei clienti (CIQ) e altri passaggi di bootstrap della zona.

Reti di infrastrutture dell'organizzazione

Quando un IO crea una nuova organizzazione, vengono forniti alcuni servizi di rete di base. Fanno parte dello spazio di indirizzi dell'infrastruttura air-gap di GDC e devono essere univoci a livello globale. Gli indirizzi vengono allocati automaticamente dalla rete dell'infrastruttura di zona fornita al bootstrap della zona. Gli amministratori e gli utenti di un'organizzazione non sono a conoscenza di queste reti.

Pianificazione IP dell'organizzazione

Quando crea un'organizzazione, l'IO deve collaborare con il PA per pianificare l'indirizzamento IP dell'organizzazione nell'ambito della procedura del questionario di input dell'organizzazione (OIQ). Questi CIDR vengono utilizzati per eseguire il bootstrap del cluster di infrastruttura dell'organizzazione in ogni zona e non devono sovrapporsi tra loro o a qualsiasi rete riservata a livello globale, come le reti di infrastruttura di zona. Zona Le reti dell'infrastruttura possono essere recuperate da CIQ o eseguendo query sul cluster di amministrazione root.

Per informazioni dettagliate sui vincoli, consulta il modello di raccolta dei requisiti.

Questi dettagli vengono raccolti dall'amministratore dell'account dall'IO e utilizzati per il provisioning dell'organizzazione. I campi chiave di OIQ correlati alla pianificazione degli indirizzi IP per le organizzazioni sono i seguenti:

• infraVPCCIDR:
  • Descrizione: utilizzato per i carichi di lavoro di sistema all'interno dell'organizzazione, inclusi la console dell'organizzazione, le API di gestione e i servizi proprietari.
  • Nome subnet radice globale: infra-vpc-root-cidr
  • Server API globale: root globale
• defaultVPCCIDR
  • Descrizione: utilizzato per i workload utente all'interno dell'organizzazione, incluse VM utente, CIDR pod e nodi del cluster Kubernetes.
  • Nome subnet radice globale: default-vpc-root-cidr
  • Global API Server (Server API globale): Global Org API
• orgAdminExternalCIDR:
  • Descrizione: per i workload e gli endpoint nel cluster perimetrale che gestiscono il traffico amministrativo tra le reti esterne e l'organizzazione.
  • Nome subnet radice globale: admin-external-root-cidr
  • Server API globale: root globale
• orgDataExternalCIDR:
  • Descrizione: per carichi di lavoro ed endpoint raggiungibili esternamente dagli utenti, ad esempio bilanciatori del carico esterni e NAT in uscita.
  • Nome subnet radice globale: data-external-root-cidr
  • Server API globale: root globale

Procedura di pianificazione

Il processo di pianificazione e provisioning di alto livello dell'indirizzamento di rete di un'organizzazione è il seguente:

1. Collabora con gli amministratori di progetto per definire i CIDR:collabora con gli amministratori di progetto dell'organizzazione per determinare blocchi CIDR non sovrapposti appropriati per il VPC dell'infrastruttura, il VPC predefinito, il segmento di rete dell'amministratore dell'organizzazione e il segmento di rete dei dati dell'organizzazione.

2. Crea subnet globali nel server API di amministrazione root globale:crea risorse Subnet (infra-vpc-root-cidr, admin-external-root-cidr, data-external-root-cidr) nello spazio dei nomi dell'organizzazione sul server API di amministrazione root globale utilizzando i CIDR definiti.

3. Dividi le subnet root per le zone:queste subnet root globali vengono poi divise automaticamente o manualmente in subnet più piccole per ogni zona da utilizzare.

   • Divisione automatica:per impostazione predefinita, un controller divide automaticamente la subnet root globale.
   • Suddivisione manuale:se è necessario il controllo manuale dell'allocazione CIDR zonale, imposta l'annotazione ipam.gdc.goog/pause-auto-division: true sulle risorse Subnet e definisci manualmente le subnet zonali.

Per la procedura più dettagliata per creare queste subnet e l'organizzazione, consulta Creare un'organizzazione cliente.

Modello di raccolta dei requisiti

Questa sezione fornisce un modello delle informazioni sull'indirizzamento IP che gli operatori dell'infrastruttura devono raccogliere per il bootstrap della zona e dell'organizzazione.

Bootstrap della zona

Prima di iniziare il bootstrap della zona, gli IO devono avere i seguenti indirizzi IP AttachmentGroup.

Dettagli subnet		Dimensionamento della subnet		Note/vincoli
Nome	IPv6 Supp.	Min	Rec
OOBMgmtCIDR Facoltativo Espandibile	No	/19 per zona	-	Utilizzato in una singola zona DEVE essere univoco in tutte le zone di un universo DEVE essere univoco in tutte le reti con peering esterno Diventa riservato a livello globale e inutilizzabile da qualsiasi organizzazione
ZoneInfraCIDR Facoltativo Non espandibile nella versione 1.14	Sì	/16 per zona	-	Utilizzato in una singola zona DEVE essere univoco in tutte le zone di un universo DEVE essere univoco in tutte le reti con peering esterno Diventa riservato a livello globale e inutilizzabile da qualsiasi organizzazione Se non viene fornito, il valore predefinito è 172.17+{zoneID}.0/16
ZoneInfraAnycastCIDR Obbligatorio Espandibile	Sì	/24 per universo	-	Utilizzato in tutte le zone DEVE essere univoco in tutte le zone di un universo DEVE essere univoco in tutte le reti con peering esterno Diventa riservato a livello globale e inutilizzabile da qualsiasi organizzazione

Bootstrap dell'organizzazione

Prima di iniziare il provisioning di un'organizzazione, gli IO devono collaborare con i PA di onboarding per pianificare le seguenti informazioni sull'indirizzamento IP.

Importante :i seguenti consigli per il dimensionamento offrono uno spazio ragionevole per la crescita senza la necessità di allocare IP aggiuntivi all'inizio del ciclo di vita dell'organizzazione.

Dettagli subnet		Dimensionamento della subnet		Note/vincoli
Nome	IPv6 Supp.	Min	Rec
defaultVPCCIDR Obbligatorio Espandibile	Sì	/16 per zona	/16 per zona	Utilizzato in più zone DEVE essere univoco all'interno dell'organizzazione globale in tutte le zone Può sempre sovrapporsi ad altre organizzazioni NON DEVE utilizzare subnet riservate a livello globale
infraVPCCIDR Obbligatorio Espandibile	Sì	/16 per zona	/16 per zona	Utilizzato in più zone DEVE essere univoco all'interno dell'organizzazione globale in tutte le zone Può sempre sovrapporsi ad altre organizzazioni NON DEVE utilizzare subnet riservate a livello globale
orgAdminExternalCIDR Obbligatorio Espandibile	Sì	/26 per zona	/26 per zona	NON DEVE utilizzare alcuna subnet riservata a livello globale Utilizzata in una singola zona DEVE essere univoca all'interno dell'organizzazione globale in tutte le zone DEVE essere univoca in tutte le reti con peering esterno NON DEVE utilizzare alcuna subnet riservata a livello globale
orgAdminAnycastCIDR Obbligatorio Espandibile	Sì	/28 per universo	/28 per universo	NON DEVE utilizzare alcuna subnet riservata a livello globale Utilizzata in più zone DEVE essere univoca all'interno dell'organizzazione globale in tutte le zone DEVE essere univoca in tutte le reti con peering esterno NON DEVE utilizzare alcuna subnet riservata a livello globale
orgDataExternalCIDR Obbligatorio Espandibile	Sì	/26 per zona	/23 per zona	NON DEVE utilizzare subnet riservate a livello globaleUtilizzate in una singola zona DEVE essere univoco all'interno dell'organizzazione globale in tutte le zone DEVE essere univoco in tutte le reti in peering esterno NON DEVE utilizzare subnet riservate a livello globale
orgDataAnycastCIDR Obbligatorio Espandibile	Sì	/28 per universo	/26 per universo	NON DEVE utilizzare subnet riservate a livello globale Utilizzate in più zone DEVE essere univoco all'interno dell'organizzazione globale in tutte le zone DEVE essere univoco in tutte le reti con peering esterno NON DEVE utilizzare subnet riservate a livello globale

Esempi

I seguenti diagrammi illustrano come i concetti di pianificazione degli indirizzi IP descritti in questo documento si applicano a scenari air-gap GDC comuni.

Esempio 1: bootstrap della zona

Esempio 2: onboarding dell'organizzazione con interconnessione condivisa

Esempio 3: onboarding dell'organizzazione con interconnessioni dedicate

Concetti chiave e best practice

• Isolamento VRF: i VRF sono fondamentali per la segmentazione di rete in GDC air-gapped. Comprendi lo scopo di ogni VRF (Zone Infra, Org Infra, Org Admin, Org Data e così via) per pianificare gli spazi di indirizzi IP che mantengono i confini di isolamento necessari.
• IP sovrapposti e non sovrapposti:
  • Spazio di indirizzi dell'infrastruttura GDCag (gestito da IO): deve essere univoco a livello globale nell'intero deployment air-gapped di GDC (tutte le zone, tutte le organizzazioni). Questo spazio di indirizzi diventa essenzialmente riservato a livello globale.
  • Spazio di indirizzi dell'organizzazione (gestito/definito da PA):
    • Reti VPC (VPC dell'infrastruttura, VPC predefinito): possono sovrapporsi tra organizzazioni diverse, ma devono essere univoche all'interno di un'organizzazione in tutte le relative zone e univoche rispetto a qualsiasi rete con cui sono in peering.
    • VRF di amministrazione/dati dell'organizzazione:possono sovrapporsi tra diverse organizzazioni se queste utilizzano gruppi di collegamenti di interconnessione separati. Se condividono un gruppo di allegati, gli indirizzi IP devono essere univoci. Deve essere univoco all'interno della stessa organizzazione in tutte le relative zone e univoco rispetto a qualsiasi rete con cui esegue il peering.
• Dimensioni CIDR consigliate:rispetta le lunghezze del prefisso CIDR consigliate specifiche per ogni segmento di rete per avere spazio di indirizzamento sufficiente per i componenti di sistema e la crescita futura.
• Preferenza RFC 1918:sebbene gli indirizzi IP pubblici possano essere utilizzati nella maggior parte degli spazi gestiti da PA se la zona non si connette a internet, gli indirizzi privati RFC 1918 sono generalmente consigliati per le reti interne GDC air-gapped.
• Accuratezza della richiesta di informazioni all'intermediario (OIQ): le informazioni fornite nella richiesta di informazioni al cliente (CIQ) (per gli intermediari) e nella richiesta di informazioni all'intermediario (OIQ) (per i clienti che si rivolgono agli intermediari) sono fondamentali. Intervalli di indirizzi IP imprecisi o pianificati male possono portare a notevoli difficoltà di implementazione.
• Multi-zona:
  • Per gli IO: i VRF dell'infrastruttura di zona sono per zona.
  • Per i PA: i VPC dell'organizzazione (infrastruttura e predefinito) e i segmenti di rete di dati dell'organizzazione sono concettualmente a livello di organizzazione, ma richiedono allocazioni IP univoche per zona che non si sovrappongono all'interno di questa organizzazione globale. Le subnet globali sono suddivise per fornire intervalli univoci per zona per una determinata organizzazione.

Supportabilità, diagnosi, risoluzione dei problemi e domande frequenti

• Errori comuni:
  • Blocchi CIDR di dimensioni insufficienti, che portano all'esaurimento degli indirizzi IP.
  • Intervalli IP sovrapposti in cui è richiesta l'unicità. Ad esempio, reti di infrastruttura gestite da IO o all'interno di VPC e VRF esterni di una singola organizzazione in più zone.
  • Incomprensione di quale entità (IO o PA) sia responsabile della pianificazione di intervalli IP specifici.
  • Intervalli CIDR in conflitto con zone-infra-cidr o con le reti in peering.
• Verifica (di alto livello):
  • iOS:può verificare le risorse CIDRClaim nel cluster di amministrazione principale e le risorse Subnet nel server API di amministrazione principale globale.
  • PA:possono coordinarsi con gli IO per comprendere gli intervalli IP allocati all'infrastruttura e ai VPC della loro organizzazione. Le risorse Subnet per il VPC predefinito possono essere controllate nel server API dell'organizzazione globale.
• Domande frequenti:
  • D: Posso modificare i CIDR IP dopo il deployment?
    • R. La modifica degli intervalli IP dell'infrastruttura di base dopo il deployment è complessa e potrebbe richiedere un notevole impegno o un nuovo deployment. I CIDR rivolti ai clienti (ad es. per VPC predefinito, amministratore dell'organizzazione e segmenti di rete di dati dell'organizzazione) sono progettati per essere modificabili dopo la creazione, ma le modifiche richiedono un'attenta pianificazione e coordinamento.
  • D: Dove posso definire gli IP per i bilanciatori del carico o il NAT in uscita della mia applicazione?
    • R: In genere vengono allocati dal CIDR VRF dei dati dell'organizzazione, che viene pianificato dal PA e fornito all'IO durante la creazione dell'organizzazione.
  • D: Che cos'è zone-infra-cidr e perché i CIDR OIQ non possono sovrapporsi?
    • R: L'zone-infra-cidr è un intervallo IP di base per i componenti dell'infrastruttura interna della zona. La sovrapposizione causerebbe conflitti di routing e instabilità.

Per le procedure dettagliate sulla creazione di organizzazioni e sulla configurazione di subnet, gli IO devono consultare la documentazione Creare un'organizzazione cliente.