Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

IP-Adressen für Arbeitslasten bereitstellen

Erstellen Sie zusätzliche Subnetze in der internen Virtual Private Cloud (VPC) oder der Standard-VPC Ihrer Organisation, um Ihre internen Netzwerkanforderungen zu erfüllen. Fügen Sie beispielsweise VPC-Subnetze hinzu, um sicherzustellen, dass Ihre internen Arbeitslasten wie virtuelle Maschinen (VMs) und Container genügend IP-Adressen haben.

Auf dieser Seite werden mehrere Aufgaben beschrieben, die nicht in einer bestimmten 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 weiter zu organisieren oder Arbeitslasten zuzuweisen.
Blatt-Subnetz für eine einzelne Arbeitslast erstellen: Diese Aufgabe ist nützlich, wenn Sie eine neue Arbeitslast haben, die noch keine IP-Adresse hat.
Zonales Subnetz aus globalem IP-Adressbereich zuweisen: Diese Aufgabe ist nützlich, wenn Ihre Zone nicht mehr über genügend internen IP-Adressbereich verfügt.
Globales Stamm-Subnetz ohne Zonenzuweisung aufteilen: Diese Aufgabe ist nützlich, um die internen IP-Adressen im globalen API-Server weiter zu organisieren, bevor sie einer Zone zugewiesen werden.
Neues globales Subnetz für den Netzwerkstammbereich hinzufügen: Diese Aufgabe ist nützlich, wenn Ihre Standard-VPC nicht mehr genügend globalen internen IP-Adressbereich hat, um ihn Ihren Zonen zuzuweisen.

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

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

Hinweis

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

Zonales Zweigstellen-Subnetz für Arbeitslasten erstellen

Wenn Sie IP-Adressen in Ihrer zonalen Standard-VPC weiter unterteilen möchten, können Sie ein zonales internes Subnetz aus dem vorhandenen zonalen Root-Subnetz der Zone erstellen. Sie müssen diesen Subnetztyp im Namespace platform erstellen.

Wenn im übergeordneten zonalen Root-Subnetz nicht genügend IP-Adressen verfügbar sind, weisen Sie ein weiteres zonales Subnetz aus dem globalen IP-Adressbereich zu, bevor Sie fortfahren.

Erstellen Sie in einem Terminalfenster das neue zonale Subnetz im 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 Verwaltungs-API-Servers. Weitere Informationen finden Sie unter Zonale API-Serverressourcen für die Verwaltung.
- SUBNET_NAME: der Name Ihres neuen Netzwerksubnetzes.
- CIDR_PREFIX_LENGTH: die Präfixlänge für Ihr neues Subnetz, z. B. 27. In diesem Feld wird der nächste verfügbare IP-Adressbereich dieser Größe aus dem übergeordneten Subnetz dynamisch zugewiesen. Verwenden Sie das Feld prefixLength, wenn Sie nur die Größe des Subnetzes und nicht den spezifischen IP-Adressbereich berücksichtigen möchten.
  
  So weisen Sie stattdessen einen bestimmten IP-Adressbereich zu:
  1. Entfernen Sie die Zeile prefixLength: CIDR_PREFIX_LENGTH.
  2. Fügen Sie stattdessen eine cidr: "YOUR_CIDR_BLOCK"-Zeile hinzu, z. B. cidr: "10.0.10.0/27".
  Verwenden Sie das Feld cidr, wenn Sie einen strikten 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 Root-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 Blattsubnetz erstellen, um einer internen Arbeitslast direkt eine einzelne IP-Adresse zuzuweisen.

Blatt-Subnetz für eine einzelne Arbeitslast erstellen

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

Ihr Blatt-Subnetz muss mit dem prefixLength-Wert 32 konfiguriert sein, da es für die Zuweisung einer einzelnen IP-Adresse vorgesehen ist. Der Wert parentReference verweist auf ein zuvor zugewiesenes Subnetz, z. B. das übergeordnete zonale Subnetz, das Sie unter Zonales Zweigsubnetz für Arbeitslasten erstellen erstellt haben.

Erstellen Sie in einem Terminalfenster das Leaf-Subnetz im Verwaltungs-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 Verwaltungs-API-Servers. Weitere Informationen finden Sie unter Zonale API-Serverressourcen für die Verwaltung.
- SUBNET_NAME: der Name des Blatt-Subnetzes.
- 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 Blattsubnetz seine IP-Adresse bezieht.
- PARENT_NAMESPACE: der Namespace PROJECT_NAMESPACE oder platform.

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 einer statischen oder dynamischen IP-Adresse erstellen oder Internen Load Balancer für Containerarbeitslasten konfigurieren.

