Subnetze und IP-Adressen in GDC

Auf dieser Übersichtsseite wird das Betriebsmodell für IP-Adressen in einem GDC-Universum (Google Distributed Cloud) mit Air Gap erläutert. IP-Adressen werden in Subnetze unterteilt, um überschaubare Segmente zu schaffen, die Sie Ihren Diensten zuweisen können. Sie können Subnetze mit bestimmten IP-Adressbereichen definieren oder sie für die dynamische Zuweisung konfigurieren.

Diese Seite 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 in einem GDC-Universum 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 von Arbeitslasten innerhalb Ihrer Organisation zugegriffen werden kann.
• 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 jedes Netzwerktyps zuweisen, um bestimmte Ziele zu erreichen. Ein Subnetz ist eine logische Unterteilung eines IP-Adressnetzwerks, das 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 in diesen Netzwerktypen hat einen unabhängigen Subnetzbaum.

Subnetze in einer VPC sind über das GDC-Netzwerk zugänglich und können nicht außerhalb des GDC erreicht werden. VPC-Subnetze sind verfügbar, um interne IP-Adressen in Ihrer Organisation zuzuweisen. Subnetze für Netzwerksegmente sind für externe Netzwerke verfügbar, die mit einer Organisation verbunden sind. So können Sie externe IP-Adressen für Netzwerke außerhalb Ihrer Organisation bereitstellen.

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 Ihrem GDC-Universum 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.
• Infra-VPC: Eine vom System verwaltete VPC, in der GDC-Airgap-Dienste von Google gehostet werden, 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 Infra-VPC dürfen sich innerhalb derselben Organisation nicht überschneiden. Weitere Informationen finden Sie unter IPv4-Nutzung und ‑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 bei der Erstellung der Organisation externe IP-Adressen für administrative Dienste zugewiesen werden, z. B. für die GDC-Konsole und Verwaltungs-APIs. Sie definieren IP-Adressen in diesem Netzwerksegment nur, wenn Sie die IP-Adressarchitektur Ihrer Organisation planen.
• Datensegment: Ein Netzwerk, dem externe IP-Adressen für Dienste wie Egress-NAT (Network Address Translation) und externe Load Balancer zugewiesen sind.

Sie können separate Interconnects verwenden, um Netzwerksegmente mit anderen externen Netzwerken zu verbinden. IP-Adressen in den Netzwerksegmenten dürfen sich nicht überschneiden. Weitere Informationen finden Sie unter IPv4-Nutzung und ‑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.

Subnetz-Hierarchie

Subnetze werden nach ihrem Typ kategorisiert:

• Root: Subnetze der obersten Ebene, aus denen andere Subnetze abgeleitet werden können. Bei der Bereitstellung Ihrer Organisation wird in jedem Netzwerk ein globales Stamm-Subnetz erstellt.
• Branch (Zweig): Subnetze, die von einem Stamm- oder einem anderen Zweigsubnetz abgeleitet werden und zum weiteren Unterteilen des IP-Adressraums verwendet werden.
• Leaf: Die kleinste Unterteilung, die in der Regel zum Zuweisen von IP-Adressen für einen bestimmten Dienst oder eine bestimmte Ressource verwendet wird.

Das folgende Diagramm veranschaulicht, wie die verschiedenen Subnetztypen miteinander verbunden sind:

• Ein Stamm-Subnetz von 10.0.0.0/16, das als Block der obersten Ebene für die Zuweisung wichtiger IP-Adressen dient.
• Aus dem Stamm-Subnetz werden zwei untergeordnete Subnetze mit den Werten 10.0.1.0/24 und 10.0.2.0/24 abgeleitet. Diese Zweig-Subnetze stellen Unterteilungen des Adressbereichs des Root-Subnetzes dar, die für spezifischere Zwecke vorgesehen sind.
• 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 untergeordneten Subnetze sind in der Regel die kleinsten Unterteilungen, wobei oft einzelne IP-Adressen für bestimmte Dienste oder Ressourcen zugewiesen werden.

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

Mit dieser hierarchischen Subnetzstruktur können Sie Ihr Netzwerk effizient auf die Arbeitslasten und Dienste verteilen und organisieren, die auf die IP-Adressen in Ihrem Netzwerk angewiesen sind.

Globale und zonale Subnetze

In GDC können Sie Subnetze in zwei verschiedenen Bereichen bereitstellen: zonal und global. Zonale und globale Subnetze werden auf separaten API-Servern definiert und ausgeführt und bieten unterschiedliche Funktionen.

