Diese Seite wurde von der Cloud Translation API übersetzt.

Eigene IP-Adressen mit externen Subnetzen verwenden

Auf dieser Seite wird beschrieben, wie Sie zusätzliche Subnetze im Datensegment des Netzwerks Ihrer Organisation erstellen, um Ihre externen Netzwerkanforderungen zu erfüllen. Sie müssen Subnetze hinzufügen, damit Ihre externen Dienste wie Egress-NAT (Network Address Translation) und externe Load Balancer über eine ausreichende Anzahl von IP-Adressen verfügen, um ihre Netzwerkanforderungen für die Verbindung mit externen Netzwerken außerhalb Ihrer Organisation zu erfüllen.

Auf dieser Seite werden mehrere Aufgaben beschrieben, die nicht in der angegebenen Reihenfolge ausgeführt werden müssen:

Zonales Zweigsubnetz für externe Dienste erstellen: Diese Aufgabe ist nützlich, um die vorhandenen externen IP-Adressen Ihrer Zone weiter zu organisieren oder Diensten zuzuweisen.
Blatt-Subnetz für einen einzelnen Dienst erstellen: Diese Aufgabe ist nützlich, wenn Sie einen neuen Dienst haben, der noch keine IP-Adresse hat.
Zonales Subnetz aus globalem IP-Adressbereich zuweisen: Diese Aufgabe ist nützlich, wenn in Ihrer Zone nicht mehr genügend externe IP-Adressen verfügbar sind.
Globales Stamm-Subnetz ohne Zonen-Zuweisung aufteilen: Diese Aufgabe ist nützlich, um die externen IP-Adressen auf dem globalen API-Server weiter zu organisieren, bevor sie einer Zone zugewiesen werden.
Neues globales Subnetz für den Netzwerk-Root-Bereich hinzufügen: Diese Aufgabe ist nützlich, wenn Ihr Data Network Segment nicht mehr genügend globalen externen IP-Adressraum hat, der Ihren Zonen zugewiesen werden kann.

Eine Übersicht über Subnetze und ihre Konzepte, bevor Sie die Aufgaben auf dieser Seite ausführen, finden Sie unter Subnetze und IP-Adressen.

Diese Seite richtet sich an Netzwerkadministratoren in der Gruppe „Plattformadministrator“ und Anwendungsentwickler in der Gruppe „Anwendungsoperator“, die für die Verwaltung des Netzwerkverkehrs ihrer Organisation verantwortlich sind. Weitere Informationen finden Sie in der Dokumentation zu Zielgruppen für GDC-Air-Gap-Umgebungen.

Hinweise

Bitten Sie Ihren Organisations-IAM-Administrator, Ihnen die IAM-Rolle „Subnet Organization Admin“ (subnet-org-admin) zuzuweisen, um die Berechtigung zum Erstellen von Subnetzen zu erhalten. Diese Rolle ist nicht an einen Namespace gebunden.

Zonales Branch-Subnetz für externe Dienste erstellen

Sie können ein zonales externes Subnetz aus dem vorhandenen zonalen Stamm-Subnetz der Zone erstellen, um IP-Adressen in Ihrem zonalen Datensegment weiter zu unterteilen. Sie müssen diesen Subnetztyp im Namespace platform erstellen. Wenn im übergeordneten zonalen Stamm-Subnetz nicht genügend IP-Adressen verfügbar sind, weisen Sie zuerst ein weiteres zonales Subnetz aus dem globalen IP-Adressbereich zu und kehren Sie dann zu diesem Verfahren zurück.

Erstellen Sie in einem Terminalfenster das neue externe Subnetz auf dem zonalen Management-API-Server:
```
kubectl -kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
  name: SUBNET_NAME
  namespace: platform
spec:
  ipv4Request:
    prefixLength: CIDR_PREFIX_LENGTH
  networkSpec:
    enableGateway: true
    enableVLANID: false
  parentReference:
    name: PARENT_SUBNET_NAME
    namespace: platform
  type: Branch
EOF
```
Ersetzen Sie Folgendes:
- MANAGEMENT_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei Ihres Management-API-Servers. Weitere Informationen finden Sie unter Zonale Management-API-Serverressourcen.
- SUBNET_NAME: der Name Ihres neuen Netzwerk-Subnetzes.
- CIDR_PREFIX_LENGTH: Die CIDR-Präfixlänge des neuen Subnetzes, das dynamisch zugewiesen wird, z. B. 20. Wenn Sie den CIDR-Block statisch festlegen möchten, ersetzen Sie das Feld prefixLength durch das Feld cidr und legen Sie dann den CIDR-Block fest, z. B. 10.0.10.0/27.
- PARENT_SUBNET_NAME: der Name des übergeordneten Subnetzes, z. B. data-external-zone0-cidr. Das übergeordnete Subnetz ist in der Regel ein zonales Stamm-Subnetz im Datensegment.
Weitere Informationen finden Sie in der API-Referenzdokumentation zur Subnet-Ressource.

