Pub/Sub-Ereignisse an einem privaten HTTP-Endpunkt in einem privaten GKE-Cluster empfangen

Nur-Proxy-Subnetz erstellen

Sofern Sie keine Organisationsrichtlinie erstellen, die dies verbietet, beginnen neue Projekte mit einem Standardnetzwerk (einem VPC-Netzwerk im automatischen Modus), das in jeder Region ein Subnetzwerk (Subnetz) hat. Jedes VPC-Netzwerk besteht aus einem oder mehreren IP-Adressbereichen, die als Subnetze bezeichnet werden. Subnetze sind regionale Ressourcen, denen IP-Adressbereiche zugeordnet sind.

1. Verwenden Sie den Befehl gcloud compute networks subnets create, um ein Nur-Proxy-Subnetz im Standardnetzwerk zu erstellen.

   gcloud compute networks subnets create proxy-only-subnet \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=us-central1 \
       --network=default \
       --range=10.10.10.0/24
   

   Beachten Sie, dass ein Subnetz mit purpose=REGIONAL_MANAGED_PROXY für Envoy-basierte Load-Balancer reserviert ist und die range mindestens 64 IP-Adressen bereitstellen muss.

2. Erstellen Sie eine Firewallregel, die dem Bereich des Nur-Proxy-Subnetzes entspricht und Traffic über TCP-Port 8080 zulässt.

   gcloud compute firewall-rules create allow-proxy-connection \
       --allow tcp:8080 \
       --source-ranges 10.10.10.0/24 \
       --network=default
   

Privaten GKE-Cluster erstellen

Verwenden Sie den Befehl gcloud container clusters create-auto, um einen privaten GKE-Cluster im Autopilot-Modus zu erstellen, der private Knoten und keinen Clientzugriff auf den öffentlichen Endpunkt hat.

Im folgenden Beispiel werden ein privater GKE-Cluster mit dem Namen private-cluster sowie ein Subnetz mit dem Namen my-subnet erstellt:

gcloud container clusters create-auto private-cluster \
    --create-subnetwork name=my-subnet \
    --enable-master-authorized-networks \
    --enable-private-nodes \
    --enable-private-endpoint \
    --region=us-central1

Wichtige Hinweise:

• --enable-master-authorized-networks gibt an, dass der Zugriff auf den öffentlichen Endpunkt auf von Ihnen autorisierte IP-Adressbereiche beschränkt ist.
• --enable-private-nodes gibt an, dass die Knoten des Clusters keine externen IP-Adressen haben.
• --enable-private-endpoint gibt an, dass der Cluster mithilfe der internen IP-Adresse für den API-Endpunkt der Steuerungsebene verwaltet wird.

Es kann einige Minuten dauern, bis der Cluster erstellt ist. Nachdem der Cluster erstellt wurde, sollte in der Ausgabe angezeigt werden, dass der Status des Clusters ist RUNNING.

VM-Instanz in einem bestimmten Subnetz erstellen

Eine Compute Engine-VM-Instanz ist eine virtuelle Maschine, die in der Infrastruktur von Google gehostet wird. Die Begriffe Compute Engine-Instanz, VM-Instanz und VM werden synonym verwendet. VM-Instanzen umfassen GKE-Cluster, Instanzen der flexiblen App Engine-Umgebung und andere Google Cloud-Produkte, die auf Compute Engine-VMs basieren.

Verwenden Sie den Befehl gcloud compute instances create, um eine Compute Engine-VM-Instanz in dem Subnetz zu erstellen, das Sie zuvor erstellt haben. Hängen Sie ein Dienstkonto an und legen Sie den Zugriffsbereich der VM auf cloud-platform fest.

gcloud compute instances create my-vm \
    --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --zone=us-central1-a \
    --subnet=my-subnet

Weitere Informationen finden Sie unter VM-Instanz erstellen und starten.

Ereignisempfänger auf der VM bereitstellen

Stellen Sie mit dem vordefinierten Image us-docker.pkg.dev/cloudrun/container/hello einen Dienst auf Ihrer VM bereit, der Port 80 überwacht und Ereignisse empfängt und protokolliert.

1. Stellen Sie mit dem folgenden Befehl eine SSH-Verbindung zu Ihrer VM-Instanz her:

   gcloud compute ssh my-vm --project=PROJECT_ID --zone=us-central1-a
   

   Nachdem eine Verbindung zum SSH-Server hergestellt wurde, führen Sie die verbleibenden Befehle auf Ihrer VM-Instanz aus.

