Subnetze und IP-Adressen in GDC

Subnetze sind logische Unterteilungen eines IP-Adressnetzwerks, die verwaltbare Segmente für Ihre Dienste bereitstellen. Sie können Subnetze mit bestimmten IP-Adressbereichen definieren oder sie für die dynamische Zuordnung in Google Distributed Cloud (GDC) mit Air Gap konfigurieren.

Dieses Dokument richtet sich an Netzwerkadministratoren in der Gruppe der Plattformadministratoren und Anwendungsentwickler in der Gruppe der Anwendungsoperatoren, die für die Verwaltung des Netzwerkverkehrs für ihre Dienste verantwortlich sind. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Netzwerke in GDC

In einer GDC-Organisation sind zwei verschiedene Netzwerktypen verfügbar, für die Sie IP-Adressen zuweisen können:

• Virtual Private Cloud (VPC): Ein Netzwerk, dem interne IP-Adressen zugewiesen sind, auf die nur Arbeitslasten innerhalb Ihrer Organisation zugreifen können.
• Externes Netzwerksegment: Ein Netzwerk, dem externe IP-Adressen zugewiesen sind, auf die externe Netzwerke zugreifen können, die mit Ihrer Organisation verbunden sind.

Sie können Subnetze innerhalb der einzelnen Netzwerktypen zuweisen, um bestimmte Ziele zu erreichen. Ein Subnetz ist eine logische Unterteilung eines IP-Adressnetzwerks, die durch CIDR-Bereiche (Classless Inter-Domain Routing) definiert wird. Mit CIDR-Bereichen können Sie IP-Adressen und die entsprechenden Netzwerke für einen Dienst darstellen. Jedes Netzwerk innerhalb dieser Netzwerktypen hat einen unabhängigen Subnetzbaum.

Subnetze innerhalb einer VPC sind innerhalb des GDC-Netzwerks zugänglich und können außerhalb von GDC nicht erreicht werden. VPC-Subnetze sind verfügbar, um interne IP-Adressen innerhalb Ihrer Organisation zuzuweisen. Subnetze von Netzwerksegmenten sind für externe Netzwerke zugänglich, die mit einer Organisation verbunden sind. Sie ermöglichen es Ihnen, externe IP-Adressen für Netzwerke außerhalb Ihrer Organisation bereitzustellen.

In jedem Netzwerk werden Subnetze in einer hierarchischen Baumstruktur organisiert, um die logische Unterteilung und Zuweisung von IP-Adressbereichen auf verschiedene Teile des Netzwerks wie Zonen, Dienste oder Arbeitslasten zu ermöglichen. Weitere Informationen finden Sie unter Subnetzhierarchie.

VPC-Netzwerk

Ein VPC-Netzwerk verwendet interne IP-Adressen, auf die nur innerhalb Ihrer Organisation zugegriffen werden kann und die von Netzwerken außerhalb Ihrer Organisation nicht erreicht werden können.

In Ihrer GDC-Umgebung sind zwei VPC-Netzwerke verfügbar:

• Standard-VPC: Eine VPC, der IP-Adressen für interne Arbeitslasten wie Container und virtuelle Maschinen (VMs) innerhalb und über mehrere Zonen hinweg zugewiesen werden.
• Infrastruktur-VPC: Eine systemverwaltete VPC, die Erstanbieter-Dienste von GDC mit Air Gap hostet, z. B. Vertex AI, Observability APIs und die GDC-Konsole. Sie definieren IP-Adressen in dieser VPC nur, wenn Sie die IP-Adressarchitektur Ihrer Organisation planen.

IP-Adressen in der Standard-VPC und der Infrastruktur-VPC dürfen sich innerhalb derselben Organisation nicht überschneiden. Weitere Informationen finden Sie unter Einschränkungen.

Erstellen Sie ein Subnetz in einem VPC-Netzwerk, um zusätzliche IP-Adressen für interne Arbeitslasten zuzuweisen.

Externes Netzwerksegment

Einem externen Netzwerksegment werden externe IP-Adressen zugewiesen, auf die externe Netzwerke zugreifen können, die mit Ihrer Organisation verbunden sind. Netzwerksegmenten in GDC werden nur externe IP-Adressen zugewiesen.

GDC bietet die folgenden logisch isolierten Netzwerksegmente:

• Admin-Netzwerksegment: Ein Netzwerk, dem während der Erstellung der Organisation externe IP-Adressen für administrative Dienste zugewiesen werden, z. B. die GDC-Konsole und Verwaltungs-APIs. Sie definieren IP-Adressen in diesem Netzwerksegment nur, wenn Sie die IP-Adressarchitektur Ihrer Organisation planen.
• Datennetzwerksegment: Ein Netzwerk, dem externe IP-Adressen für Dienste wie ausgehende Netzwerkadressübersetzung (NAT) und externe Load Balancer zugewiesen werden.