Sie können Ihre zonalen Subnetze weiter unterteilen oder ein Leaf-Subnetz erstellen, um einem externen Dienst direkt eine einzelne IP-Adresse zuzuweisen.

Blatt-Subnetz für einen einzelnen Dienst erstellen

Sie müssen ein Leaf-Subnetz erstellen, um Ihrem Dienst eine einzelne IP-Adresse zuzuweisen. Dieses Blatt-Subnetz muss den Feldwert type: Leaf haben und sich im selben Projekt-Namespace wie Ihr externer Dienst befinden, z. B. ein externer Load-Balancer oder Egress-NAT.

Für Ihr Leaf-Subnetz muss ein prefixLength-Wert von 32 konfiguriert sein, da nur eine einzelne IP-Adresse zugewiesen werden soll. Der Wert parentReference verweist auf ein zuvor zugewiesenes Subnetz, z. B. das übergeordnete zonale Subnetz, das Sie in Zonales Zweigsubnetz für Arbeitslasten erstellen erstellt haben.

Erstellen Sie in einem Terminalfenster das untergeordnete Subnetz auf dem Management-API-Server:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/allocation-preference: default
    ipam.gdc.goog/network-segment: data
  name: SUBNET_NAME
  namespace: PROJECT_NAMESPACE
spec:
  ipv4Request:
    prefixLength: 32
  parentReference:
    name: PARENT_SUBNET
    namespace: platform
  type: Leaf