Nachdem Ihre Organisation bereitgestellt wurde, hat jedes Netzwerk ein globales Stamm-Subnetz, das auf dem globalen API-Server Ihrer Organisation gehostet wird. Wenn Sie IP-Adressen aus dem globalen Stamm-Subnetz bereitstellen möchten, müssen Sie eine globale Subnet-Ressource auf dem globalen API-Server erstellen, mit der ein CIDR-Block für eine Zone oder für mehrere Zonen bereitgestellt wird. 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 zugewiesen.

Hinweis :Ein zonales Stamm-Subnetz, das direkt über das globale Stamm-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 über ein eigenes zonales Stamm-Subnetz verfügt, können Sie zonale Subnet-Ressourcen auf dem Management-API-Server der Zone erstellen, um den IP-Adressbereich des Subnetzes in zusätzliche Zweig-Subnetze innerhalb der Zone oder in Blatt-Subnetze zu unterteilen, 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 Stamm-Subnetz einer oder mehreren Zonen in Ihrem GDC-Universum zuzuweisen.

Globale Subnetze werden auf dem 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 enthalten einen CIDR-Block als untergeordneten Subnetzbereich, der von Zonen in einem GDC-Universum verwendet 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 und enthält oft direkte Netzwerkkonfigurationen. Zonale Subnetze sind ausschließlich in einer einzigen Zone verfügbar und werden hauptsächlich für Arbeitslasten mit virtuellen Maschinen und Containern in dieser Zone bereitgestellt. In einem zonalen Subnetz werden IP-Adressen, die bereits für die Zone bereitgestellt wurden, für die Verwendung durch ein globales Subnetz zugewiesen.

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

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

Subnetz-Labeling

Es gibt vier Arten von Labels:

• ipam.gdc.goog/vpc und ipam.gdc.goog/network-segment werden verwendet, um das Netzwerk zu identifizieren, zu dem dieses Subnetz gehört.
• ipam.gdc.goog/usage gibt den Zweck an, für den dieses Subnetz verwendet wird.
• ipam.gdc.goog/subnet-group gibt die Subnetzgruppe an, zu der dieses Subnetz gehört. Die Funktion für Subnetzgruppen wird im folgenden Abschnitt Subnetzgruppen vorgestellt.

Die folgende Tabelle zeigt die Zuordnung zwischen den Netzwerken und den Netzwerklabels:

Netzwerk	Label
Standard-VPC	ipam.gdc.goog/vpc: default-vpc
Infra-VPC	ipam.gdc.goog/vpc: infra-vpc
Administratornetzwerksegment	ipam.gdc.goog/network-segment: admin
Datensegment für das Netzwerk	ipam.gdc.goog/network-segment: data

Die CIDR-Bereiche der vier Netzwerke wurden 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 anfangs ein zonales Netzwerk-Root-Subnetz auf dem globalen API-Server verfügbar, das aus der Organisationsbereitstellung stammt. Sie können zusätzliche Stamm-Subnetze erstellen, um Ihren IP-Adressraum zu erweitern. Jedes Stamm-Subnetz enthält einen CIDR-Bereich für ein Netzwerk in der jeweiligen Zone und dient logisch als zonenbezogenes Stamm-Subnetz mit dem Label ipam.gdc.goog/usage: zone-network-root-range. Dieses Stamm-Subnetz muss zuerst auf dem globalen API-Server erstellt werden und wird automatisch in eine angegebene Zone übertragen. 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 veranschaulicht globale und zonale Netzwerke in einem GDC-Universum:

In diesem Diagramm sind zwei Organisationen dargestellt, die sich über ein Universum mit mehreren Zonen erstrecken. Jede Organisation definiert die VPC-Netzwerke und externen Netzwerksegmente. In diesem Beispiel werden Anycast-IP-Adressen verwendet, um den Traffic zwischen den zonenbasierten externen Netzwerksegmenten weiterzuleiten. So wird die Netzwerkanfrage von der nächstgelegenen oder leistungsstärksten Zone bearbeitet. 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). Die Organisation von Subnetzen in einer Gruppe bietet die folgenden Vorteile:

1. Eine Subnetzgruppe vereinfacht die Aufskalierung der IP-Ressourcen, die derselben Organisation gehören oder für denselben Zweck verwendet werden. Ein Subnetz kann nicht allein skaliert werden, eine Subnetzgruppe jedoch schon, indem ein neues Subnetz daran angehängt wird. Nutzer können auf eine Subnetzgruppe als IP-Ressource verweisen und die Vorteile der Aufskalierung nutzen.
2. Beim Erstellen eines untergeordneten Subnetzes können Nutzer anstelle eines einzelnen Subnetzes auf eine Subnetzgruppe als übergeordnetes Element verweisen. Wenn Sie eine Subnetzgruppe auf diese Weise verwenden, müssen Nutzer nicht selbst nach einem übergeordneten Subnetz mit verfügbarem IP-Bereich suchen. Stattdessen sucht IPAM automatisch nach einem Subnetz in der Subnetzgruppe mit ausreichend verfügbarem IP-Bereich als übergeordnetes Subnetz.
3. Wenn die IP-Ressourcen für einen einzelnen Zweck oder eine einzelne Einheit mit der Subnetzgruppe als übergeordnetem Element aufgebraucht sind, sind die Fehlerinformationen im untergeordneten Subnetz einfacher und es ist weniger Aufwand erforderlich, alle Subnetze einzeln zu prüfen.

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

Subnetzgruppe erstellen und hochskalieren

Es gibt keine API oder kein Objekt für eine Subnetzgruppe. Stattdessen wird eine Subnetzgruppe durch ein Subnetzgruppenlabel 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.

Im folgenden Beispiel sehen Sie die Definition eines Subnetzes, das an eine Subnetzgruppe namens default-vpc-us-east67-b-group angehängt ist.

apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
  ...
  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
  ...
spec:
  ipv4Request:
    cidr: 10.99.0.0/16
  parentReference:
    name: default-vpc-root-cidr
    namespace: platform
    type: SingleSubnet
  type: Branch

Regeln für das Erstellen und Hochskalieren von Subnetzgruppen

1. Subnetzgruppen werden pro Namespace-Bereich definiert. Subnetze mit demselben Subnetzgruppenlabel, aber in zwei verschiedenen Namespaces werden als Teil von zwei verschiedenen Subnetzgruppen betrachtet.
2. Ein Subnetz kann nicht das untergeordnete Element eines anderen Subnetzes in derselben Gruppe sein.
3. Subnetze in derselben Gruppe müssen zum selben VPC- oder Netzwerksegment gehören.
4. Ein Subnetz kann nur an eine Subnetzgruppe angehängt werden.

Subnetzgruppe als übergeordnetes Element verwenden

Beim Erstellen eines untergeordneten Subnetzes kann der Nutzer anstelle eines einzelnen Subnetzes als übergeordnetes Element auf eine Subnetzgruppe verweisen. Wenn Sie auf eine Subnetzgruppe als übergeordnetes Element verweisen möchten, müssen Sie Folgendes tun:

1. Legen Sie spec.parentReference.type explizit auf SubnetGroup fest. Wenn das Feld leer gelassen wird, ist der Standardwert SingleSubnet.
2. Wenn sich die übergeordnete Subnetzgruppe in einem anderen Namespace als das untergeordnete Subnetz befindet, muss spec.parentReference.namespace für den Namespace der übergeordneten Subnetzgruppe angegeben werden.

Nachdem ein untergeordnetes Subnetz aus einer Subnetzgruppe erstellt wurde, weist IPAM einen CIDR 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 daraus und die Referenz des übergeordneten Subnetzes wird im Status des untergeordneten Subnetzes aktualisiert.

Im folgenden Beispiel wird für das Subnetz CIDR aus der default-vpc-zone1-Gruppe angefordert und im Status wird ein übergeordnetes platform/default-vpc-zone1-root-cidr zugewiesen.

apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
...
  labels:
    ipam.gdc.goog/vpc: default-vpc
  name: default-vpc-default-node-subnet
  namespace: platform
...
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
...

Regeln für das Referenzieren einer Subnetzgruppe als übergeordnetes Element

1. Wenn Sie auf eine Subnetzgruppe als übergeordnetes Element verweisen, muss der Ersteller des untergeordneten Subnetzes die Berechtigung „use“ (Verwenden) für alle Subnetze in der Subnetzgruppe haben.
2. 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 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 eine vollständige CIDR anzugeben, geben Sie die erforderliche Präfixlänge im Feld spec.ipv4Request.prefixLength an. Weisen Sie Ihren CIDR-Block dynamisch zu, wenn das System IP-Adressen automatisch an Ihre Subnetze delegieren soll. 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 Datensegment des Netzwerks erstellt wurden. Wenden Sie sich an Ihre Infrastrukturbetreibergruppe, um Informationen zu IPv6-Bereichen für andere Netzwerke in Ihrem GDC-Universum zu erhalten. Weitere Informationen zu IPv4-Bereichen finden Sie unter IPv4-Nutzung und -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 für externe Netzwerke beworben, 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. Sie können externe IPv4-Adressen für Ressourcen auf folgende Weise bereitstellen:

• Eigene externe IP-Adressen verwenden (Bring your own IP, BYOIP): Sie stellen diese externen IP-Adressen für Ihre Organisation bereit. Externe BYOIP-IP-Adressen können sich mit anderen Organisationen überschneiden, sofern sie nicht mit demselben externen Netzwerk verbunden sind.
• Von IO 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 Infrastrukturbetreibergruppe ist der Anbieter der Konnektivität für dieses Netzwerk.

Interne IP-Adresse

Interne IP-Adressen sind nicht direkt von außerhalb von GDC erreichbar und können nicht öffentlich weitergeleitet werden. 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 eine spezielle Art von externen Adressen, die immer auf das gesamte GDC-Universum beschränkt sind. GDC verwendet Anycast-IP-Adressen zusammen mit dem Border Gateway Protocol (BGP), um den Traffic an die nächstgelegene oder leistungsstärkste Zone weiterzuleiten. Jeder globalen 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. In jeder Zone wird dieselbe Anycast-IP-Adresse beworben, aber Ihr Netzwerk wählt die beste anhand seiner Routingregeln aus. Wenn eine Zone ausfällt, wird ihre IP-Adresse zurückgezogen und der Traffic in Ihrem Netzwerk wird automatisch an eine andere Zone weitergeleitet. Dieses automatische Routing sorgt für eine nahtlose Verbindung, auch bei Ausfällen.

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 der Tabelle Gültige IPv4-Bereiche.

Öffentliche IP-Adresse

Öffentliche IP-Adressen können über das Internet weitergeleitet werden. In GDC können externe IP-Adressen öffentlich oder privat sein. Sie können öffentliche IPv4-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-Nutzung und ‑Einschränkungen

Für jedes Netzwerk in Ihrem GDC-Universum gelten einige Einschränkungen bei der Verwendung von IPv4-Adressbereichen, die Sie bei der Zuweisung von IP-Adressen berücksichtigen müssen. IPv6-Adressbereiche werden in der Standard-VPC und im Datensegment des Netzwerks nicht unterstützt. Wenden Sie sich an Ihre Infrastrukturbetreibergruppe, um Informationen zu IPv6-Bereichen in anderen Netzwerken zu erhalten.

Einschränkungen für alle IPv4-Subnetze

Diese Einschränkungen gelten für VPC-Netzwerk-Subnetze und Subnetze für externe Netzwerksegmente.

• Alle Subnetze müssen eindeutige gültige CIDR-Blöcke sein.
• Nachdem Sie ein Subnetz erstellt haben, kann es nicht mehr vergrößert, ersetzt oder verkleinert werden.
• GDC erzwingt keine Begrenzung für die Größe eines CIDR. 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 Sie ein ungültiges Subnetz auswählen, empfehlen wir, die maximale Subnetzgröße auf /8 zu beschränken.

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

  Hinweis :Ein Peering-Netzwerk ist ein Netzwerk, in dem Netzwerkrouten ausgetauscht werden. Dazu gehören externe Kundennetzwerke, externe Netzwerksegmente von Organisationen in einer gemeinsamen Interconnect-Gruppe und VPC-Netzwerke mit Peering. Beispielsweise sind die Infra-VPC und die Standard-VPC Peer-Netzwerke.

• GDC erstellt entsprechende Routen für Subnetze. Für VPC-Netzwerk-Subnetze werden Routen im virtuellen Netzwerk-Stack Ihrer Organisation erstellt. Für Subnetze des externen Netzwerksegments werden Routen in der Routingtabelle des externen Peering-Netzwerks erstellt.

• Prüfen Sie, ob Subnetze mit lokalen IP-Adressen in Konflikt stehen, wenn Sie Ihr VPC-Netzwerk über 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. Beispielsweise ist 192.0.0.0/8 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.

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 diese 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: 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. Bei GDC Air-Gapped wird keine Verbindung zum Internet vorausgesetzt. Daher werden in GDC Air-Gapped 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 dafür sorgen, dass sie in externen Netzwerken keine 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. Außerdem hat die Infrastrukturbetreibergruppe möglicherweise reservierte Bereiche, die von Ihrer Organisation nicht verwendet werden können. Diese Bereiche unterscheiden sich je nach GDC-Universum 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-Infrastruktur	Ein global reservierter CIDR, der vom GDC-System verwendet wird. Wenn dieser Bereich für das Feld zone-infra-cidr des CIQ nicht angegeben ist, verwendet GDC standardmäßig 172.16.0.0/12 als GDC-Infrastrukturbereich.
Universumspezifische Bereiche	Zusätzliche Bereiche, die von der Infrastrukturbetreibergruppe reserviert werden.
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
Übertragungsadresse	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.