Sie können separate Interconnect-Verbindungen verwenden, um Netzwerksegmente mit anderen externen Netzwerken zu verbinden. IP-Adressen innerhalb der Netzwerksegmente dürfen sich nicht überschneiden. Weitere Informationen finden Sie unter Einschränkungen.

Erstellen Sie ein Subnetz in einem Netzwerksegment, um zusätzliche externe IP-Adressen für Dienste zuzuweisen, die eine Verbindung zu Netzwerken außerhalb Ihrer GDC-Organisation herstellen müssen.

Subnetzhierarchie

Subnetze werden nach ihrem Typ kategorisiert:

• Root: Subnetze auf oberster Ebene, von denen andere Subnetze abgeleitet werden können. Während der Bereitstellung Ihrer Organisation wird in jedem Netzwerk ein globales Root-Subnetz erstellt.
• Zweig: Subnetze, die von einem Stamm- oder einem anderen Zweigsubnetz abgeleitet sind und zur weiteren Unterteilung des IP-Adressbereichs verwendet werden.
• Blatt: die kleinste Unterteilung, die in der Regel zum Zuweisen von IP-Adressen für einen bestimmten Dienst oder eine bestimmte Ressource verwendet wird.

Dieses Beispieldiagramm zeigt, wie die verschiedenen Subnetztypen miteinander verbunden sind:

• Ein Root-Subnetz von 10.0.0.0/16, das als Block auf oberster Ebene für wichtige IP-Adresszuweisungen dient.
• Vom Root-Subnetz werden zwei Zweigsubnetze mit den Werten 10.0.1.0/24 und 10.0.2.0/24 abgeleitet. Diese Zweigsubnetze stellen Unterteilungen des Adressbereichs des Stammknotens dar und sind für spezifischere Zwecke vorgesehen.
• Die Zweigsubnetze werden weiter in Blatt-Subnetze mit Werten wie 10.0.1.10/32, 10.0.1.11/32 und 10.0.2.12/24 unterteilt. Diese Blatt-Subnetze sind in der Regel die kleinsten Unterteilungen und weisen oft einzelne IP-Adressen für bestimmte Dienste oder Ressourcen zu.

Hinweis: Ein Zweigsubnetz kann auch in andere Zweigsubnetze unterteilt werden.

Mit dieser hierarchischen Subnetzstruktur können Sie Ihr Netzwerk effizient über die Zonen, Arbeitslasten und Dienste hinweg delegieren und organisieren, die auf die IP-Adressen in Ihrem Netzwerk angewiesen sind. Wenn Sie die Verzweigung Ihres Subnetzes genauer steuern möchten, definieren Sie Ihr Subnetz so, dass CIDR-Blöcke statisch oder dynamisch zugewiesen werden.

Globale und zonale Subnetze

In GDC können Sie Subnetze in zwei verschiedenen Bereichen bereitstellen: zonal und global. Zonale und globale Subnetze werden in unterschiedlichen API-Servern definiert und betrieben und bieten unterschiedliche Funktionen.

Nachdem Ihre Organisation bereitgestellt wurde, hat jedes Netzwerk ein globales Root-Subnetz, das auf dem globalen API-Server Ihrer Organisation gehostet wird. Wenn Sie IP-Adressen aus dem globalen Root-Subnetz bereitstellen möchten, müssen Sie im globalen API-Server eine globale Subnet-Ressource erstellen, die einen CIDR-Block für eine Zone oder mehrere Zonen bereitstellt. Im globalen Subnetz definieren Sie das Feld propagationStrategy, um anzugeben, wie Sie Ihren CIDR-Block auf Zonen verteilen möchten. Dieser IP-Adressbereich wird einer Zone als zonales Root-Subnetz bereitgestellt.

Hinweis: Ein zonales Root-Subnetz, das direkt aus dem globalen Root-Subnetz bereitgestellt wird, hat das Label ipam.gdc.goog/usage: zone-network-root-range in seiner Subnet-Ressource. Dieses Label wird automatisch vom GDC-System angewendet.

Nachdem eine Zone ein eigenes zonales Root-Subnetz hat, können Sie im Verwaltungs-API-Server der Zone zonale Subnet-Ressourcen erstellen, um den IP-Adressbereich des Subnetzes weiter in zusätzliche Zweigsubnetze innerhalb der Zone oder Blatt-Subnetze aufzuteilen, die für einzelne Arbeitslasten und Dienste innerhalb der Zone verfügbar sind.

