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 eine ausreichende Anzahl von IP-Adressen haben, um die Netzwerkanforderungen in 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 die zugehörigen 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 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 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-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 Subnet-Ressource.

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, z. B. eine VM oder ein Container, befinden.

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/vpc: default-vpc
  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 Arbeitslasten befinden.
- PARENT_SUBNET: der Name des übergeordneten Subnetzes, aus dem dieses untergeordnete Subnetz seine IP-Adresse bezieht.

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-Arbeitslasten bereitstellen oder Containerarbeitslasten bereitstellen.

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 \
    --label 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 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 einen /13-CIDR benötigen, die verfügbaren CIDRs jedoch nur /15 und /16 enthalten, müssen Sie einen neuen globalen Subnetz-Stammbereich für das Netzwerk 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 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

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 Zonen-Zuweisung aufteilen

Wenn Sie ein globales Subnetz weiter unterteilen möchten, ohne es einer Zone für Ihre Arbeitslasten zuzuweisen, erstellen Sie ein globales Subnetz und definieren Sie keine Weiterleitungsstrategie in der benutzerdefinierten Ressource Subnet. 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 \
    --label 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>

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/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 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 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 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 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 Zonen-Zuweisung aufteilen

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

Nächste Schritte

IP-Adressen für Arbeitslasten bereitstellen