Diese Seite wurde von der Cloud Translation API übersetzt.

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

Autopilot Standard

Auf dieser Seite 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 (PUPIs) sind Adressen, die Sie privat in Ihrem Google Cloud VPC-Netzwerk (Virtual Private Cloud) 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 Dienste. Wenn Ihre Infrastruktur wächst, kann es sein, dass der standardmäßige interne IP-Adressbereich (RFC 1918) erschöpft ist. Eine Möglichkeit, die Ausschöpfung privater 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 sind eine Alternative für Ihr GKE-Pod-Netzwerk, da 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 häufiges 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 über PUPI mit VPC-Peering anbietet.

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

Das obige Diagramm beinhaltet die folgenden Ü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), der einen anderen PUPI-Bereich (5.0.0.0/8) für seine Pod-IP-Adressen verwendet.

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 sicherstellen

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 Konflikt steht, die in der VPC des Producers verwendet werden.
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-Adressen-Masquerading aktivieren, bei dem die Pod-IP-Adressen hinter den Knoten-IP-Adressen des Producers verborgen 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): Subnetzrouten mit öffentlichen IP-Adressen werden exportiert. 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, 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

Damit die Kommunikation zwischen VPC-Pods und einer anderen VPC erfolgreich ist, müssen die folgenden Voraussetzungen und Konfigurationen erfüllt sein:

Ihr GKE-Cluster muss die folgenden Mindestversionsanforderungen 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 geroutet werden kann oder Google gehört.
Achten Sie darauf, dass sich die Knoten-IP-Adressen und der primäre IP-Adressbereich der beiden VPCs nicht überschneiden.
Wenn eine direkte Pod-zu-Pod-Kommunikation zwischen der VPC des Kunden und dem verwalteten Dienst erforderlich ist, gehen Sie so vor:
- Autopilot-Cluster: Konfigurieren Sie SNAT für PUPI, um die Pod-zu-Pod-Kommunikation zu ermöglichen. Es ist keine zusätzliche Konfiguration erforderlich.
- Standardcluster: Pod-IP-Adressen werden mithilfe von SNAT in die entsprechenden Knoten-IP-Adressen übersetzt. SNAT für PUPI-Traffic aktivieren. 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 VPC-Netzwerk konfigurieren
In jedem Subnetz einen PUPI-Adressbereich in einem sekundären Adressbereich konfigurieren
Eine geeignete VPC-Peering-Beziehung zwischen den beiden VPC-Netzwerken mit entsprechenden Import- und Exporteinstellungen herstellen
Die Routen in jeder Virtual Private Cloud prüfen

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 diesen Task 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

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 zwei 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 für jede VPC separate Bereiche mit privat verwendeten öffentlichen IP-Adressen (Privately Used Public IPs, PUPIs) zu. Diese PUPI-Bereiche werden ausschließlich für die Pod-IP-Adressen in den entsprechenden GKE-Clustern verwendet.
- VPC-Netzwerk des Nutzers: In diesem VPC wird der GKE-Cluster gehostet, in dem die Anwendungen oder Arbeitslasten des Nutzers ausgeführt werden. Sie können eine Konfiguration verwenden, die der folgenden ähnelt:
```
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 verwenden, die der folgenden ähnelt:
```
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 VPC-Netzwerken und Subnetzen, die im vorherigen Schritt mit PUPI-Bereichen erstellt wurden, können Sie zwei GKE-Cluster (producer und consumer) erstellen.

Hinweis :PUPI-Bereiche werden in GKE nur als sekundäre IP-Adressbereiche für das Pod-Netzwerk unterstützt und können nicht für den primären IP-Adressbereich (der von Knoten und Diensten verwendet wird) verwendet werden.
1. Erstellen Sie producer-Cluster mit dem Produzentennetzwerk und ‑subnetz:
```
gcloud container clusters create PRODUCER_CLUSTER_NAME \
    --location=PRODUCER_CONTROL_PLANE_LOCATION \
    --enable-ip-alias \
    --network=PRODUCER_NETWORK_NAME \
    --subnetwork=PRODUCER_SUBNETWORK_NAME \
    --cluster-secondary-range-name=PRODUCER_PODS \
    --services-secondary-range-name=PRODUCER_SERVICES \
    --num-nodes=1 \
    --project=PRODUCER_PROJECT_ID
```
  Ersetzen Sie Folgendes:
  - PRODUCER_CLUSTER_NAME ist der Name des GKE-Producer-Clusters.
  - PRODUCER_CONTROL_PLANE_LOCATION: der Compute Engine-Standort der Steuerungsebene Ihres Producer-Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.
  - PRODUCER_NETWORK_NAME: der Name eines vorhandenen Ersteller-VPC-Netzwerk.
  - PRODUCER_SUBNETWORK_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.
  - PRODUCER_PROJECT_ID ist die ID des Erstellerprojekts.