Globale Subnetze

Sie müssen ein globales Subnetz erstellen, um IP-Adressen aus dem im globalen API-Server gehosteten Root-Subnetz einer oder mehreren Zonen in Ihrem GDC-Universum zuzuweisen.

Globale Subnetze werden im globalen API-Server mit der API-Gruppe ipam.global.gdc.goog/v1 erstellt und enthalten optionale Felder wie zone und propagationStrategy, um ihre Interaktion mit bestimmten Zonen zu definieren.

Globale Subnetze hosten einen CIDR-Block als Zweigsubnetzbereich, der von Zonen in einem GDC-Universum genutzt wird. Weitere Informationen dazu, wo Sie Ihre globalen Subnetze erstellen können, finden Sie unter Netzwerke in GDC.

Zonale Subnetze

Ein zonales Subnetz ist mit einer bestimmten Betriebszone verknüpft, oft einschließlich direkter Netzwerkkonfigurationen. Zonale Subnetze arbeiten ausschließlich innerhalb einer einzelnen Zone und werden hauptsächlich für Arbeitslasten von virtuellen Maschinen und Containern innerhalb dieser Zone bereitgestellt. Ein zonales Subnetz weist IP-Adressen, die bereits für die Zone bereitgestellt wurden, zur Verwendung durch ein globales Subnetz zu.

Damit die VPC-zu-VPC-Kommunikation über Zonen hinweg ordnungsgemäß funktioniert, müssen in jeder Zone nicht überlappende Subnetze verwendet werden.

Zonale Subnetze werden im Management API-Server mit der API-Gruppe ipam.gdc.goog/v1 erstellt und enthalten ein optionales Feld networkSpec in ihrer Spezifikation, sodass Sie zonenspezifische Netzwerkelemente wie Gateways und VLAN-IDs definieren können.

Subnetz-Labels

Es gibt vier Arten von Subnetzlabels:

• ipam.gdc.goog/vpc: Gibt das Netzwerk des Subnetzes als VPC an.
• ipam.gdc.goog/network-segment: Gibt das Netzwerk des Subnetzes als Netzwerksegment an.
• ipam.gdc.goog/usage: Gibt den Zweck des Subnetzes an.
• ipam.gdc.goog/subnet-group: Gibt die Subnetzgruppe an, zu der das Subnetz gehört. Weitere Informationen finden Sie unter Subnetzgruppen.

In der folgenden Tabelle sehen Sie die Zuordnung zwischen den Netzwerken und den Netzwerk-Labels:

Netzwerk	Label
Standard-VPC	ipam.gdc.goog/vpc: default-vpc
Infrastruktur-VPC	ipam.gdc.goog/vpc: infra-vpc
Admin-Netzwerksegment	ipam.gdc.goog/network-segment: admin
Datennetzwerksegment	ipam.gdc.goog/network-segment: data

Die CIDR-Bereiche der vier Netzwerke werden im Rahmen des Bootstrap-Prozesses in Ihrer Organisation festgelegt. Die vier entsprechenden globalen Subnetze befinden sich auf dem globalen API-Server. Diese globalen Subnetze sind der CIDR-Bereich auf Stammebene für jedes Netzwerk in allen Zonen einer Organisation. Alle globalen Subnetze auf Stammebene haben ein weiteres Label ipam.gdc.goog/usage: network-root-range.

Für jede Zone ist im globalen API-Server, der aus der Organisationsbereitstellung stammt, anfänglich ein zonales Netzwerk-Root-Subnetz verfügbar. Sie können zusätzliche Root-Subnetze erstellen, um Ihren IP-Adressbereich zu erweitern. Jedes Root-Subnetz hostet einen CIDR-Bereich für ein Netzwerk in der jeweiligen Zone und dient logisch als Root-Subnetz mit zonalem Bereich und dem Label ipam.gdc.goog/usage: zone-network-root-range. Dieses Root-Subnetz muss zuerst im globalen API-Server erstellt werden und wird automatisch an eine angegebene Zone weitergegeben. Weitere Informationen zu Subnetzbereichen finden Sie unter Globale und zonale Subnetze.

Sie müssen die definierten Labels verwenden, wenn Sie eine benutzerdefinierte Subnet-Ressource erstellen, um sie auf das entsprechende GDC-Netzwerk anzuwenden. Das folgende Diagramm zeigt globale und zonale Netzwerke innerhalb eines GDC-Universums:

