Planung von IP-Adressen

Dieser Leitfaden bietet einen Überblick über die Planung von IP-Adressen für Google Distributed Cloud (GDC)-Umgebungen mit Air Gap. Eine effektive Verwaltung von IP-Adressen ist entscheidend für die erfolgreiche Bereitstellung, den Betrieb und die Skalierung Ihrer GDC-Air-Gap-Lösung.

Dieses Dokument richtet sich an:

• Infrastructure Operators (IOs): Einzelpersonen oder Teams, die für die allgemeine Planung, Bereitstellung und den Betrieb einer GDC-Airgap-Zone verantwortlich sind, einschließlich der zugrunde liegenden Netzwerkinfrastruktur und der Erstellung von Mandantenorganisationen.

Produktübersicht

Google Distributed Cloud (GDC) mit Air Gap ist eine integrierte Hardware- und Softwarelösung, mit der Sie Cloud-Technologien in Umgebungen mit strengen Sicherheits- oder Souveränitätsbeschränkungen ausführen können, die vollständig von öffentlichen Clouds getrennt sind. Mit GDC 1.14 werden erhebliche Verbesserungen am Clusterdesign und an der Vernetzung eingeführt, darunter ein einzelner Infrastrukturcluster pro Organisation und erweiterte VPC-Netzwerkfunktionen (Virtual Private Cloud).

Eine sorgfältige IP-Adressplanung ist in GDC Air-Gapped für Folgendes unerlässlich:

• Isolation:Richtige Netzwerksegmentierung zwischen verschiedenen Mandanten (Organisationen) und zwischen Verwaltungs- und Datenebenen.
• Skalierbarkeit:Ausreichend IP-Adressraum für aktuelle und zukünftige Arbeitslasten, einschließlich VMs, Containern und Diensten.
• Konnektivität:Korrektes Routing und Erreichbarkeit für alle Komponenten in der GDC-Air-Gap-Umgebung und für externe Netzwerke nach Bedarf.
• Compliance:Einhaltung bestimmter Netzwerkadressierungsschemata oder Einschränkungen, die von Ihrer Umgebung vorgeschrieben werden.

In der GDC-Architektur werden VRF-Instanzen (Virtual Routing and Forwarding) verwendet, um Netzwerkisolation und ‑segmentierung zu erreichen. Es ist wichtig, zu wissen, welche IP-Adressbereiche vom IO und welche vom PA verwaltet werden, um eine erfolgreiche Planung zu ermöglichen.

Planung von Zonen-IPs

Als Infrastrukturbetreiber sind Sie für die Planung des grundlegenden IP-Adressbereichs für die gesamte GDC-Airgap-Zone verantwortlich. Dazu gehören Netzwerke für die Kerninfrastruktur der Zone, freigegebene Dienste und die ersten Netzwerksegmente, die zum Bootstrapping neuer Organisationen erforderlich sind.

Zoneninfrastrukturnetzwerke

Zoneninfrastrukturnetzwerke werden vom IO während des ersten Zonen-Bootstraps bereitgestellt und sind für die Funktion der GDC-Air-Gap-Umgebung von entscheidender Bedeutung. Ihre Adressierung muss im GDC-Air-Gap-Universum global eindeutig sein und verwendet in der Regel den privaten RFC 1918-Adressbereich. Diese Netzwerke werden global reserviert und können nicht von Netzwerken von Mandantenorganisationen verwendet werden.

Eine vollständige Referenz/Spezifikation finden Sie in der Vorlage für die Anforderungserfassung .

Diese IP-Adressen werden vom IO beim Bootstrapping einer Zone mithilfe des CIQ (Customer Intake Questionnaire) und anderer Schritte zum Bootstrapping von Zonen bereitgestellt.

Netzwerke der Organisationsinfrastruktur

Wenn ein IO eine neue Organisation erstellt, werden bestimmte grundlegende Netzwerke bereitgestellt. Sie sind Teil des Adressbereichs der GDC-Infrastruktur ohne Internetverbindung und müssen global eindeutig sein. Die Adressen werden automatisch aus dem Zoneninfrastrukturnetzwerk zugewiesen, das beim Zonen-Bootstrap angegeben wird. Administratoren und Nutzer einer Organisation sind sich dieser Netzwerke nicht bewusst.

Planung von Organisations-IPs

Bei der Erstellung einer Organisation muss der IO mit dem PA zusammenarbeiten, um die IP-Adressierung der Organisation im Rahmen des Prozesses für den Fragebogen zur Organisationseingabe (Organization Input Questionnaire, OIQ) zu planen. Diese CIDRs werden verwendet, um den Infrastrukturcluster der Organisation in jeder Zone zu booten. Sie dürfen sich nicht gegenseitig oder mit einem global reservierten Netzwerk wie Zone Infrastructure-Netzwerken überschneiden. Zone Infrastrukturnetzwerke können aus dem CIQ oder durch Abfragen des Root-Administratorclusters abgerufen werden.