IAM-Berechtigungen für Subnetze

Google Distributed Cloud mit Air Gap unterstützt eine Vielzahl von IAM-Berechtigungen für die Verwaltung von Subnetzen.

• Subnet Organization Admin (global): Verwaltet mehrere Zonensubnetze innerhalb der Organisation. Bitten Sie Ihren Organisations-IAM-Administrator, Ihnen die Clusterrolle „Subnet Organization Admin“ (subnet-org-admin) zuzuweisen.
• Subnetz-Organisationsadministrator:Verwaltet zonale Subnetze innerhalb der Organisation. Bitten Sie Ihren Organisations-IAM-Administrator, Ihnen die Clusterrolle „Subnet Organization Admin“ (subnet-org-admin) zuzuweisen.
• Subnetz-Projektadministrator (global): Verwaltet mehrere zonale Subnetze in Projekten. Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Subnetz-Projektadministrator“ (subnet-project-admin) zuzuweisen.
• Subnetz-Projektadministrator:Verwaltet zonale Subnetze in Projekten. Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Subnetz-Projektadministrator“ (subnet-project-admin) zuzuweisen.
  • Diese Rolle hat die Berechtigung, alle Subnetze im Projekt-Namespace zu lesen und die meisten Subnetze in den Projekt-Namespaces zu erstellen, zu aktualisieren und zu löschen. Diese Rolle gewährt jedoch keine Berechtigung zum Erstellen, Aktualisieren oder Löschen der Subnetze des Stammtyps (subnet.Spec.Type == Root).
• Subnet Project Operator:Verwaltet automatisch zugewiesene Subnetze vom Typ „Leaf“ in Projekten. Bitten Sie Ihren Organisations-IAM-Administrator, Ihnen die Rolle „Subnetzprojekt-Operator“ (subnet-project-operator) zuzuweisen.
  • Diese Rolle ist berechtigt, alle Subnetze im Projekt-Namespace zu lesen und nur die automatisch zugewiesenen Leaf-Subnetze in den Projekt-Namespaces zu erstellen, zu aktualisieren und zu löschen. Diese Rolle gewährt nicht die Berechtigung, die folgenden Subnetze zu erstellen, zu aktualisieren oder zu löschen:
    • Subnetze vom Typ „Root“ oder „Branch“ (subnet.Spec.Type == Root || subnet.Spec.Type == Branch)
    • Netzwerk-Subnetze (subnet.Spec.NetworkSpec != nil)
    • Subnetze mit dediziertem CIDR (subnet.Spec.Ipv4Request.CIDR != nil || subnet.Spec.Ipv6Request.CIDR != nil)
• Subnet Platform Viewer:Ruft Subnetze im Namespace platform ab. Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Subnet Platform Viewer“ (subnet-platform-viewer) zuzuweisen.
• Wenn Sie ein freigegebenes Subnetz im Plattform-Namespace als übergeordnetes Element verwenden möchten, um ein Subnetz innerhalb des Projekts zuzuweisen, bitten Sie den IAM-Administrator Ihrer Organisation, Ihnen die Rolle shared-subnet-user zuzuweisen.
• Damit ein dediziertes Subnetz im Plattform-Namespace als übergeordnetes Element zum Zuweisen von Subnetzen innerhalb des Projekts verwendet werden kann, muss subnet-org-admin ein Subnetz erstellen oder aktualisieren und die Annotation "ipam.gdc.goog/subnet-delegation-role": auto dafür festlegen. Bitten Sie dann Ihren IAM-Administrator der Organisation, dem Nutzer die Rolle <subnetName>-user zuzuweisen.
• Damit eine Subnetzgruppe im Plattform-Namespace für die projektinterne Subnetzzuweisung aktiviert werden kann, muss die subnet-org-admin alle Subnetze in der Gruppe erstellen oder aktualisieren. Für jedes Subnetz muss die Anmerkung "ipam.gdc.goog/subnet-delegation-role": auto festgelegt werden. Bitten Sie dann den IAM-Administrator der Organisation, die Rolle <subnetName>-user für jedes Subnetz in der Gruppe zuzuweisen.

Nächste Schritte

• Netzwerkübersicht
• IP-Adressen für Arbeitslasten bereitstellen
• Eigene externe IP-Adressen verwenden
• Übersicht über mehrere Zonen