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

Auf dieser Seite wird beschrieben, wie Sie privat genutzte öffentliche IP-Adressen (Privately Used Public IPs; PUPIs) für Pod-Adressblöcke von Google Kubernetes Engine (GKE) verwenden.

Privat genutzte ö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. Mit zunehmender Größe Ihrer Infrastruktur kann es zu einer Ausschöpfung des standardmäßigen internen IP-Adressbereichs (RFC 1918) kommen. 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 bieten 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 genutzte 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), ist eine komplexere Konfiguration erforderlich. Das folgende Diagramm zeigt ein Beispiel dafür, wie ein Unternehmen (Producer) einem Kunden (Nutzer) einen verwalteten Dienst mit PUPI und VPC-Peering anbietet.

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

Das vorherige Diagramm berücksichtigt die folgenden Aspekte:

  • 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 auf 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) und verwendet einen 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 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 die IP-Adressmaskierung aktivieren, bei der 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): Importiert keine Subnetzrouten mit öffentlichen IP-Adressen
Aktivieren: --import-subnet-routes-with-public-ip (über Peering)

Standardverhalten (aktiviert): Exportiert Subnetzrouten mit öffentlichen IP Adressen
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

Damit die Kommunikation zwischen VPC-Pods und einer anderen VPC funktioniert, 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 routingfähig ist oder Google gehört.
  • Achten Sie darauf, dass sich die Knoten-IP-Adressen und der primäre IP-Adressbereich beider VPCs nicht überschneiden.
  • Wenn Sie eine direkte Pod-zu-Pod-Kommunikation zwischen der VPC des Kunden und dem verwalteten Dienst benötigen, führen Sie die folgenden Schritte aus:
    • Autopilot-Cluster: Konfigurieren Sie SNAT für PUPI, um die Pod-zu-Pod-Kommunikation zu ermöglichen. Es ist keine zusätzliche Konfiguration erforderlich.
    • Standard-Cluster: Übersetzen Sie Pod-IP-Adressen mit SNAT in die entsprechenden Knoten-IP-Adressen. Aktivieren Sie SNAT für PUPI-Traffic. Weitere Informationen finden Sie unter Externe IP-Adressbereiche für die private Nutzung aktivieren.

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

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

  1. Konfigurieren Sie zwei Virtual Private Cloud-Netzwerke.
  2. Konfigurieren Sie ein Subnetz in jedem Virtual Private Cloud-Netzwerk.
  3. In jedem Subnetz einen PUPI-Adressbereich in einem sekundären Adressbereich konfigurieren
  4. Stellen Sie eine Virtual Private Cloud-Peering-Beziehung zwischen den beiden Virtual Private Cloud-Netzwerken mit entsprechenden Import- und Exporteinstellungen her.
  5. 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.

Hinweis

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, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

  • Verwenden Sie nur VPC-native Cluster.

  • Richten Sie die erforderlichen IPAM-Spezifikationen für das VPC Peering ein.

Netzwerke und Cluster einrichten

  1. 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 Adressbereich 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. Zusätzlich zu den internen IP-Adressbereichen legen Sie für jede VPC separate Bereiche mit privat genutzten öffentlichen IP-Adressen (PUPIs) fest. Diese PUPI-Bereiche werden ausschließlich für die Pod-IP-Adressen in den entsprechenden GKE-Clustern verwendet.

    • VPC-Netzwerk des Nutzers: In dieser VPC wird der GKE-Cluster gehostet, 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.

  2. Mit den VPC-Netzwerken und Subnetzen mit PUPI-Bereichen, die im vorherigen Schritt erstellt wurden, können Sie zwei GKE-Cluster (producer und consumer) erstellen.

    1. Erstellen Sie producer-Cluster mit dem Producer-Netzwerk und -Subnetz wie folgt:

      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: 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 oder für zonale Cluster eine Zone an.
      • PRODUCER_NETWORK_NAME: der Name eines vorhandenen Producer-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 default-VPC-Netzwerk in der Region des Clusters zu verwenden.
      • PRODUCER_PODS: der Name eines vorhandenen sekundären IP-Adressbereichs in PRODUCER_SUBNETWORK_NAME, der von GKE für die Pods des Clusters verwendet wird.
      • PRODUCER_SERVICES: der Name eines vorhandenen sekundären IP-Adressbereichs in PRODUCER_SUBNETWORK_NAME, der von GKE für die Dienste des Clusters verwendet wird.
      • PRODUCER_PROJECT_ID: die ID des Producer-Projekts.

    2. Erstellen Sie consumer-Cluster mit dem Consumer-Netzwerk und -Subnetz wie folgt:

      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: der Name des GKE-Nutzerclusters.
      • CONSUMER_CONTROL_PLANE_LOCATION: der Compute Engine Standort der Steuerungsebene Ihres Nutzerclusters. Geben Sie für regionale Cluster eine Region oder für zonale Cluster eine Zone an.
      • CONSUMER_NETWORK_NAME: der Name eines vorhandenen Consumer-VPC-Netzwerk.
      • 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 default-VPC-Netzwerk in der Region des Clusters zu verwenden.
      • CONSUMER_PODS: der Name eines vorhandenen sekundären IP-Adressbereichs in CONSUMER_SUBNETWORK_NAME, der von GKE für die Pods des Clusters verwendet wird.
      • CONSUMER_SERVICES: der Name eines vorhandenen sekundären IP-Adressbereichs in CONSUMER_SUBNETWORK_NAME, der von GKE für die Dienste des Clusters verwendet wird.
      • CONSUMER_PROJECT_ID: die ID des Nutzerprojekts.

    Weitere Informationen zum Erstellen von Clustern finden Sie unter Cluster erstellen.

  3. 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 Consumer-Netzwerk 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

  1. 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
…

  2. 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
…

  3. 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
...

  4. Prüfen Sie das Nutzer-Subnetzwerk:

    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

  1. Rufen Sie die Anmeldedaten für den Nutzercluster 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.
...

  2. Installieren und prü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

  3. Wenden Sie das Manifest auf Ihren Cluster an:

    kubectl apply -f deployment.yaml

  4. Prüfen Sie die helloweb-Bereitstellung:

    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

  1. 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.

  2. 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

  3. 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

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

    kubectl get pod -o wide

    Die Ausgabe sieht in etwa so aus und 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