Zonales Subnetz aus globalem IP-Adressbereich zuweisen

Wenn Ihre Zone nicht genügend IP-Adressen für Ihre Arbeitslasten aus dem vorhandenen zonalen Stamm-Subnetz-IP-Adressbereich bereitstellt, können Sie zusätzliche IP-Adressen aus dem globalen IP-Adressstammbereich zuweisen.

Führen Sie die folgenden Schritte für das Standard-VPC-Netzwerk im Namespace platform aus, um ein zonales Subnetz aus dem globalen IP-Adressbereich zuzuweisen:

Beschreiben Sie in einem Terminalfenster alle Root-Subnetze des Standard-VPC und prüfen Sie die verfügbaren CIDR-Blöcke:

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 unverändert 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. Diese Werte sind die verfügbaren CIDR-Blöcke, 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 CIDR-Blöcke und ihre Quellsubnetze.

Vergleichen Sie den größten verfügbaren CIDR-Block aus dem vorherigen Schritt mit der Größe des CIDR-Blocks, der für Ihre Zone erforderlich ist. Wenn der größte verfügbare CIDR-Block 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-Block für Ihr neues Subnetz abrufen möchten.

Wenn Sie beispielsweise einen /13-CIDR-Block benötigen, die verfügbaren CIDRs aber nur /15 und /16 enthalten, müssen Sie ein neues globales Subnetz für den Netzwerkstammbereich hinzufügen. Wenn Sie ein /15-Subnetz benötigen, können Sie ein neues zonales Subnetz aus dem vorhandenen /15-CIDR-Block 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 das neue globale Subnetz für den Netzwerkstammbereich, 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 den Typ true haben:

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 im zonalen Verwaltungs-API-Server erstellt wurde und ob der Status Ready den Typ true hat:
```
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 Verwaltungs-API-Servers. Weitere Informationen finden Sie unter Zonale API-Serverressourcen für die Verwaltung.

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
```
In diesem neuen zonalen Subnetz können Sie weitere zonale untergeordnete Subnetze erstellen oder einer internen Arbeitslast direkt eine einzelne IP-Adresse zuweisen.

Globales Root-Subnetz ohne Zonenzuweisung aufteilen

Wenn Sie ein globales Subnetz weiter unterteilen möchten, ohne es einer Zone zuzuweisen, erstellen Sie ein globales Subnetz und lassen Sie die Propagierungsstrategie in der benutzerdefinierten Ressource Subnet weg. Dieser Ansatz ist nützlich, wenn Sie Ihren global zugänglichen IP-Adressbereich weiterhin über das globale Root-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 innerhalb des globalen Bereichs aufzuteilen:

Beschreiben Sie in einem Terminalfenster alle Root-Subnetze der Standard-VPC und prüfen Sie die verfügbaren CIDR-Blöcke:

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. Diese Werte sind die verfügbaren CIDR-Blöcke, 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 können in der Ausgabe mehrere Subnetze enthalten sein. Notieren Sie sich daher alle verfügbaren CIDR-Blöcke und das Subnetz, aus dem der verfügbare CIDR-Block 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-Block 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-Block für Ihr neues Subnetz abrufen möchten.

Wenn Sie beispielsweise einen /13-CIDR-Block benötigen, die verfügbaren CIDRs aber 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-Block 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 das neue globale Subnetz für den Netzwerkstammbereich, 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 den Typ true haben:

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 aus diesem neuen globalen übergeordneten Subnetz ein Subnetz für eine bestimmte Zone erstellen.

Neues globales Subnetz für Netzwerkstammbereich hinzufügen

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

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

Erstellen Sie in einem Terminalfenster das neue globale Subnetz für den Netzwerkstammbereich 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-Bereichs-Subnetz 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.

Hinweis

Zonales Zweigstellen-Subnetz für Arbeitslasten erstellen

Blatt-Subnetz für eine einzelne Arbeitslast erstellen

Zonales Subnetz aus globalem IP-Adressbereich zuweisen

Globales Root-Subnetz ohne Zonenzuweisung aufteilen

Neues globales Subnetz für Netzwerkstammbereich hinzufügen

Nächste Schritte

IP-Adressen für Arbeitslasten bereitstellen