EOF
```
Ersetzen Sie Folgendes:
- MANAGEMENT_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei Ihres Management-API-Servers. Weitere Informationen finden Sie unter Zonale Management-API-Serverressourcen.
- SUBNET_NAME: der Name für das untergeordnete Subnetz.
- PROJECT_NAMESPACE: Der Projekt-Namespace, der Ihrem Projekt entspricht, in dem sich Ihre Dienste befinden.
- PARENT_SUBNET: der Name des übergeordneten Subnetzes, aus dem dieses untergeordnete Subnetz seine IP-Adresse bezieht.

Ihre individuelle IP-Adresse kann jetzt von Ihrem externen Dienst verwendet werden. Weitere Informationen zum Konfigurieren der IP-Adresse für Ihren Dienst finden Sie in der entsprechenden Dienstdokumentation, z. B. unter Externe Load-Balancer konfigurieren.

Zonales Subnetz aus globalem IP-Adressbereich zuweisen

Wenn in Ihrer Zone nicht genügend IP-Adressen für Ihre externen Dienste aus dem vorhandenen IP-Adressbereich des zonalen Stamm-Subnetzes verfügbar sind, können Sie zusätzliche IP-Adressen aus dem globalen IP-Adress-Stammbereich zuweisen.

Führen Sie die folgenden Schritte für das Datensegment im Namespace platform aus:

Beschreiben Sie in einem Terminalfenster alle Stamm-Subnetze des Datensicherheitssegments und prüfen Sie die verfügbaren CIDRs:

kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
    --label ipam.gdc.goog/network-segment=data,ipam.gdc.goog/usage=network-root-range

Ersetzen Sie GLOBAL_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des globalen API-Servers. Weitere Informationen finden Sie unter Globale API-Serverressourcen. Die Labels sind konstant und müssen gleich bleiben.

Die Ausgabe sieht etwa so aus:

Name:         data-external-root-cidr
Namespace:    platform
Labels:       ipam.gdc.goog/allocation-preference=default
              ipam.gdc.goog/subnet-group=data-external-root-group
              ipam.gdc.goog/usage=network-root-range
              ipam.gdc.goog/network-segment=data
Annotations:  <none>
API Version:  ipam.global.gdc.goog/v1
Kind:         Subnet
Metadata:
  Creation Timestamp:  2025-06-18T23:05:38Z
  Finalizers:
    global-subnet-finalizer
  Generation:        1
  Resource Version:  439434
  UID:               5ed1c51a-b5ee-473e-a185-8e065a87ae8f
Spec:
  ipv4Request:
    Cidr:                10.252.0.0/14
  Propagation Strategy:  None
  Type:                  Root
Status:
  Children Refs:
    Name:       data-external-zone1-root-cidr
    Namespace:  platform
    Type:       SingleSubnet
  Conditions:
    Last Transition Time:  2025-06-18T23:05:38Z
    Message:               IP allocation finished successfully
    Observed Generation:   1
    Reason:                AllocationSucceeded
    Status:                True
    Type:                  Ready
  ipv4Allocation:
    Available CIDRs:
      10.254.0.0/15
      10.253.0.0/16
    Cidr:  10.252.0.0/14
Events:    <none>

Notieren Sie sich die Status.ipv4Allocation.Available CIDRs-Werte als die verfügbaren CIDRs, auf die im nächsten Schritt verwiesen wird. In der vorherigen Ausgabe sind die CIDR-Bereiche 10.254.0.0/15 und 10.253.0.0/16 verfügbar. Je nach Anzahl der Root-Subnetze kann es in Ihrer Ausgabe mehrere Subnetze geben. Notieren Sie sich daher alle verfügbaren CIDRs und das Subnetz, aus dem die verfügbare CIDR stammt.

Vergleichen Sie den größten verfügbaren CIDR-Block, den Sie im vorherigen Schritt notiert haben, mit der Größe des CIDR-Blocks, den Sie Ihrer Zone zuweisen müssen. Wenn der größte verfügbare CIDR-Bereich nicht groß genug ist, um das neue Subnetz zuzuweisen, fügen Sie ein neues globales Subnetz für den Netzwerkstammbereich hinzu, bevor Sie fortfahren. Notieren Sie sich das übergeordnete Subnetz, aus dem Sie das CIDR für Ihr neues Subnetz beziehen möchten.

Wenn Sie beispielsweise ein /13-CIDR benötigen, die verfügbaren CIDRs jedoch nur /15 und /16 enthalten, müssen Sie ein neues globales Subnetz für den Netzwerkstammbereich erstellen. Wenn Sie ein /15-Subnetz benötigen, können Sie ein neues zonales Subnetz aus dem vorhandenen /15-CIDR-Bereich zuweisen.
Erstellen Sie das neue Subnetz auf dem globalen API-Server:
```
kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: zone-network-root-range
  name: SUBNET_NAME
  namespace: platform
spec:
  ipv4Request:
    prefixLength: CIDR_PREFIX_LENGTH
  zone: ZONE_NAME
  propagationStrategy: SingleZone
  type: Branch
  parentReference:
    name: PARENT_SUBNET_NAME
    namespace: ORG_NAME
EOF
```
Ersetzen Sie Folgendes:
- GLOBAL_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei des globalen API-Servers. Weitere Informationen finden Sie unter Globale API-Serverressourcen.
- SUBNET_NAME: der Name des neuen Subnetzes.
- CIDR_PREFIX_LENGTH: Die CIDR-Präfixlänge des neuen Subnetzes, das dynamisch zugewiesen wird, z. B. 20. Wenn Sie den CIDR-Block statisch festlegen möchten, ersetzen Sie das Feld prefixLength durch das Feld cidr und legen Sie dann den CIDR-Block fest, z. B. 10.0.10.0/27.
- ZONE_NAME: die Zone, für die das Subnetz zugewiesen werden soll, z. B. zone1.
- PARENT_SUBNET_NAME: der Name des übergeordneten Subnetzes, z. B. data-external-root-cidr, oder des neuen globalen Subnetzes für den Netzwerk-Root-Bereich, das Sie erstellt haben.
- ORG_NAME: der Name der Organisation.
Weitere Informationen finden Sie in der API-Referenzdokumentation zur globalen Ressource Subnet.

Prüfen Sie, ob das Subnetz bereit und auf dem globalen API-Server verfügbar ist. Dazu muss der Status Ready vom Typ true sein:

kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG get subnet --namespace platform \
    SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

Die Ausgabe sieht etwa so aus:

status:
  conditions:
  - lastTransitionTime: "2025-06-06T07:28:48Z"
    message: IP allocation finished successfully
    observedGeneration: 1
    reason: AllocationSucceeded
    status: "True"
    type: Ready

Prüfen Sie, ob das zonale Subnetz auf dem zonalen Management-API-Server erstellt wurde und sein Status vom Typ Ready ist:true
```
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet --namespace platform \
    SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
