Privat genutzte öffentliche IP-Adressen für GKE konfigurieren

Autopilot Standard

In dieser Anleitung wird beschrieben, wie Sie privat genutzte öffentliche IP-Adressen für Pod-Adressblöcke von Google Kubernetes Engine (GKE) verwenden.

Privat verwendete öffentliche IP-Adressen (Privately Used Public IP, PUPI) sind Adressen, die Sie privat in Ihrem Google Cloud Virtual Private Cloud (VPC)-Netzwerk verwenden können. Diese IP-Adressen gehören nicht Google. Sie müssen diese öffentlichen IP-Adressen nicht besitzen, um sie privat verwenden zu können.

Übersicht

GKE-Cluster benötigen dedizierte IP-Adressbereiche für Knoten, Pods und Services. Wenn Ihre Infrastruktur wächst, kann der standardmäßige interne IP-Adressbereich (RFC 1918) erschöpft sein. Eine Möglichkeit, die Ausschöpfung von privaten RFC 1918-Adressen zu reduzieren, besteht darin, privat genutzte öffentliche IP-Adressen (Privately Used Public IPs; PUPIs) für den CIDR-Block des GKE-Pods zu verwenden. PUPIs bieten eine Alternative für Ihr GKE-Pod-Netzwerk, bei der private IP-Adressen für andere Clusterkomponenten reserviert werden.

Einzelner Cluster: Wenn Sie nur einen GKE-Cluster erstellen, können Sie PUPIs aktivieren, indem Sie privat verwendete externe IP-Adressbereiche aktivieren.

Mehrere Cluster: Wenn Sie mit mehreren GKE-Clustern arbeiten, die über VPC-Peering verbunden sind (ein gängiges Szenario für Dienstanbieter), benötigen Sie eine komplexere Konfiguration. Das folgende Diagramm zeigt ein Beispiel dafür, wie ein Unternehmen (Producer) einem Kunden (Nutzer) einen verwalteten Dienst mit PUPI mit VPC-Peering anbietet.

PUPI-Adressen für den CIDR-Block des GKE-Pods.

Das obige Diagramm beinhaltet folgende Überlegungen:

Primärer CIDR-Block: Ein Nicht-PUPI-CIDR-Block, der für Knoten und interne Load-Balancer (ILB) verwendet wird und VPCs nicht überlappen darf.
Sekundärer CIDR-Block für Producer: Ein PUPI-CIDR-Block, der für Pods verwendet wird (z. B. 45.45.0.0/16).
Sekundärer CIDR-Block für Nutzer: Jeder andere PUPI-CIDR-Block auf Kundenseite (z. B. 5.5.0.0/16)

Verwendung von PUPIs in einem Szenario mit Dienstanbietern

Der Dienstanbieter (Producer) führt seinen verwalteten Dienst in einem GKE-Cluster (gke-2) in seiner VPC (vpc-producer) aus. Dieser Cluster verwendet den PUPI-Bereich 45.0.0.0/8 für seine Pod-IP-Adressen.

Der Kunde (Nutzer) hat auch einen GKE-Cluster (gke-1) in seiner eigenen VPC (vpc-consumer) mit einem anderen PUPI-Bereich 5.0.0.0/8 für seine Pod-IP-Adressen.

Diese beiden VPCs sind über VPC-Peering verbunden, verwenden aber weiterhin standardmäßige private IP-Adressen (RFC 1918) für Knoten, Dienste und interne Load Balancer.

Kommunikation zwischen VPCs ermöglichen

Nutzer zu Producer: Standardmäßig teilt die VPC des Nutzers automatisch ihre RFC 1918-Routen (aber nicht PUPIs) mit dem Producer. Dadurch können Ressourcen in der VPC des Nutzers auf Dienste in der VPC des Producers zugreifen (in der Regel über interne Load-Balancer).
Producer zum Nutzer: Damit die Pods des Producers Ressourcen in der VPC des Nutzers erreichen können, ist eine explizite Konfiguration erforderlich.
Keine Überschneidung: Der Producer und der Nutzer müssen dafür sorgen, dass der PUPI-Bereich des Nutzers nicht mit IP-Adressen in der VPC des Producers in Konflikt steht.
Export/Import: Der Producer muss den Export seiner PUPI-Routen aktivieren und der Nutzer muss den Import dieser Routen über die Peering-Verbindung aktivieren.