2. Installieren Sie bei Bedarf kubectl und alle erforderlichen Plug-ins.

3. Verwenden Sie in Ihrer VM-Instanz den Befehl get-credentials, um kubectl für die Arbeit mit dem von Ihnen erstellten Cluster zu aktivieren.

   gcloud container clusters get-credentials private-cluster \
       --region=us-central1 \
       --internal-ip
   

4. Verwenden Sie einen Kubernetes-Befehl kubectl create deployment, um eine Anwendung im Cluster bereitzustellen.

   kubectl create deployment hello-app \
       --image=us-docker.pkg.dev/cloudrun/container/hello
   

   Damit wird ein Deployment mit dem Namen hello-app erstellt. Der Pod des Deployments führt das Container-Image hello aus.

5. Nach der Bereitstellung der Anwendung können Sie sie für Traffic freigeben, indem Sie einen Kubernetes-Dienst erstellen. Führen Sie den kubectl expose-Befehl aus:

   kubectl expose deployment hello-app \
       --type ClusterIP \
       --port 80 \
       --target-port 8080
   

   In der Ausgabe sollte service/hello-app exposed angezeigt werden.

   Nachrichten wie diese können Sie ignorieren:

   E0418 14:15:33.970933    1129 memcache.go:287] couldn't get resource list for metrics.k8s.io/v1beta1: the server is currently unable to handle the request
   

Traffic-Routing von Kubernetes konfigurieren

Eine Gateway-Ressource stellt eine Datenebene dar, die Traffic in Kubernetes weiterleitet. Ein Gateway kann je nach der abgeleiteten GatewayClass viele verschiedene Arten von Load-Balancing und Routing darstellen. Weitere Informationen finden Sie unter Gateways bereitstellen. Ein HTTPRoute-Manifest wird bereitgestellt, um Routen zu erstellen und Traffic an Anwendungs-Back-Ends zu senden.

1. Stellen Sie ein Gateway in Ihrem Cluster bereit.

   kubectl apply -f - <<EOF
   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: internal-http
   spec:
     gatewayClassName: gke-l7-rilb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
   EOF
   

   Wichtige Hinweise:

   • gatewayClassName: gke-l7-rilb gibt die GatewayClass an, von der dieses Gateway abgeleitet wurde. gke-l7-rilb entspricht dem internen Anwendungs-Load-Balancer.
   • port: 80 gibt an, dass das Gateway nur Port 80 für das Monitoring von HTTP-Traffic freigibt.

2. Prüfen Sie, ob das Gateway ordnungsgemäß bereitgestellt wurde. Es kann einige Minuten dauern, bis alle Ressourcen bereitgestellt wurden.

   kubectl describe gateways.gateway.networking.k8s.io internal-http
   

   Die Ausgabe sieht in etwa so aus:

   Name:         internal-http
   Namespace:    default
   ...
   API Version:  gateway.networking.k8s.io/v1beta1
   Kind:         Gateway
   ...
   Spec:
     Gateway Class Name:  gke-l7-rilb
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      http
       Port:      80
       Protocol:  HTTP
   Status:
     Addresses:
       Type:   IPAddress
       Value:  10.36.172.5
   ...
   Events:
     Type    Reason  Age                From                   Message
     ----    ------  ----               ----                   -------
     Normal  ADD     80s                sc-gateway-controller  default/internal-http
     Normal  UPDATE  20s (x3 over 80s)  sc-gateway-controller  default/internal-http
     Normal  SYNC    20s                sc-gateway-controller  SYNC on default/internal-http was a success
   

3. Stellen Sie ein HTTPRoute-Manifest bereit, um HTTP-Traffic an den Dienst hello-app über Port 80 weiterzuleiten.

   kubectl apply -f - <<EOF
   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: hello-app-route
   spec:
     parentRefs:
     - kind: Gateway
       name: internal-http
     rules:
     - backendRefs:
       - name: hello-app
         port: 80
   EOF
   

Netzwerkanhang erstellen

Ein Netzwerkanhang ist eine Ressource, mit der ein Produzenten-VPC-Netzwerk über eine Private Service Connect-Schnittstelle Verbindungen zu einem Nutzer-VPC-Netzwerk initiieren kann.