In diesem Diagramm gibt es zwei Organisationen, die ein Multi-Zonen-Universum umfassen. Jede Organisation definiert die VPC-Netzwerke und externen Netzwerksegmente. In diesem Beispiel werden Anycast-IP-Adressen verwendet, um Traffic zwischen den zonalen externen Netzwerksegmenten weiterzuleiten, sodass die nächstgelegene oder leistungsstärkste Zone die Netzwerkanfrage verarbeitet. Weitere Informationen zu Anycast-IP-Adressen finden Sie unter IP-Adressen in GDC.

Subnetzgruppen

Eine Subnetzgruppe ist eine Gruppe von Subnetzen mit demselben Subnetzgruppenlabel, z. B. ipam.gdc.goog/subnet-group: subnetgroup1. Das Organisieren von Subnetzen in einer Gruppe bietet folgende Vorteile:

• Eine Subnetzgruppe vereinfacht die Skalierung von IP-Adressressourcen, die derselben Entität gehören oder für denselben Zweck verwendet werden. Ein Subnetz kann nicht einzeln hochskaliert werden. Sie können jedoch eine Subnetzgruppe hochskalieren, indem Sie ihr ein neues Subnetz hinzufügen. Nutzer können eine Subnetzgruppe als IP-Adressressource referenzieren und die Vorteile der Skalierung nutzen.
• Beim Erstellen eines untergeordneten Subnetzes können Nutzer eine Subnetzgruppe als übergeordnetes Element anstelle eines einzelnen Subnetzes angeben. Wenn Sie eine Subnetzgruppe auf diese Weise verwenden, müssen Nutzer nicht selbst ein übergeordnetes Subnetz mit verfügbarem IP-Adressbereich finden. Stattdessen sucht GDC automatisch ein Subnetz in der Subnetzgruppe mit genügend verfügbarem IP-Adressbereich als übergeordnetes Subnetz.
• Wenn die IP-Adressressourcen für einen einzelnen Zweck oder eine einzelne Entität aufgebraucht sind, ist die Fehlerinformation im untergeordneten Subnetz mit der Subnetzgruppe als übergeordnetem Element einfacher und der Aufwand für die Überprüfung jedes Subnetzes wird reduziert.

Alle Funktionen der Subnetzgruppe gelten sowohl für globale als auch für zonale Subnetze.

Erstellung und Skalierung von Subnetzgruppen

Es gibt kein API-Objekt für eine Subnetzgruppe. Stattdessen wird eine Subnetzgruppe durch ein Label identifiziert. Wenn Sie eine Subnetzgruppe erstellen oder ihr ein Subnetz hinzufügen möchten, fügen Sie einem vorhandenen Subnetz ein Subnetzgruppenlabel hinzu oder erstellen Sie ein neues Subnetz mit einem Subnetzgruppenlabel.

Wenn die Subnetzgruppe noch nicht vorhanden ist, wird eine neue Subnetzgruppe erstellt. Wenn im selben Namespace bereits andere Subnetze mit demselben Subnetzgruppenlabel vorhanden sind, wird das neue Subnetz der vorhandenen Subnetzgruppe hinzugefügt.

Das folgende Beispiel zeigt die Definition eines Subnetzes, das an eine Subnetzgruppe mit dem Namen default-vpc-us-east67-b-group angehängt ist:

apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
  # Several lines of code are omitted here.
  labels:
    ipam.gdc.goog/subnet-group: default-vpc-us-east67-b-group
    ipam.gdc.goog/usage: zone-network-root-range
    ipam.gdc.goog/vpc: default-vpc
  name: default-vpc-us-east67-b-root-cidr
  namespace: platform
  # Several lines of code are omitted here.
spec:
  ipv4Request:
    cidr: 10.99.0.0/16
  parentReference:
    name: default-vpc-root-cidr
    namespace: platform
    type: SingleSubnet
  type: Branch

Regeln zum Erstellen und Skalieren von Subnetzgruppen

Beachten Sie beim Erstellen einer Subnetzgruppe die folgenden Regeln:

• Subnetzgruppen werden für jeden Namespace-Bereich definiert. Subnetze mit demselben Subnetzgruppenlabel, aber in zwei verschiedenen Namespaces, werden als Teil von zwei verschiedenen Subnetzgruppen betrachtet.
• Ein Subnetz kann nicht der Nachfolger eines anderen Subnetzes in derselben Gruppe sein.
• Subnetze in derselben Gruppe müssen zum selben VPC- oder Netzwerksegment gehören.
• Ein Subnetz kann nur an eine Subnetzgruppe angehängt werden.

Subnetzgruppen als übergeordnete Gruppe