Kommunikation aktivieren, wenn sich PUPI-Bereiche überschneiden

Wenn die VPC des Nutzers bereits denselben PUPI-Bereich wie der Producer verwendet, ist eine direkte Kommunikation von Producer-Pods nicht möglich. Stattdessen kann der Producer das IP-Masquerading aktivieren, bei dem die Pod-IP-Adressen hinter den Knoten-IP-Adressen des Producers ausgeblendet werden.

Die folgende Tabelle zeigt die Standard-Import- und Exporteinstellungen für jede VPC. Sie können Standard-VPC-Peering-Einstellungen mit dem Befehl gcloud compute networks peerings update ändern.

VPC-Netzwerk	Einstellungen importieren	Exporteinstellungen	Hinweise
Ersteller	Standardverhalten (deaktiviert): Subnetzrouten mit öffentlichen IP-Adressen werden nicht importiert Aktivieren: --import-subnet-routes-with-public-ip (über Peering)	Standardverhalten (aktiviert): Exportiert Subnetzrouten mit öffentlichen IP-Adressen Zum Deaktivieren: --no-export-subnet-routes-with-public-ip (über Peering)	Flags, die über Dienstnetzwerke gesteuert werden.
Nutzer	Deaktiviert (Standard)	Aktiviert (Standard)	Wird in der Regel vom Kunden verwaltet und muss nicht über das Dienstnetzwerk geändert werden

Diese Einstellungen führen zu Folgendem:

In der Producer-VPC werden alle Kundenrouten angezeigt.
In der Nutzer-VPC werden die PUPI-Routen, die auf dem Pod-Subnetz in der Producer-VPC konfiguriert sind, nicht angezeigt.
Traffic von den Producer-Pods zum vpc-consumer-Netzwerk muss hinter den Knotenadressen im Producer-Cluster übersetzt werden.

Vorbereitung

Achten Sie darauf, dass die folgenden Voraussetzungen und Konfigurationen erfüllt sind, um eine erfolgreiche Kommunikation zwischen VPC-Pods und einer anderen VPC einzurichten:

Ihr GKE-Cluster muss die folgenden Mindestanforderungen an die Version erfüllen:
- Autopilot-Cluster: GKE-Version 1.22 oder höher
- Standard-Cluster: GKE-Version 1.14 oder höher
Wählen Sie einen PUPI-Bereich aus, der nicht öffentlich routbar ist oder nicht Google gehört.
Die Knoten-IP-Adressen und der primäre IP-Adressbereich der beiden VPCs dürfen sich nicht überschneiden.
Wenn Sie eine direkte Pod-zu-Pod-Kommunikation zwischen der VPC des Kunden und dem verwalteten Dienst benötigen, gehen Sie so vor:
- Autopilot-Cluster: Konfigurieren Sie SNAT für PUPI, um die Pod-zu-Pod-Kommunikation zu ermöglichen. Sie benötigen keine zusätzliche Konfiguration.
- Standardcluster: Übersetzen Sie Pod-IP-Adressen mithilfe von SNAT in die entsprechenden Knoten-IP-Adressen. Aktivieren Sie SNAT für PUPI-Traffic. Weitere Informationen finden Sie unter Privat verwendete externe IP-Adressbereiche aktivieren.

Privat genutzte öffentliche IP-Adressen für GKE-Cluster konfigurieren

So konfigurieren Sie PUPI-Adressen für GKE-Cluster:

Zwei Virtual Private Cloud-Netzwerke konfigurieren
Ein Subnetz in jedem Virtual Private Cloud-Netzwerk konfigurieren
In jedem Subnetz einen PUPI-Adressbereich in einem sekundären Adressbereich konfigurieren
Eine geeignete Virtual Private Cloud-Peering-Beziehung zwischen den beiden Virtual Private Cloud-Netzwerken mit entsprechenden Import- und Exporteinstellungen herstellen
Prüfen Sie die Routen in jeder Virtual Private Cloud.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Verwenden Sie nur VPC-native Cluster.
Richten Sie die erforderlichen IPAM-Spezifikationen für das VPC-Peering ein.

Netzwerke und Cluster einrichten

VPC-Netzwerke erstellen

Erstellen Sie die folgenden beiden VPC-Netzwerke mit RFC-1918 als primären Bereichen für Knoten und PUPI-Bereichen für Pods. Weisen Sie beiden VPCs primäre IP-Adressbereiche aus dem privaten Adressraum von RFC 1918 zu (z. B. 10.x.x.x, 172.16.x.x oder 192.168.x.x). Diese Bereiche werden in der Regel für die Worker-Knoten in Ihren GKE-Clustern verwendet. Weisen Sie zusätzlich zu den internen IP-Adressbereichen separate Bereiche privat verwendeter öffentlicher IP-Adressen (Privately Used Public IP, PUPI) für jedes VPC zu. Diese PUPI-Bereiche werden ausschließlich für die Pod-IP-Adressen in den entsprechenden GKE-Clustern verwendet.
- Nutzer-VPC-Netzwerk: Diese VPC hostet den GKE-Cluster, in dem die Anwendungen oder Arbeitslasten des Nutzers ausgeführt werden. Sie können eine Konfiguration ähnlich der folgenden verwenden:
```
Network: consumer
Subnetwork: consumer-subnet
Primary range: 10.129.0.0/24
Service range name and cidr: consumer-services, 172.16.5.0/24
Pod range name and cidr: consumer-pods, 5.5.5.0/24
Cluster name: consumer-cluster
```
- VPC-Netzwerk des Producers: In diesem VPC wird der GKE-Cluster gehostet, der für die Bereitstellung des Dienstes verantwortlich ist, den der Nutzer nutzt. Sie können eine Konfiguration ähnlich der folgenden verwenden:
```
Network: producer
Subnetwork: producer-subnet
Primary range: 10.128.0.0/24
Service range name and cidr: producer-services, 172.16.45.0/24
Pod range name and cidr: producer-pods, 45.45.45.0/24
Cluster name: producer-cluster
```
Weitere Informationen zum Erstellen von VPC-Netzwerken finden Sie unter VPC-Netzwerke erstellen.
Mit den im vorherigen Schritt mit PUPI-Bereichen erstellten VPC-Netzwerken und Subnetzen können Sie zwei GKE-Cluster erstellen (producer und consumer).