Ausführliche Informationen zu Einschränkungen finden Sie in der Vorlage für die Erfassung von Anforderungen.

Diese Informationen werden von der PA vom IO erhoben und zum Bereitstellen der Organisation verwendet. Die wichtigsten OIQ-Felder im Zusammenhang mit der Planung von IP-Adressen für Organisationen sind die folgenden:

• infraVPCCIDR:
  • Beschreibung: Wird für Systemarbeitslasten innerhalb der Organisation verwendet, einschließlich der Organisationskonsole, Verwaltungs-APIs und First-Party-Dienste.
  • Name des globalen Stamm-Subnetzes: infra-vpc-root-cidr
  • Global API Server (Globaler API-Server): Global root (Globaler Stamm)
• defaultVPCCIDR
  • Beschreibung: Wird für Nutzerarbeitslasten in der Organisation verwendet, einschließlich Nutzer-VMs, Pod-CIDRs und Kubernetes-Clusterknoten.
  • Name des globalen Stamm-Subnetzes: default-vpc-root-cidr
  • Global API Server (Globaler API-Server): Global Org API
• orgAdminExternalCIDR:
  • Beschreibung: Für Arbeitslasten und Endpunkte im Perimeter-Cluster, die administrativen Traffic zwischen externen Netzwerken und der Organisation verarbeiten.
  • Name des globalen Stamm-Subnetzes: admin-external-root-cidr
  • Global API Server (Globaler API-Server): Global root (Globaler Stamm)
• orgDataExternalCIDR:
  • Beschreibung: Für Arbeitslasten und Endpunkte, die für Nutzer extern erreichbar sind, z. B. externe Load Balancer und NATs für ausgehenden Traffic.
  • Name des globalen Stamm-Subnetzes: data-external-root-cidr
  • Global API Server (Globaler API-Server): Global root (Globaler Stamm)

Planungsprozess

Der allgemeine Prozess für die Planung und Bereitstellung der Netzwerkadressierung einer Organisation sieht so aus:

1. Mit PAs zusammenarbeiten, um CIDRs zu definieren:Arbeiten Sie mit den PAs der Organisation zusammen, um geeignete, nicht überlappende CIDR-Blöcke für die Infra-VPC, die Standard-VPC, das Netzwerksegment des Organisationsadministrators und das Netzwerksegment der Organisationsdaten zu bestimmen.

2. Globale Subnetze auf dem globalen Root-Admin-API-Server erstellen:Erstellen Sie Subnet-Ressourcen (infra-vpc-root-cidr, admin-external-root-cidr, data-external-root-cidr) im Namespace der Organisation auf dem globalen Root-Admin-API-Server mit den definierten CIDRs.

3. Aufteilen von Root-Subnetzen für Zonen:Diese globalen Root-Subnetze werden dann automatisch oder manuell in kleinere Subnetze für jede Zone aufgeteilt.

   • Automatische Aufteilung:Standardmäßig teilt ein Controller das globale Stamm-Subnetz automatisch auf.
   • Manuelle Aufteilung:Wenn eine manuelle Steuerung der zonalen CIDR-Zuweisung erforderlich ist, legen Sie die Annotation ipam.gdc.goog/pause-auto-division: true für die Subnet-Ressourcen fest und definieren Sie die zonalen Subnetze manuell.

Eine detailliertere Anleitung zum Erstellen dieser Subnetze und der Organisation finden Sie unter Kundenorganisation erstellen.

Vorlage für die Anforderungserfassung

Dieser Abschnitt enthält eine Vorlage der IP-Adressierungsinformationen, die Infrastrukturbetreiber (Infrastructure Operators, IOs) für das Bootstrapping von Zonen und Organisationen benötigen.

Zonen-Bootstrap

Vor dem Starten von Zone Bootstrap sollten IOs die folgenden IP-Adressen haben: AttachmentGroup.

Subnetzdetails		Subnetzgröße		Hinweise/Einschränkungen
Name	IPv6-Unterstützung	Min.	Rec
OOBMgmtCIDR Optional Erweiterbar	Nein	/19 pro Zone	-	Wird in einer einzelnen Zone verwendet MUSS in allen Zonen eines Universums eindeutig sein MUSS in allen externen Peering-Netzwerken eindeutig sein Wird global reserviert und kann von keiner Organisation verwendet werden
ZoneInfraCIDR Optional Not Expandable in 1.14	Ja	/16 pro Zone	-	Wird in einer einzelnen Zone verwendet MUSS für alle Zonen in einem Universum eindeutig sein MUSS für alle externen Peering-Netzwerke eindeutig sein Wird global reserviert und kann von keiner Organisation verwendet werden Wenn nicht angegeben, wird standardmäßig 172.17+{zoneID}.0/16 verwendet.
ZoneInfraAnycastCIDR Erforderlich Erweiterbar	Ja	/24 pro Universum	-	Wird in allen Zonen verwendet MUSS in allen Zonen eines Universums eindeutig sein MUSS in allen externen Peering-Netzwerken eindeutig sein Wird global reserviert und kann von keiner Organisation verwendet werden

