Diese Seite wurde von der Cloud Translation API übersetzt.

IP-Adressen für Arbeitslasten bereitstellen

Auf dieser Seite wird beschrieben, wie Sie zusätzliche Subnetze in der internen VPC (Virtual Private Cloud) oder der Standard-VPC Ihrer Organisation erstellen, um Ihre internen Netzwerkanforderungen zu erfüllen. Sie müssen ein VPC-Subnetz erstellen, damit Ihre internen Arbeitslasten wie VMs und Container genügend IP-Adressen haben, um die Anforderungen des internen Netzwerks 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 Arbeitslasten erstellen: Diese Aufgabe ist nützlich, um die vorhandenen internen IP-Adressen Ihrer Zone für Arbeitslasten zu organisieren oder zuzuweisen.
Blatt-Subnetz für eine einzelne Arbeitslast erstellen: Diese Aufgabe ist nützlich, wenn Sie eine neue Arbeitslast haben, für die noch keine IP-Adresse verwendet wird.
Zonales Subnetz aus globalem IP-Adressbereich zuweisen: Diese Aufgabe ist nützlich, wenn in Ihrer Zone nicht mehr genügend interner IP-Adressraum vorhanden ist.
Globales Stamm-Subnetz ohne Zonen-Zuweisung aufteilen: Diese Aufgabe ist nützlich, um die internen 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 Ihre Standard-VPC nicht mehr genügend globalen internen IP-Adressraum hat, um ihn Ihren Zonen zuzuweisen.

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 der Plattformadministratoren und Anwendungsentwickler in der Gruppe der Anwendungsoperatoren, die für die Verwaltung des Netzwerkverkehrs für ihre Organisation verantwortlich sind. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

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 Arbeitslasten erstellen

Sie können ein zonales internes Subnetz aus dem vorhandenen zonalen Stamm-Subnetz der Zone erstellen, um IP-Adressen in Ihrer zonalen Standard-VPC weiter zu unterteilen. Sie müssen diesen Subnetztyp im Namespace platform erstellen. Wenn im zonalen Stamm-Subnetz der übergeordneten Zone nicht genügend IP-Adressen verfügbar sind, müssen Sie ein weiteres zonales Subnetz aus dem globalen IP-Adressbereich zuweisen, bevor Sie fortfahren.

Erstellen Sie in einem Terminalfenster das neue zonale 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/vpc: default-vpc
  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 Präfixlänge für Ihr neues Subnetz, z. B. 27. In diesem Feld wird dynamisch der nächste verfügbare IP-Adressbereich dieser Größe aus dem übergeordneten Subnetz zugewiesen. Verwenden Sie das Feld prefixLength, wenn Sie sich nur für die Größe des Subnetzes und nicht für den spezifischen IP-Adressbereich interessieren.
  
  So weisen Sie stattdessen einen bestimmten IP-Bereich zu:
  1. Entfernen Sie die Zeile prefixLength: CIDR_PREFIX_LENGTH.
  2. Fügen Sie stattdessen eine cidr: "YOUR_CIDR_BLOCK"-Zeile ein, z. B. cidr: "10.0.10.0/27".
  Verwenden Sie das Feld cidr, wenn Sie einen strengen IP-Plan einhalten und einen genauen, vorhersehbaren IP-Adressbereich zuweisen müssen. Dieser Bereich muss ein gültiges und verfügbares Subnetz innerhalb des übergeordneten Subnetzes sein.
- PARENT_SUBNET_NAME: der Name des übergeordneten Subnetzes, z. B. default-vpc-zone0-cidr. Das übergeordnete Subnetz ist in der Regel ein zonales Stamm-Subnetz in der Standard-VPC.
Weitere Informationen finden Sie in der API-Referenzdokumentation zur Ressource Subnet.

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

Blatt-Subnetz für einen einzelnen Arbeitslast erstellen

Sie müssen ein Leaf-Subnetz erstellen, um Ihrer Arbeitslast eine einzelne IP-Adresse zuzuweisen. Dieses Blatt-Subnetz muss den Feldwert type: Leaf haben und sich im selben Projekt-Namespace wie Ihre Arbeitslastressource befinden, z. B. eine VM oder ein Container.

Für Ihr Leaf-Subnetz muss der prefixLength-Wert 32 konfiguriert sein, da nur eine einzelne IP-Adresse zugewiesen werden soll. Der Wert parentReference verweist auf ein zuvor zugewiesenes Subnetz, z. B. das zonale übergeordnete Subnetz, das Sie in Zonales untergeordnetes Subnetz 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/vpc: default-vpc
  name: SUBNET_NAME
  namespace: PROJECT_NAMESPACE
spec:
  ipv4Request:
    prefixLength: 32
  parentReference:
    name: PARENT_SUBNET
    namespace: PARENT_NAMESPACE
  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 Arbeitslasten befinden.