Hinweis: PUPI-Bereiche werden nur als sekundäre IP-Adressbereiche für das Pod-Netzwerk in GKE unterstützt und können nicht für den primären IP-Adressbereich verwendet werden, der von Knoten und Diensten verwendet wird.
1. Erstelle producer Cluster mit dem Producer-Netzwerk und ‑Subnetz:
```
gcloud container clusters create PRODUCER_CLUSTER_NAME \
    --enable-ip-alias \
    --network=NETWORK_NAME \
    --subnetwork=SUBNETWORK_NAME \
    --cluster-secondary-range-name=PRODUCER_PODS \
    --services-secondary-range-name=PRODUCER_SERVICES \
    --num-nodes=1 \
    --zone=PRODUCER_ZONE_NAME \
    --project=PRODUCER_PROJECT_NAME
```
  Ersetzen Sie Folgendes:
  - PRODUCER_CLUSTER_NAME ist der Name des GKE-Producer-Clusters.
  - COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.
  - PRODUCER_SUBNET_NAME: Der Name eines vorhandenen Subnetzes. Der primäre IP-Adressbereich des Subnetzes wird für Knoten verwendet. Das Subnetz muss sich in derselben Region befinden wie der Cluster. Wenn keine Angabe gemacht wird, versucht GKE, ein Subnetz im VPC-Netzwerk default in der Region des Clusters zu verwenden.
  - Wenn die Zuweisungsmethode für sekundäre Bereiche von GKE verwaltet wird:
    - POD_IP_RANGE: Ein IP-Adressbereich in CIDR-Notation, z. B. 10.0.0.0/14, oder die Größe der Subnetzmaske eines CIDR-Blocks, z. B. /14. Damit wird der sekundäre IP-Adressbereich des Subnetzes für Pods erstellt. Wenn Sie die Option --cluster-ipv4-cidr weglassen, wählt GKE automatisch einen /14-Bereich (2¹⁸ Adressen) aus. Der automatisch ausgewählte Bereich wird nach dem Zufallsprinzip aus 10.0.0.0/8 (einem Bereich von 2²⁴ Adressen) ausgewählt.
    - SERVICES_IP_RANGE: ein IP-Adressbereich in CIDR-Notation (z. B. 10.4.0.0/19) oder die Größe der Subnetzmaske eines CIDR-Blocks (z. B. /19). Damit wird der sekundäre IP-Adressbereich des Subnetzes für Services erstellt.
  - Wenn die Zuweisungsmethode für sekundäre Bereiche Vom Nutzer verwaltet lautet:
    - SECONDARY_RANGE_PODS: der Name eines vorhandenen sekundären IP-Adressbereichs im angegebenen SUBNET_NAME. GKE verwendet den gesamten sekundären IP-Adressbereich des Subnetzes für die Pods des Clusters.
    - SECONDARY_RANGE_SERVICES: der Name eines vorhandenen sekundären IP-Adressbereichs im angegebenen.
2. Erstellen Sie consumer Cluster mit dem Nutzernetzwerk und ‑subnetz:
```
gcloud container clusters create CONSUMER_CLUSTER_NAME \
    --enable-ip-alias \
    --network=CONSUMER_NETWORK_NAME \
    --subnetwork=CONSUMER_SUBNETWORK_NAME \
    --cluster-secondary-range-name=CONSUMER_PODS \
    --services-secondary-range-name=CONSUMER_SERVICES \
    --num-nodes=1 \
    --zone=CONSUMER_ZONE \
    --project=CONSUMER_PROJECT
```
  Ersetzen Sie Folgendes:
  - CONSUMER_CLUSTER_NAME ist der Name des GKE-Nutzerclusters.
  - COMPUTE_LOCATION: der Compute Engine-Standort für den Cluster.
  - CONSUMER_SUBNET_NAME: Der Name eines vorhandenen Subnetzes. Der primäre IP-Adressbereich des Subnetzes wird für Knoten verwendet. Das Subnetz muss sich in derselben Region befinden wie der Cluster. Wenn keine Angabe gemacht wird, versucht GKE, ein Subnetz im VPC-Netzwerk default in der Region des Clusters zu verwenden.
  - Wenn die Zuweisungsmethode für sekundäre Bereiche von GKE verwaltet wird:
    - POD_IP_RANGE: Ein IP-Adressbereich in CIDR-Notation, z. B. 10.0.0.0/14, oder die Größe der Subnetzmaske eines CIDR-Blocks, z. B. /14. Damit wird der sekundäre IP-Adressbereich des Subnetzes für Pods erstellt. Wenn Sie die Option --cluster-ipv4-cidr weglassen, wählt GKE automatisch einen /14-Bereich (2¹⁸ Adressen) aus. Der automatisch ausgewählte Bereich wird nach dem Zufallsprinzip aus 10.0.0.0/8 (einem Bereich von 2²⁴ Adressen) ausgewählt und enthält keine IP-Adressbereiche, die VMs zugewiesen sind, keine vorhandenen Routen und keine Bereiche, die anderen Clustern zugewiesen sind. Der automatisch ausgewählte Bereich kann einen Konflikt mit reservierten IP-Adressen, dynamischen Routen oder Routen in VPCs auslösen, die eine Peering-Verbindung zu diesem Cluster haben. Wenn Sie einen dieser Fälle verwenden, sollten Sie --cluster-ipv4-cidr angeben, um Konflikte zu vermeiden.
    - SERVICES_IP_RANGE: ein IP-Adressbereich in CIDR-Notation (z. B. 10.4.0.0/19) oder die Größe der Subnetzmaske eines CIDR-Blocks (z. B. /19). Damit wird der sekundäre IP-Adressbereich des Subnetzes für Services erstellt.
  - Wenn die Zuweisungsmethode für sekundäre Bereiche Vom Nutzer verwaltet lautet:
    - SECONDARY_RANGE_PODS: der Name eines vorhandenen sekundären IP-Adressbereichs im angegebenen SUBNET_NAME. GKE verwendet den gesamten sekundären IP-Adressbereich des Subnetzes für die Pods des Clusters.
    - SECONDARY_RANGE_SERVICES: der Name eines vorhandenen sekundären IP-Adressbereichs im angegebenen.