```
Ersetzen Sie MANAGEMENT_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig-Datei Ihres Management-API-Servers. Weitere Informationen finden Sie unter Zonale Management-API-Serverressourcen.

Die Ausgabe sieht etwa so aus:
```
status:
  conditions:
  - lastTransitionTime: "2025-06-06T07:29:34Z"
    message: IP allocation finished successfully
    observedGeneration: 1
    reason: AllocationSucceeded
    status: "True"
    type: Ready
```
Aus diesem neuen zonalen Subnetz können Sie weitere zonale untergeordnete Subnetze erstellen oder einzelne IP-Adressen direkt einem externen Dienst zuweisen.

Globales Stamm-Subnetz ohne Zonen-Zuweisung aufteilen

Wenn Sie Ihren global zugänglichen IP-Adressbereich weiterhin über das globale Stamm-Subnetz organisieren möchten, ohne die IP-Adressen Ihren zonenbasierten externen Diensten zuzuweisen, erstellen Sie ein globales Subnetz und definieren Sie keine Weiterleitungsstrategie in der benutzerdefinierten Ressource Subnet.

Führen Sie die folgenden Schritte im Namespace platform aus, um Ihr globales Stamm-Subnetz nur im globalen Bereich aufzuteilen:

Beschreiben Sie in einem Terminalfenster alle Stamm-Subnetze des Datensicherheitssegments und prüfen Sie die verfügbaren CIDRs:

kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
    --label ipam.gdc.goog/network-segment=data,ipam.gdc.goog/usage=network-root-range

Die Ausgabe sieht etwa so aus:

Name:         data-external-root-cidr
Namespace:    platform
Labels:       ipam.gdc.goog/allocation-preference=default
              ipam.gdc.goog/subnet-group=data-external-root-group
              ipam.gdc.goog/usage=network-root-range
              ipam.gdc.goog/network-segment=data
Annotations:  <none>
API Version:  ipam.global.gdc.goog/v1
Kind:         Subnet
Metadata:
  Creation Timestamp:  2025-06-18T23:05:38Z
  Finalizers:
    global-subnet-finalizer
  Generation:        1
  Resource Version:  439434
  UID:               5ed1c51a-b5ee-473e-a185-8e065a87ae8f
Spec:
  ipv4Request:
    Cidr:                10.252.0.0/14
  Propagation Strategy:  None
  Type:                  Root
Status:
  Children Refs:
    Name:       data-external-zone1-root-cidr
    Namespace:  platform
    Type:       SingleSubnet
  Conditions:
    Last Transition Time:  2025-06-18T23:05:38Z
    Message:               IP allocation finished successfully
    Observed Generation:   1
    Reason:                AllocationSucceeded
    Status:                True
    Type:                  Ready
  ipv4Allocation:
    Available CIDRs:
      10.254.0.0/15
      10.253.0.0/16
    Cidr:  10.252.0.0/14
Events:    <none>

Vergleichen Sie den größten verfügbaren CIDR-Bereich, den Sie im vorherigen Schritt notiert haben, mit der Größe des CIDR-Bereichs, den Sie Ihrem neuen globalen Subnetz zuweisen müssen. Wenn der größte verfügbare CIDR-Bereich nicht groß genug ist, um Ihr neues Subnetz zuzuweisen, fügen Sie ein neues globales Subnetz für den Netzwerkstammbereich hinzu, bevor Sie fortfahren. Notieren Sie sich das übergeordnete Subnetz, aus dem Sie das CIDR für Ihr neues Subnetz beziehen möchten.

Wenn Sie beispielsweise ein /13-CIDR benötigen, die verfügbaren CIDRs jedoch nur /15 und /16 enthalten, müssen Sie ein neues globales Subnetz für den Netzwerkstammbereich erstellen. Wenn Sie ein /15-Subnetz benötigen, können Sie das neue globale Subnetz aus dem vorhandenen /15-CIDR-Bereich zuweisen.
Erstellen Sie das neue Subnetz auf dem globalen API-Server:
```
kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: zone-network-root-range
  name: SUBNET_NAME
  namespace: platform