Organisation bootstrappen

Bevor Sie mit der Bereitstellung einer Organisation beginnen, sollten IOs mit den Onboarding-PAs zusammenarbeiten, um die folgenden IP-Adressierungsinformationen zu planen.

Wichtig :Die folgenden Empfehlungen zur Dimensionierung bieten ausreichend Spielraum für Wachstum, ohne dass zusätzliche IPs frühzeitig im Lebenszyklus der Organisation zugewiesen werden müssen.

Subnetzdetails		Subnetzgröße		Hinweise/Einschränkungen
Name	IPv6-Unterstützung	Min.	Rec
defaultVPCCIDR Erforderlich Erweiterbar	Ja	/16 pro Zone	/16 pro Zone	Wird in mehreren Zonen verwendet MUSS innerhalb der globalen Organisation in allen Zonen eindeutig sein Kann sich immer mit anderen Organisationen überschneiden DARF NICHT global reservierte Subnetze verwenden
infraVPCCIDR Erforderlich Erweiterbar	Ja	/16 pro Zone	/16 pro Zone	Wird in mehreren Zonen verwendet MUSS innerhalb der globalen Organisation in allen Zonen eindeutig sein Kann sich immer mit anderen Organisationen überschneiden DARF NICHT global reservierte Subnetze verwenden
orgAdminExternalCIDR Erforderlich Erweiterbar	Ja	/26 pro Zone	/26 pro Zone	NICHT global reservierte Subnetze verwenden Wird in einer einzelnen Zone verwendet MUSS innerhalb der globalen Organisation über alle Zonen hinweg eindeutig sein MUSS über alle externen Peering-Netzwerke hinweg eindeutig sein NICHT global reservierte Subnetze verwenden
orgAdminAnycastCIDR Erforderlich Erweiterbar	Ja	/28 pro Universum	/28 pro Universum	NICHT global reservierte Subnetze verwenden Wird in mehreren Zonen verwendet MUSS innerhalb der globalen Organisation in allen Zonen eindeutig sein MUSS in allen externen Peering-Netzwerken eindeutig sein NICHT global reservierte Subnetze verwenden
orgDataExternalCIDR Erforderlich Erweiterbar	Ja	/26 pro Zone	/23 pro Zone	NICHT verwenden. Wird in einer einzelnen Zone verwendet MUSS innerhalb der globalen Organisation über alle Zonen hinweg eindeutig sein MUSS über alle externen Peering-Netzwerke hinweg eindeutig sein NICHT verwenden.
orgDataAnycastCIDR Erforderlich Erweiterbar	Ja	/28 pro Universum	/26 pro Universum	NICHT global reservierte Subnetze verwenden In mehreren Zonen verwendet MUSS innerhalb der globalen Organisation in allen Zonen eindeutig sein MUSS in allen externen Peering-Netzwerken eindeutig sein NICHT global reservierte Subnetze verwenden

Beispiele

Die folgenden Diagramme veranschaulichen, wie die in diesem Dokument beschriebenen Konzepte für die Planung von IP-Adressen auf häufige GDC-Szenarien ohne Internetverbindung angewendet werden.

Beispiel 1: Zonen-Bootstrap

Beispiel 2: Organisationseinrichtung mit gemeinsam genutzter Interconnect-Verbindung

Beispiel 3: Organisationseinrichtung mit Dedicated Interconnects

Wichtige Konzepte und Best Practices

• VRF-Isolation:VRFs sind für die Netzwerksegmentierung in GDC Air-Gapped von grundlegender Bedeutung. Machen Sie sich mit dem Zweck der einzelnen VRFs (Zone Infra, Org Infra, Org Admin, Org Data usw.) vertraut, um IP-Adressbereiche zu planen, die die erforderlichen Isolationsgrenzen einhalten.
• Sich überschneidende und nicht überschneidende IP-Adressen:
  • GDCag Infrastructure Address Space (IO-managed): Muss im gesamten GDC-Air-Gap-Deployment (alle Zonen, alle Organisationen) global eindeutig sein. Dieser Adressraum wird im Wesentlichen global reserviert.
  • Adressbereich der Organisation (von PA verwaltet/definiert):
    • VPC-Netzwerke (Infra-VPC, Standard-VPC): Können sich zwischen verschiedenen Organisationen überschneiden, müssen aber innerhalb einer Organisation in allen Zonen und in allen Netzwerken, mit denen sie ein Peering durchführen, eindeutig sein.
    • Organisationsadministrator/Data-VRFs:Können sich zwischen verschiedenen Organisationen überschneiden, wenn diese Organisationen separate Interconnect Attachment-Gruppen verwenden. Wenn sie eine Anhangsgruppe gemeinsam nutzen, müssen IP-Adressen eindeutig sein. Muss innerhalb der derselben Organisation in allen Zonen eindeutig sein und sich von allen Netzwerken unterscheiden, mit denen sie ein Peering durchführt.