Wenn Sie ein untergeordnetes Subnetz erstellen, können Sie alternativ zur Verwendung eines einzelnen Subnetzes als übergeordnetes Element eine Subnetzgruppe als übergeordnetes Element angeben. Wenn Sie eine Subnetzgruppe als übergeordnetes Element referenzieren möchten, müssen Sie Folgendes tun:

1. Legen Sie den Wert spec.parentReference.type explizit auf SubnetGroup fest. Wenn das Feld leer bleibt, ist der Standardwert SingleSubnet.
2. Wenn sich die übergeordnete Subnetzgruppe in einem anderen Namespace als das untergeordnete Subnetz befindet, müssen Sie das Feld spec.parentReference.namespace als Namespace der übergeordneten Subnetzgruppe angeben.

Nachdem ein untergeordnetes Subnetz aus einer Subnetzgruppe erstellt wurde, weist GDC einen CIDR-Block aus der Subnetzgruppe basierend auf der Anfrage des untergeordneten Subnetzes und der Verfügbarkeit der Subnetze in der übergeordneten Subnetzgruppe zu. Wenn ein geeignetes übergeordnetes Subnetz gefunden wird, erhält das untergeordnete Subnetz seinen CIDR-Block vom übergeordneten Subnetz und der Verweis des übergeordneten Subnetzes wird im Status des untergeordneten Subnetzes aktualisiert.

Das Subnetz im folgenden Beispiel fordert einen CIDR-Block aus der Subnetzgruppe default-vpc-zone1-group an. Ihm wird ein übergeordneter platform/default-vpc-zone1-root-cidr-CIDR-Block im Status zugewiesen:

apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
# Several lines of code are omitted here.
  labels:
    ipam.gdc.goog/vpc: default-vpc
  name: default-vpc-default-node-subnet
  namespace: platform
# Several lines of code are omitted here.
spec:
  ipv4Request:
    prefixLength: 23
  networkSpec:
    enableGateway: true
    enableVLANID: false
  parentReference:
    name: default-vpc-zone1-group
    namespace: platform
    type: SubnetGroup
  type: Branch
status:
  allocatedParent:
    name: default-vpc-zone1-root-cidr
    namespace: platform
    type: SingleSubnet
# Several lines of code are omitted here.

Regeln für den Verweis auf eine Subnetzgruppe als übergeordnetes Element

Beachten Sie beim Verweisen auf eine Subnetzgruppe als übergeordnetes Element die folgenden Regeln:

• Der Ersteller des untergeordneten Subnetzes muss die Berechtigung haben, alle Subnetze in der Subnetzgruppe zu verwenden.
• Das untergeordnete Subnetz muss sich in derselben VPC oder demselben Netzwerksegment wie die Subnetzgruppe befinden.

Statische und dynamische CIDR-Konfiguration

Beim Definieren von Subnetzen können Sie eine statische oder dynamische Konfiguration für die Zuweisung der CIDR-Blöcke verwenden.

Mit der statischen CIDR-Konfiguration können Sie den genauen CIDR-Block für Ihr Subnetz explizit angeben. Weisen Sie Ihren CIDR-Block statisch zu, wenn Sie eine genaue Kontrolle über Ihren IP-Adressbereich benötigen. Verwenden Sie das Feld spec.ipv4Request.cidr in der benutzerdefinierten Ressource Subnet, um den genauen, vordefinierten IP-Adressbereich anzugeben.

Die dynamische CIDR-Konfiguration bietet mehr Flexibilität, da das System automatisch einen CIDR-Block für Ihr Subnetz zuweisen kann. Anstatt einen vollständigen CIDR anzugeben, geben Sie die erforderliche Präfixlänge im Feld spec.ipv4Request.prefixLength an. Weisen Sie Ihren CIDR-Block dynamisch zu, wenn Sie möchten, dass das System IP-Adressen automatisch an Ihre Subnetze delegiert. Dadurch wird die Netzwerkplanung vereinfacht und das Risiko von IP-Adresskonflikten verringert. Das System wählt einen verfügbaren CIDR-Block der angegebenen Größe aus dem übergeordneten Netzwerk aus.

Weitere Informationen finden Sie in der SubnetRequest API.

IP-Adressen in GDC

Wichtig: GDC unterstützt nur IPv4-Bereiche für Subnetze, die in der Standard-VPC und im Datennetzwerksegment erstellt wurden. Weitere Informationen finden Sie unter Einschränkungen.

Ressourcen wie VMs und Load Balancer haben IP-Adressen in GDC. Mit diesen IP-Adressen können GDC-Ressourcen mit anderen Ressourcen innerhalb einer Organisation oder mit externen Netzwerken kommunizieren, die mit Ihrer Organisation verbunden sind. Die folgenden IP-Adresstypen sind in einem GDC-Universum verfügbar:

Externe IP-Adresse

Externe IP-Adressen werden an externe Netzwerke weitergegeben, die mit einer Organisation verbunden sind. Ressourcen mit externen IP-Adressen, z. B. Load Balancer und NAT, können mit externen Netzwerken kommunizieren. Mit GDC können Sie private oder öffentliche IP-Adressen als externe Adressen verwenden. Externe IPv4-Adressen für Ressourcen können auf folgende Weise bereitgestellt werden:

• Eigene externe IP-Adressen verwenden (BYOIP): Sie stellen diese externen IP-Adressen für Ihre Organisation bereit. Externe BYOIP-IP-Adressen können sich mit anderen Organisationen überschneiden, solange sie keine Verbindung zum selben externen Netzwerk herstellen.
• Vom Infrastrukturbetreiber bereitgestellte externe IP-Adressen: Organisationen können die von der Infrastrukturbetreibergruppe bereitgestellten externen IP-Adressen verwenden, wenn sie eine Verbindung zu einem externen Netzwerk herstellen. Die Gruppe der Infrastrukturbetreiber ist der Anbieter der Verbindung zu diesem Netzwerk.

Interne IP-Adresse

Interne IP-Adressen können nicht direkt von außerhalb der GDC erreicht werden und sind nicht öffentlich routingfähig. Interne IP-Adressen sind lokal in einem VPC-Netzwerk, in einem VPC-Netzwerk, das über VPC-Netzwerk-Peering verbunden ist, oder in einem lokalen Netzwerk, das über Cloud VPN mit einem VPC-Netzwerk verbunden ist. Ressourcen mit internen IP-Adressen kommunizieren mit anderen Ressourcen, als befänden sie sich alle im selben privaten Netzwerk.

Anycast-IP-Adresse

Anycast-IP-Adressen sind ein spezieller Typ von externen Adressen, die immer auf das gesamte GDC-Universum beschränkt sind. GDC nutzt Anycast-IP-Adressen zusammen mit dem Border Gateway Protocol (BGP), um Traffic an die nächstgelegene oder leistungsstärkste Zone weiterzuleiten. Jeder globale Layer-4-Dienst, der in zwei oder mehr Zonen ausgeführt wird, erhält eine Anycast-IP-Adresse aus dem Anycast-Subnetz, einem externen Subnetz. Jede Zone bewirbt dieselbe Anycast-IP-Adresse, aber Ihr Netzwerk wählt die beste anhand seiner Routingregeln aus. Wenn eine Zone ausfällt, wird ihre IP-Adresse zurückgezogen und Ihr Netzwerk leitet den Traffic automatisch an eine andere Zone weiter. Dieses automatische Routing sorgt auch bei Ausfällen für eine nahtlose Verbindung.

Private IP-Adresse

Private IP-Adressen sind Adressen, die nicht im Internet weitergeleitet werden können. Eine Liste der privaten IPv4-Adressbereiche finden Sie in den Einträgen für private IP-Adressbereiche in der Tabelle Gültige IPv4-Bereiche.

Öffentliche IP-Adresse

Öffentliche IP-Adressen sind über das Internet weiterleitbare Adressen. In GDC können externe IP-Adressen öffentlich oder privat sein. Sie können öffentliche IP-Adressen auch als interne Adressen verwenden, wenn Sie den primären IPv4-Adressbereich eines Subnetzes in Ihrem VPC-Netzwerk konfigurieren. Diese Adressen werden als privat verwendete öffentliche IP-Adressen bezeichnet.

IPv4-Adressauswahl

Jedes Netzwerk in Ihrem GDC-Universum hat eine Reihe von gültigen, unzulässigen und nicht verwendbaren IPv4-Adressen, die Sie bei der Zuweisung von IP-Adressen berücksichtigen müssen.

IPv6-Adressbereiche werden im Standard-VPC- und Datennetzwerksegment nicht unterstützt. Wenden Sie sich an Ihre Infrastrukturbetreibergruppe, um Informationen zu IPv6-Bereichsmöglichkeiten in anderen Netzwerken zu erhalten.

Gültige IPv4-Bereiche

In der folgenden Tabelle werden gültige Bereiche beschrieben.