Eventarc verwendet zum Veröffentlichen von Ereignissen den Netzwerkanhang, um eine Verbindung zum internen HTTP-Endpunkt herzustellen, der in einem VPC-Netzwerk gehostet wird.

Sie können einen Netzwerkanhang erstellen, der automatisch Verbindungen von jeder Private Service Connect-Schnittstelle akzeptiert, die auf den Netzwerkanhang verweist. Erstellen Sie den Netzwerkanhang im selben Netzwerk und in derselben Region wie der HTTP-Zieldienst.

gcloud compute network-attachments create my-network-attachment \
    --region=us-central1 \
    --subnets=my-subnet\
    --connection-preference=ACCEPT_AUTOMATIC

Weitere Informationen finden Sie unter Netzwerkanhänge.

Eventarc-Trigger erstellen

Sie erstellen einen Eventarc-Trigger, der ein neues Pub/Sub-Thema erstellt und Ereignisse an den auf der VM bereitgestellten Ereignisempfänger weiterleitet, wenn eine Nachricht im Pub/Sub-Thema veröffentlicht wird.

1. Rufen Sie die Gateway-Adresse ab.

   GATEWAY_ADDRESS=$(kubectl get gateways.gateway.networking.k8s.io internal-http -o=jsonpath="{.status.addresses[0].value}")
   

2. Erstellen Sie einen Trigger.

   gcloud eventarc triggers create my-trigger \
       --location=us-central1 \
       --destination-http-endpoint-uri="http://$GATEWAY_ADDRESS:80/" \
       --network-attachment="projects/PROJECT_ID/regions/us-central1/networkAttachments/my-network-attachment" \
       --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" \
       --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com
   

   Ersetzen Sie PROJECT_NUMBER durch Ihre Google Cloud-Projektnummer. Sie finden Ihre Projektnummer auf der Willkommensseite der Google Cloud Console oder durch Ausführen des folgenden Befehls:

   gcloud projects describe PROJECT_ID --format='value(projectNumber)'
   

Weitere Informationen zum Konfigurieren des Triggers finden Sie unter Ereignisse an einen internen HTTP-Endpunkt in einem VPC-Netzwerk weiterleiten.

Generieren Sie ein Pub/Sub-Thema und rufen Sie es auf.

Sie können ein Ereignis generieren, indem Sie eine Nachricht in einem Pub/Sub-Thema veröffentlichen.

1. Suchen Sie das Pub/Sub-Thema und legen Sie es als Umgebungsvariable fest.

   export MY_TOPIC=$(gcloud eventarc triggers describe my-trigger \
       --location=us-central1 \
       --format='value(transport.pubsub.topic)')
   

2. Senden Sie eine Nachricht an das Pub/Sub-Thema, um ein Ereignis zu generieren:

   gcloud pubsub topics publish $MY_TOPIC --message "Hello World"
   

   Der Eventarc-Trigger leitet das Ereignis an den internen HTTP-Endpunkt im privaten GKE-Cluster weiter.

3. Prüfen Sie die Anwendungs-Pod-Logs und die Ereignisübermittlung.

   POD_NAME=$(kubectl get pod --selector app=hello-app --output=name)
   kubectl logs $POD_NAME
   

   Der Ereignistext sollte in etwa so aussehen:

   2024/04/18 20:31:43 Hello from Cloud Run! The container started successfully and is listening for HTTP requests on $PORT
   {"severity":"INFO","eventType":"google.cloud.pubsub.topic.v1.messagePublished","message":"Received event of type google.cloud.pubsub.topic.v1.messagePublished.
   Event data: Hello World","event":{"specversion":"1.0","id":"10935738681111260","source":"//pubsub.googleapis.com/projects/my-project/topics/eventarc-us-central1-my-trigger-224","type":"google.cloud.pubsub.topic.v1.messagePublished","datacontenttype":"application/json","time":"2024-04-18T20:40:03Z","data":
   {"message":{"data":"SGVsbG8gV29ybGQ=","messageId":"10935738681111260","publishTime":"2024-04-18T20:40:03Z"}}}}
   

Sie haben einen Ereignisempfängerdienst an einem internen HTTP-Endpunkt in einem privaten GKE-Cluster bereitgestellt, einen Eventarc-Trigger erstellt sowie ein Ereignis über Pub/Sub generiert und bestätigt, dass das Ereignis wie erwartet vom Trigger zum Zielendpunkt weitergeleitet wurde.