• Empfohlene CIDR-Größen:Halten Sie sich an die empfohlenen CIDR-Präfixlängen, die für jedes Netzwerksegment angegeben sind, um genügend Adressraum für Systemkomponenten und zukünftiges Wachstum zu haben.
• RFC 1918-Präferenz:Obwohl öffentliche IP-Adressen in den meisten von PA verwalteten Bereichen verwendet werden können, wenn die Zone keine Verbindung zum Internet hat, werden private RFC 1918-Adressen im Allgemeinen für interne GDC-Netzwerke ohne Internetverbindung empfohlen.
• Genauigkeit von OIQ:Die Informationen, die im CIQ (für IOs) und OIQ (für PAs für IOs) bereitgestellt werden, sind entscheidend. Ungenaue oder schlecht geplante IP-Adressbereiche können zu erheblichen Problemen bei der Bereitstellung führen.
• Mehrere Zonen:
  • Für IOs: VRFs für die Zoneninfrastruktur sind zonenbezogen.
  • Für PAs: VPCs der Organisation (Infra und Default) sowie Organisationsadministrator- und Organisationsdatensegmente sind konzeptionell organisationsweit, erfordern jedoch eindeutige IP-Zuweisungen pro Zone, die sich innerhalb dieser globalen Organisation nicht überschneiden. Die globalen Subnetze werden unterteilt, um eindeutige Bereiche pro Zone für eine bestimmte Organisation bereitzustellen.

Support, Diagnose, Fehlerbehebung und häufig gestellte Fragen

• Häufige Stolperfallen:
  • CIDR-Blöcke mit unzureichender Größe, die zu IP-Erschöpfung führen.
  • Überlappende IP-Bereiche, bei denen Eindeutigkeit erforderlich ist. Beispiele sind IO-verwaltete Infrastrukturnetzwerke oder VPCs und externe VRFs einer einzelnen Organisation über Zonen hinweg.
  • Es besteht ein Missverständnis darüber, welche Einheit (IO oder PA) für die Planung bestimmter IP-Bereiche verantwortlich ist.
  • CIDR-Bereiche, die mit dem zone-infra-cidr oder Peering-Netzwerken in Konflikt stehen.
• Überprüfung (allgemein):
  • IOs:Kann CIDRClaim-Ressourcen im Administrator-Stammcluster und Subnet-Ressourcen im globalen Administrator-Stamm-API-Server überprüfen.
  • PAs:Sie können sich mit IOs abstimmen, um die IP-Bereiche zu ermitteln, die der Infrastruktur und den VPCs ihrer Organisation zugewiesen sind. Subnet-Ressourcen für die Standard-VPC können auf dem globalen API-Server der Organisation geprüft werden.
• FAQ:
  • F: Kann ich IP-CIDRs nach dem Deployment ändern?
    • A: Das Ändern von IP-Bereichen der Kerninfrastruktur nach der Bereitstellung ist komplex und kann einen erheblichen Aufwand oder eine erneute Bereitstellung erfordern. Kundenorientierte CIDRs (z. B. für Standard-VPC, Organisationsadministrator und Organisationsdatensegmente) sind so konzipiert, dass sie nach der Erstellung geändert werden können. Änderungen erfordern jedoch eine sorgfältige Planung und Koordination.
  • F: Wo definiere ich IP-Adressen für die Load-Balancer oder das Egress-NAT meiner Anwendung?
    • A: Diese werden in der Regel aus dem CIDR des VRF für Organisationsdaten zugewiesen, das vom PA geplant und dem IO bei der Erstellung der Organisation bereitgestellt wird.
  • F: Was ist die zone-infra-cidr und warum dürfen sich die CIDRs meiner OIQ nicht damit überschneiden?
    • A: Der zone-infra-cidr ist ein grundlegender IP-Bereich für die internen Infrastrukturkomponenten der Zone. Eine Überschneidung würde zu Routingkonflikten und Instabilität führen.

Eine detaillierte Anleitung zum Erstellen von Organisationen und Konfigurieren von Subnetzen finden IOs in der Dokumentation Kundenorganisation erstellen.