Weitere Informationen zum Erstellen von Clustern finden Sie unter Cluster erstellen.
So richten Sie die VPC-Peering-Beziehung zwischen dem VPC-Netzwerk des Nutzers und dem VPC-Netzwerk des Producers ein:
- Führen Sie den folgenden Befehl aus, um das consumer-Netzwerk mit dem Producer zu verbinden:
```
gcloud compute networks peerings create PEERING_NAME \
    --project=consumer_project \
    --network=consumer \
    --peer-network=producer
```
- Führen Sie den folgenden Befehl aus, um das producer-Netzwerk mit dem Nutzer zu verbinden:
```
gcloud compute networks peerings create PEERING_NAME \
    --project=producer_project \
    --network=producer \
    --peer-network=consumer \
    --no-export-subnet-routes-with-public-ip \
    --import-subnet-routes-with-public-ip
```
Ersetzen Sie Folgendes:
- PEERING_NAME ist der Name des GKE-Nutzerclusters.
- CONSUMER_CLUSTER_NAME ist der Name des GKE-Nutzerclusters.
Standardmäßig exportiert die VPC des Nutzers die PUPI-Adressen. Beim Erstellen der Producer-VPC verwenden Sie die folgenden Argumente, um die VPC so zu konfigurieren, dass sie PUPI-Adressen importiert, aber nicht exportiert:
```
--no-export-subnet-routes-with-public-ip
--import-subnet-routes-with-public-ip
```

Netzwerke und Subnetzwerke prüfen

Prüfen Sie das Producer-Netzwerk:

gcloud compute networks describe producer \
    --project=producer_project

Die Ausgabe sieht in etwa so aus:

...
kind: compute#network
name: producer
peerings:
- autoCreateRoutes: true
  exchangeSubnetRoutes: true
  exportCustomRoutes: false
  exportSubnetRoutesWithPublicIp: false
  importCustomRoutes: false
  importSubnetRoutesWithPublicIp: true
  name: producer-peer-consumer
…

Prüfen Sie das Producer-Subnetzwerk:

gcloud compute networks subnets describe producer-subnet \
    --project=producer_project\
    --region=producer_region

Die Ausgabe sieht in etwa so aus:

...
ipCidrRange: 10.128.0.0/24
kind: compute#subnetwork
name: producer-subnet
…
secondaryIpRanges:
- ipCidrRange: 172.16.45.0/24
  rangeName: producer-services
- ipCidrRange: 45.45.45.0/24
  rangeName: producer-pods
…

Prüfen Sie das Nutzernetzwerk:

gcloud compute networks subnets describe consumer-subnet \
    --project=consumer_project \
    --region=consumer_region

Die Ausgabe sieht in etwa so aus:

...
kind: compute#network
name: consumer
peerings:
- autoCreateRoutes: true
  exchangeSubnetRoutes: true
  exportCustomRoutes: false
  exportSubnetRoutesWithPublicIp: true
  importCustomRoutes: false
  importSubnetRoutesWithPublicIp: false
  name: consumer-peer-producer
...

Prüfen Sie das Nutzer-Subnetzwerk:

gcloud compute networks describe consumer \
--project=consumer_project

Die Ausgabe sieht in etwa so aus:

...
ipCidrRange: 10.129.0.0/24
kind: compute#subnetwork
name: consumer-subnet
...
secondaryIpRanges:
- ipCidrRange: 172.16.5.0/24
  rangeName: consumer-services
- ipCidrRange: 5.5.5.0/24
  rangeName: consumer-pods
...

GKE-Cluster und seine Ressourcen prüfen

Rufen Sie die Anmeldedaten des Nutzerclusters ab:

gcloud container clusters get-credentials consumer-cluster \
    --project=consumer_project \
    --zone=consumer_zone

Die Ausgabe sieht in etwa so aus:

...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for consumer-cluster.
...

Installieren und prüfen Sie helloapp.

Alternativ können Sie das folgende Manifest als deployment.yaml speichern:

kubectl apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 200m
EOF

Wenden Sie die Datei "deployment.yaml" an:
```
kubectl apply -f
```

helloweb-Bereitstellung prüfen

kubectl get deployment helloweb

Die Ausgabe sieht in etwa so aus:

...
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
helloweb   1/1     1            1           10s
...

Lösung prüfen

Prüfen Sie, ob das VPC-Peering erfolgreich erstellt wurde:

gcloud compute networks peerings list

Die Ausgabe sieht in etwa so aus, mit Peerings namens "consumer" und "producer":

NAME                                     NETWORK    PEER_PROJECT                PEER_NETWORK                            STACK_TYPE  PEER_MTU  IMPORT_CUSTOM_ROUTES  EXPORT_CUSTOM_ROUTES  STATE   STATE_DETAILS
consumer-peer-producer                   consumer   <project_name>            producer                                IPV4_ONLY   1460      False                 False                 ACTIVE  [2023-08-07T13:14:57.178-07:00]: Connected.
producer-peer-consumer                   producer   <project_name>             consumer                                IPV4_ONLY   1460      False                 False                 ACTIVE  [2023-08-07T13:14:57.178-07:00]: Connected.

Prüfen Sie, ob die Nutzer-VPC PUPI-Routen exportiert:

gcloud compute networks peerings list-routes consumer-peer-producer \
    --direction=OUTGOING \
    --network=consumer \
    --region=<consumer_region>

Die Ausgabe sieht etwa so aus, wobei alle drei Nutzer-CIDR-Blöcke angezeigt werden:

DEST_RANGE     TYPE                  NEXT_HOP_REGION  PRIORITY  STATUS
10.129.0.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer
172.16.5.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer
5.5.5.0/24     SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer

Prüfen Sie die PUPI-Routen, die die Producer-VPC importiert hat:

gcloud compute networks peerings list-routes producer-peer-consumer \
    --direction=INCOMING \
    --network=producer \
    --region=<producer_region>

Die Ausgabe sieht etwa so aus, wobei alle drei Nutzer-CIDR-Blöcke angezeigt werden:

DEST_RANGE     TYPE                  NEXT_HOP_REGION  PRIORITY  STATUS
10.129.0.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted
172.16.5.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted
5.5.5.0/24     SUBNET_PEERING_ROUTE  us-central1      0         accepted

Prüfen Sie, ob die GKE-Pods eine PUPI-Adresse haben:

kubectl get pod -o wide

Die Ausgabe sieht ähnlich aus wie die folgende, die zeigt, dass die IP-Adressen der Pods innerhalb des Bereichs 5.5.5/24 liegen:

NAME                        READY   STATUS    RESTARTS   AGE   IP         NODE                                              NOMINATED NODE   READINESS GATES
helloweb-575d78464d-xfklj   1/1     Running   0          28m   5.5.5.16   gke-consumer-cluster-default-pool-e62b6542-dp5f   <none>           <none>

Nächste Schritte

Lesen Sie die Anleitung "Zugriff auf private Dienste konfigurieren"
Lesen Sie die Anleitung "Erste Schritte mit der Service Networking API"
Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Cloud Architecture Center ansehen