spec:
  ipv4Request:
    prefixLength: CIDR_PREFIX_LENGTH
  propagationStrategy: None
  type: Branch
  parentReference:
    name: PARENT_SUBNET_NAME
    namespace: ORG_NAME
EOF
```
Ersetzen Sie Folgendes:
- GLOBAL_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei des globalen API-Servers. Weitere Informationen finden Sie unter Globale API-Serverressourcen.
- SUBNET_NAME: der Name des neuen Subnetzes.
- CIDR_PREFIX_LENGTH: Die CIDR-Präfixlänge des neuen Subnetzes, das dynamisch zugewiesen wird, z. B. 20. Wenn Sie den CIDR-Block statisch festlegen möchten, ersetzen Sie das Feld prefixLength durch das Feld cidr und legen Sie dann den CIDR-Block fest, z. B. 10.0.10.0/27.
- PARENT_SUBNET_NAME: der Name des übergeordneten Subnetzes, z. B. data-external-root-cidr, oder des neuen globalen Subnetzes des Netzwerk-Root-Bereichs, das Sie erstellt haben.
- ORG_NAME: der Name der Organisation.
Weitere Informationen finden Sie in der API-Referenzdokumentation zur globalen Ressource Subnet.

Prüfen Sie, ob das Subnetz bereit und auf dem globalen API-Server verfügbar ist. Dazu muss der Status Ready vom Typ true sein:

kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG get subnet --namespace platform \
    SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

Die Ausgabe sieht etwa so aus:

status:
  conditions:
  - lastTransitionTime: "2025-06-06T07:28:48Z"
    message: IP allocation finished successfully
    observedGeneration: 1
    reason: AllocationSucceeded
    status: "True"
    type: Ready

Das neue globale Subnetz für Ihre Organisation im Datensicherheitssegment ist verfügbar. Sie können ein Subnetz für eine bestimmte Zone erstellen.

Neues globales Subnetz für den Netzwerk-Root-Bereich hinzufügen

Globale Subnetze mit dem Label ipam.gdc.goog/usage: network-root-range enthalten den CIDR für alle Zonen des Netzwerks. Wenn das CIDR aufgebraucht ist, müssen Sie im globalen API-Server ein neues Subnetz für den Netzwerkstammbereich erstellen. Bei Bedarf können Sie mehrere globale Stamm-Subnetze erstellen.

So erstellen Sie ein neues Subnetz für den Netzwerkstammbereich:

Erstellen Sie in einem Terminalfenster das neue globale Subnetz für den Netzwerk-Root-Bereich für das Datensegment im Namespace platform:
```
kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
apiVersion: ipam.global.gdc.goog/v1
kind: Subnet
metadata:
  labels:
    ipam.gdc.goog/network-segment: data
    ipam.gdc.goog/usage: network-root-range
  name: SUBNET_NAME
  namespace: platform
spec:
  ipv4Request:
    cidr: NEW_CIDR
  type: Root
EOF
```
Ersetzen Sie Folgendes:
- GLOBAL_API_SERVER_KUBECONFIG: der Pfad zur kubeconfig-Datei des globalen API-Servers. Weitere Informationen finden Sie unter Globale API-Serverressourcen.
- SUBNET_NAME: der Name des neuen Subnetzes.
- NEW_CIDR: der neue CIDR-Bereich für das Subnetz. Dieser CIDR darf sich nicht mit einem CIDR in allen vorhandenen Subnetzen mit dem Label ipam.gdc.goog/usage: network-root-range auf demselben globalen API-Server überschneiden.

Dieses neue globale Root-Bereichssubnetz kann innerhalb des globalen API-Servers unterteilt oder einer bestimmten Zone zugewiesen werden.

Eigene IP-Adressen mit externen Subnetzen verwenden Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweise

Zonales Branch-Subnetz für externe Dienste erstellen

Blatt-Subnetz für einen einzelnen Dienst erstellen

Zonales Subnetz aus globalem IP-Adressbereich zuweisen

Globales Stamm-Subnetz ohne Zonen-Zuweisung aufteilen

Neues globales Subnetz für den Netzwerk-Root-Bereich hinzufügen

Nächste Schritte

Eigene IP-Adressen mit externen Subnetzen verwenden