2. Erstellen Sie consumer-Cluster mit dem Nutzer-Netzwerk und ‑Subnetz:
```
gcloud container clusters create CONSUMER_CLUSTER_NAME \
    --location=CONSUMER_CONTROL_PLANE_LOCATION \
    --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 \
    --project=CONSUMER_PROJECT_ID
```
  Ersetzen Sie Folgendes:
  - CONSUMER_CLUSTER_NAME ist der Name des GKE-Nutzerclusters.
  - CONSUMER_CONTROL_PLANE_LOCATION: der Compute Engine-Standort der Steuerungsebene Ihres Consumer-Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.
  - PRODUCER_NETWORK_NAME: der Name eines vorhandenen VPC-Netzwerk des Consumers.
  - CONSUMER_SUBNETWORK_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.
  - CONSUMER_PROJECT_ID: die ID des Nutzerprojekts.
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 CONSUMER_PEERING_NAME \
    --project=CONSUMER_PROJECT_ID \
    --network=CONSUMER_NETWORK_NAME \
    --peer-network=PRODUCER_NETWORK_NAME
```
  Ersetzen Sie CONSUMER_PEERING_NAME durch den Namen des Peerings, das dem Consumernetzwerk hinzugefügt werden soll.
- Führen Sie den folgenden Befehl aus, um das producer-Netzwerk mit dem Nutzer zu verbinden:
```
gcloud compute networks peerings create PRODUCER_PEERING_NAME \
    --project=PRODUCER_PROJECT_ID \
    --network=PRODUCER_NETWORK_NAME \
    --peer-network=CONSUMER_NETWORK_NAME \
    --no-export-subnet-routes-with-public-ip \
    --import-subnet-routes-with-public-ip
```
  Ersetzen Sie PRODUCER_PEERING_NAME durch den Namen des Peerings, das dem Producer-Netzwerk hinzugefügt werden soll.
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_NETWORK_NAME \
    --project=PRODUCER_PROJECT_ID

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_SUBNETWORK_NAME \
    --project=PRODUCER_PROJECT_ID\
    --region=PRODUCER_CONTROL_PLANE_LOCATION

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 describe CONSUMER_NETWORK_NAME \
    --project=CONSUMER_PROJECT_ID

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 Subnetzwerk des Nutzers:

gcloud compute networks subnets describe CONSUMER_SUBNETWORK_NAME \
    --project=CONSUMER_PROJECT_ID\
    --region=CONSUMER_CONTROL_PLANE_LOCATION

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 für den Consumer-Cluster ab:

gcloud container clusters get-credentials CONSUMER_CLUSTER_NAME \
    --project=CONSUMER_PROJECT_ID \
    --location=CONSUMER_CONTROL_PLANE_LOCATION

Die Ausgabe sieht in etwa so aus:

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

Installieren und überprüfen Sie die Hello-App.

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_PEERING_NAME \
    --direction=OUTGOING \
    --network=CONSUMER_NETWORK_NAME \
    --region=CONSUMER_CONTROL_PLANE_LOCATION

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_PEERING_NAME \
    --direction=INCOMING \
    --network=PRODUCER_NETWORK_NAME \
    --region=PRODUCER_CONTROL_PLANE_LOCATION

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 etwa so aus. Sie zeigt, dass die IP-Adressen der Pods im Bereich 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 zuGoogle Cloudkennenlernen. Cloud Architecture Center ansehen

Privat genutzte öffentliche IP-Adressen für GKE konfigurieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Übersicht

Vorbereitung

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

Kosten

Hinweise

Netzwerke und Cluster einrichten

Netzwerke und Subnetzwerke prüfen

GKE-Cluster und seine Ressourcen prüfen

Lösung prüfen

Nächste Schritte

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