- PARENT_SUBNET: der Name des übergeordneten Subnetzes, aus dem dieses untergeordnete Subnetz seine IP-Adresse bezieht.
- PARENT_NAMESPACE: entweder PROJECT_NAMESPACE oder der Plattform-Namespace.

Ihre individuelle IP-Adresse kann jetzt von Ihren internen Arbeitslasten wie VMs und Containern verwendet werden. Weitere Informationen zum Konfigurieren der IP-Adresse für Ihre Arbeitslasten finden Sie unter VM mit statischer oder dynamischer IP-Adresse erstellen oder Internen Load-Balancer für Containerarbeitslasten konfigurieren.

Zonales Subnetz aus globalem IP-Adressbereich zuweisen

Wenn in Ihrer Zone nicht genügend IP-Adressen für Ihre Arbeitslasten 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 Standard-VPC-Netzwerk im Namespace platform aus:

Beschreiben Sie in einem Terminalfenster alle Stamm-Subnetze der Standard-VPC und prüfen Sie die verfügbaren CIDRs:

kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
    -l ipam.gdc.goog/vpc=default-vpc,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:         default-vpc-root-cidr
Namespace:    platform
Labels:       ipam.gdc.goog/allocation-preference=default
              ipam.gdc.goog/subnet-group=default-vpc-root-group
              ipam.gdc.goog/usage=network-root-range
              ipam.gdc.goog/vpc=default-vpc
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:       default-vpc-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. Dies sind 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. In der Ausgabe werden möglicherweise mehrere Subnetze angezeigt. Notieren Sie sich alle verfügbaren CIDRs und ihre Quellsubnetze.

Vergleichen Sie den größten verfügbaren CIDR aus dem vorherigen Schritt mit der Größe des CIDR, der für Ihre Zone erforderlich ist. 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 Netzwerk-Root-Bereich hinzu, bevor Sie fortfahren. Notieren Sie sich das übergeordnete Subnetz, aus dem Sie den CIDR für Ihr neues Subnetz abrufen möchten.

Wenn Sie beispielsweise einen /13-CIDR benötigen, die verfügbaren CIDRs jedoch nur /15 und /16 enthalten, müssen Sie einen neuen globalen Subnetz-Netzwerkstammbereich hinzufügen. 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/vpc: default-vpc
    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. default-vpc-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 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 einer internen Arbeitslast direkt eine einzelne IP-Adresse zuweisen.

Globales Stamm-Subnetz ohne Zonenaufteilung aufteilen

Wenn Sie ein globales Subnetz weiter unterteilen möchten, ohne es einer Zone zuzuweisen, erstellen Sie ein globales Subnetz und lassen Sie die Weiterleitungsstrategie in der benutzerdefinierten Ressource Subnet weg. Dieser Ansatz ist nützlich, wenn Sie Ihren global zugänglichen IP-Adressbereich weiterhin über das globale Stamm-Subnetz organisieren möchten, ohne die IP-Adressen einer Zone zuzuweisen.

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 der Standard-VPC und prüfen Sie die verfügbaren CIDRs:

kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
    -l ipam.gdc.goog/vpc=default-vpc,ipam.gdc.goog/usage=network-root-range

Die Ausgabe sieht etwa so aus:

Name:         default-vpc-root-cidr
Namespace:    platform
Labels:       ipam.gdc.goog/allocation-preference=default
              ipam.gdc.goog/subnet-group=default-vpc-root-group
              ipam.gdc.goog/usage=network-root-range
              ipam.gdc.goog/vpc=default-vpc
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:       default-vpc-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. Dies sind 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 aus dem vorherigen Schritt mit der Größe des CIDR-Blocks, der für Ihr neues globales Subnetz erforderlich ist. 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 den CIDR für Ihr neues Subnetz abrufen 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/vpc: default-vpc
    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. default-vpc-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

Das neue globale Subnetz für Ihre Organisation in der Standard-VPC ist verfügbar. Sie können ein Subnetz für eine bestimmte Zone aus diesem neuen globalen übergeordneten Subnetz 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 Netzwerk-Root-Bereich erstellen. Bei Bedarf können Sie mehrere globale Stamm-Subnetze erstellen.

So erstellen Sie ein neues Subnetz für den Netzwerk-Root-Bereich:

Erstellen Sie in einem Terminalfenster das globale Subnetz für den neuen Netzwerk-Root-Bereich für die Standard-VPC 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/vpc: default-vpc
    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.

IP-Adressen für Arbeitslasten bereitstellen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweise

Zonales Branch-Subnetz für Arbeitslasten erstellen

Blatt-Subnetz für einen einzelnen Arbeitslast erstellen

Zonales Subnetz aus globalem IP-Adressbereich zuweisen

Globales Stamm-Subnetz ohne Zonenaufteilung aufteilen

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

Nächste Schritte

IP-Adressen für Arbeitslasten bereitstellen