Bereich	Beschreibung
Private IPv4-Adressbereiche
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16	Private IP-Adressen RFC 1918 Informationen zur Verwendung von 172.17.0.0/16 finden Sie unter Zusätzliche Überlegungen.
100.64.0.0/10	Gemeinsamer Adressbereich RFC 6598
192.0.0.0/24	IETF-Protokollzuweisungen RFC 6890
192.0.2.0/24 (TEST-NET-1) 198.51.100.0/24 (TEST-NET-2) 203.0.113.0/24 (TEST-NET-3)	Dokumentation RFC 5737
192.88.99.0/24	IPv6-zu-IPv4-Relay (verworfen) RFC 7526
198.18.0.0/15	Benchmarktests RFC 2544
240.0.0.0/4	Für die spätere Verwendung (Klasse E) reserviert, wie in RFC 5735 und RFC 1112 vermerkt. Einige Betriebssysteme unterstützen die Verwendung dieses Bereichs nicht. Prüfen Sie daher, ob Ihr Betriebssystem ihn unterstützt, bevor Sie Subnetze erstellen, die diesen Bereich verwenden.
Privat verwendete öffentliche IP-Adressbereiche
Privat genutzte öffentliche IPv4-Adressen	Privat genutzte öffentliche IPv4-Adressen haben die folgenden Merkmale: IPv4-Adressen, die normalerweise im Internet geroutet werden können, aber in einem VPC-Netzwerk privat genutzt werden. Sie dürfen nicht zu einem unzulässigen Subnetzbereich gehören. GDC mit Air Gap setzt keine Verbindung zum Internet voraus. Daher werden in GDC mit Air Gap alle öffentlichen IP-Adressbereiche so beworben, als wären sie privat für Ihre Organisation. Wenn Ihre importierten BYOIP-Adressen (Bring Your Own IP) öffentliche IP-Adressbereiche sind, müssen Sie prüfen, ob sie in externen Netzwerken Netzwerkprobleme verursachen. Ihre BYOIP-Adressen dürfen sich nicht mit anderen Subnetzen in Ihrer Organisation überschneiden.

Unzulässige IPv4-Subnetze

Unzulässige Subnetzbereiche umfassen häufig reservierte RFC-Bereiche und alle global reservierten Subnetze in Ihrem spezifischen GDC-Universum, wie in der folgenden Tabelle beschrieben. Diese Bereiche können nicht für Subnetze verwendet werden.

Wichtig: GDC reserviert IP-Adressen für die Systemnutzung. Darüber hinaus hat die Gruppe der Infrastrukturbetreiber möglicherweise reservierte Bereiche, die für Ihre Organisation nicht verfügbar sind. Diese Bereiche unterscheiden sich für jede GDC-Umgebung und können daher hier nicht dokumentiert werden. Prüfen Sie, ob Ihre Infrastrukturbetreibergruppe Ihnen diese Bereiche zur Verfügung stellt, um die IP-Adressplanung Ihrer Organisation zu unterstützen.

Bereich	Beschreibung
GDC-Infrastrukturbereich	Ein global reservierter CIDR-Block, der vom GDC-System verwendet wird. Wenn dieser Bereich nicht im Feld zone-infra-cidr des Fragebogens zur Kundenaufnahme (CIQ) angegeben ist, verwendet GDC standardmäßig 172.16.0.0/12 als GDC-Infrastrukturbereich.
Universumspezifische Bereiche	Zusätzliche Bereiche, die von der Gruppe der Infrastrukturbetreiber reserviert wurden.
0.0.0.0/8	Aktuelles (lokales) Netzwerk RFC 1122
127.0.0.0/8	Lokaler Host RFC 1122
169.254.0.0/16	Link-Local RFC 3927
224.0.0.0/4	Multicast (Klasse D) RFC 5771
255.255.255.255/32	Eingeschränkte Übertragungszieladresse RFC 8190 und RFC 919

Nicht verwendbare Adressen in IPv4-Subnetzen

GDC verwendet zum Hosten des Subnetzes die ersten beiden und die letzten beiden IPv4-Adressen in jedem Subnetz.

Nicht verwendbare IPv4-Adresse	Beschreibung	Beispiel
Netzwerkadresse	Erste Adresse im primären IPv4-Bereich.	10.1.2.0 aus dem Bereich 10.1.2.0/24
Standard-Gateway-Adresse	Zweite Adresse im primären IPv4-Bereich.	10.1.2.1 aus dem Bereich 10.1.2.0/24
Vorletzte Adresse	Vorletzte Adresse im primären IPv4-Bereich. Dieser Bereich ist von Google Cloud für eine mögliche zukünftige Verwendung reserviert.	10.1.2.254 aus dem Bereich 10.1.2.0/24
Broadcast-Adresse	Letzte Adresse im primären IPv4-Bereich.	10.1.2.255 aus dem Bereich 10.1.2.0/24

Weitere Überlegungen

Einige Google- und Drittanbieterprodukte verwenden 172.17.0.0/16 für das Routing innerhalb des Gastbetriebssystems. Das Standard-Docker-Bridge-Netzwerk verwendet beispielsweise diesen Bereich. Wenn Sie ein Produkt benötigen, das 172.17.0.0/16 verwendet, verwenden Sie es nicht als IPv4-Adressbereich des Subnetzes.

Beschränkungen

Diese Einschränkungen gelten für VPC-Netzwerksubnetze und Subnetze externer Netzwerksegmente in GDC:

• Alle Subnetze müssen ein eindeutiger gültiger CIDR-Block sein.
• Nachdem Sie ein Subnetz erstellt haben, kann es nicht mehr hochskaliert, ersetzt oder verkleinert werden.
• GDC unterstützt nur IPv4-Bereiche für Subnetze, die in der Standard-VPC und im Datennetzwerksegment erstellt wurden. Wenden Sie sich an Ihre Gruppe von Infrastrukturbetreibern, um Informationen zu IPv6-Bereichsmöglichkeiten für andere Netzwerke in Ihrem GDC-Universum zu erhalten.
• GDC erzwingt keine Beschränkung für die Größe eines CIDR-Blocks, der erstellt werden kann. Bei den meisten IP-Adressbereichen, die größer als /8 sind, verhindern zusätzliche Validierungen jedoch, dass Sie ein so großes Subnetz erstellen. Ein Subnetz darf sich beispielsweise nicht mit einem unzulässigen Subnetz überschneiden. Um die Wahrscheinlichkeit zu minimieren, dass ein ungültiges Subnetz ausgewählt wird, empfehlen wir, die maximale Subnetzgröße auf /8 zu beschränken.

• Sie können keine Subnetze erstellen, die sich mit unzulässigen Subnetzen, anderen Subnetzen im selben VPC-Netzwerk, Subnetzen in einem angehängten externen Netzwerksegment oder Subnetzen in einem Peering-Netzwerk überschneiden. Sie müssen mit Ihrer Infrastrukturbetreibergruppe zusammenarbeiten, um sicherzustellen, dass Sie in diesen Szenarien keine überlappenden Subnetze erstellen.

  Hinweis: Ein Peering-Netzwerk ist ein Netzwerk, das Netzwerkrouten mit anderen Netzwerken austauscht. Dazu gehören externe Kundennetzwerke, externe Netzwerksegmente von Organisationen in einer gemeinsamen Interconnect-Gruppe und Peering-VPC-Netzwerke. Beispielsweise sind die Infrastruktur-VPC und die Standard-VPC Peer-Netzwerke zueinander.

• GDC erstellt entsprechende Routen für Subnetze. Für VPC-Netzwerksubnetze werden Routen im virtuellen Netzwerkstack Ihrer Organisation erstellt. Für Subnetze externer Netzwerksegmente werden Routen in der Routingtabelle Ihres externen Peering-Netzwerks erstellt.

• Prüfen Sie, ob Subnetze mit der lokalen IP-Adressierung in Konflikt stehen, wenn Sie Ihr VPC-Netzwerk über ein verwaltetes VPN oder eine freigegebene oder dedizierte Interconnect-Verbindung mit einem anderen Netzwerk verbunden haben.

• Subnetze dürfen nicht kleiner oder größer als ein unzulässiger Bereich sein oder mit diesem übereinstimmen. 169.0.0.0/8 ist beispielsweise kein gültiges Subnetz, da es sich mit dem Link-Local-Bereich 169.254.0.0/16 (RFC 3927) überschneidet, der eingeschränkt ist.

• Subnetze dürfen sich nicht über einen RFC-Bereich, wie unter Gültige IPv4-Bereiche beschrieben, und einen privat genutzten öffentlichen IP-Adressbereich erstrecken. Beispiel: 172.0.0.0/10 ist kein gültiges Subnetz, da es sowohl den privaten IP-Adressbereich 172.16.0.0/12 als auch öffentliche IP-Adressen enthält.

• Subnetze dürfen sich nicht über mehrere RFC-Bereiche erstrecken. 192.0.0.0/8 ist beispielsweise kein gültiges Subnetz, da es sowohl 192.168.0.0/16 (RFC 1918) als auch 192.0.0.0/24 (RFC 6890) enthält. Sie können jedoch zwei Subnetze erstellen, eines mit 192.168.0.0/16 und eines mit 192.0.0.0/24.

Nächste Schritte

• Netzwerkübersicht
• IP-Adressen für Arbeitslasten bereitstellen
• Eigene externe IP-Adressen verwenden
• Zonen in GDC mit Air Gap