Traffic von Cloud Service Mesh-Arbeitslasten an Cloud Run-Dienste weiterleiten

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Pre-GA-Angebotsbedingungen“ im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Features sind "im Ist-Zustand" verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie unter den Beschreibungen der Startphase.

Hinweis: Diese Anleitung gilt nur für Cloud Service Mesh mit Istio APIs und nicht für Google Cloud -APIs. Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

Durch die Einbindung von Cloud Run in Cloud Service Mesh können Sie Traffic von GKE-Arbeitslasten sicher an serverlose Back-Ends weiterleiten. Ihre Cloud Run-Dienste müssen nicht dem Service Mesh beitreten, um Traffic zu empfangen.

Diese Integration unterstützt Cloud Service Mesh mit Istio APIs und keineGoogle Cloud -APIs. Während sich dieses Feature in der öffentlichen Vorschau befindet, muss sich der Cloud Run-Dienst im selben Google Cloud -Projekt wie Ihr GKE-Cluster befinden.

Hinweis

In den folgenden Abschnitten wird davon ausgegangen, dass Sie Folgendes haben:

1. Einen GKE-Cluster mit aktiviertem Cloud Service Mesh.
2. Cloud Run-Dienst bereitgestellt

Alternativ können Sie die folgenden Befehle ausführen, um einen Cloud Run-Beispieldienst bereitzustellen.

1. Generieren Sie einen kubeconfig-Kontext für Ihren Cluster:

   gcloud container clusters get-credentials CLUSTER_NAME --project=PROJECT_ID  --location=CLUSTER_LOCATION
   

   Wobei:

   • CLUSTER_NAME ist der Name des Clusters.
   • PROJECT_ID ist die Projekt-ID Ihres Projekts.
   • CLUSTER_LOCATION ist die Region oder Zone Ihres Clusters.

2. Stellen Sie einen Cloud Run-Beispieldienst bereit:

   gcloud run deploy hello-world \
     --image=us-docker.pkg.dev/cloudrun/container/hello \
     --no-allow-unauthenticated \
     --port=8080 \
     --service-account=[e-mail] \
     --region=us-central1 \
     --project=PROJECT_ID
   

   Wobei:

   • PROJECT_NUMBER ist die Projektnummer Ihres Projekts.
   • PROJECT_ID ist die Projekt-ID Ihres Projekts.

IAM konfigurieren

Zum Aufrufen von Cloud Run-Diensten müssen die IAM-Prüfungen (Identity and Access Management) von Cloud Run bestanden werden. Sie müssen dem Google-Dienstkonto die Rolle „Cloud Run-Aufrufer“ zuweisen. Außerdem müssen Sie das GKE-Kubernetes-Dienstkonto (KSA) so konfigurieren, dass es die Identität des Google-Dienstkontos übernimmt.

Führen Sie die folgenden Schritte aus, um einem Kubernetes-Dienstkonto zu erlauben, die Identität eines Google-Dienstkontos zu übernehmen.

1. Fügen Sie einem IAM-Dienstkonto eine IAM-Richtlinienbindung hinzu:

   gcloud iam service-accounts add-iam-policy-binding [e-mail] \
     --role roles/iam.workloadIdentityUser \
     --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]"
   

   Wobei:

   • NAMESPACE ist der Namespace-Name. Für die Zwecke dieses Leitfadens können Sie den Namespace default verwenden.
   • KSA ist der Name des Kubernetes-Dienstkontos. Für diese Anleitung können Sie das KSA default verwenden.

2. Annotieren Sie das Dienstkonto:

   kubectl annotate serviceaccount KSA \
     --namespace NAMESPACE \
     iam.gke.io/gcp-service-account=[e-mail]
   

3. Weisen Sie dem Google-Dienstkonto die Rolle „Cloud Run-Aufrufer“ zu:

   gcloud run services add-iam-policy-binding hello-world \
     --region=us-central1 \
     --member="serviceAccount:[e-mail]" \
     --role="roles/run.invoker"
   

Cloud Run-Dienst als GCPBackend konfigurieren

In diesem Abschnitt machen Sie den Cloud Run-Dienst mithilfe von GCPBackend für die GKE-Arbeitslasten verfügbar. Das GCPBackend besteht aus:

1. Frontend-Informationen – insbesondere der Hostname und der Port, die von GKE-Arbeitslasten zum Aufrufen dieses GCPBackend verwendet werden.
2. Backend-Informationen: Details zum Cloud Run-Dienst, z. B. Dienstname, Standort und Projektnummer.

Das GCPBackend enthält die Hostnamen- und Portdetails sowie die Cloud-Dienstdetails (Dienstname, Standort und Projektnummer). Die GKE-Arbeitslasten sollten den GCPBackend-Hostnamen und -Port in ihren HTTP-Anfragen verwenden, um auf den Cloud Run-Dienst zuzugreifen.

Damit der Hostname im Cluster per DNS aufgelöst werden kann (standardmäßig ist er nicht auflösbar), müssen Sie das Google Cloud DNS so konfigurieren, dass alle Hosts unter einem ausgewählten Hostnamen in eine beliebige IP-Adresse aufgelöst werden. Bis Sie diesen DNS-Eintrag konfigurieren, schlägt die Anfrage fehl. Die Google Cloud DNS-Konfiguration ist eine einmalige Einrichtung pro benutzerdefinierter Domain.

1. Erstellen Sie eine verwaltete Zone:

   gcloud dns managed-zones create prod \
       --description="zone for gcpbackend" \
       --dns-name=gcpbackend \
       --visibility=private \
       --networks=default
   

   In diesem Beispiel lautet der DNS-Name gcpbackend und das VPC-Netzwerk default.

2. Richten Sie den Eintrag ein, damit die Domain aufgelöst werden kann:

   gcloud beta dns record-sets create *.gcpbackend \
     --ttl=3600 --type=A --zone=prod \
     --rrdatas=10.0.0.1
   

3. Erstellen Sie das GCPBackend mit einem Hostnamen unter der vorherigen Domain:

   cat <<EOF > gcp-backend.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPBackend
   metadata:
     name: cr-gcp-backend
     namespace: NAMESPACE
   spec:
     hostname: hello-world.gcpbackend
     type: CloudRun
     cloudrun:
       service: hello-world
       regions: [us-central1]
   EOF
   kubectl apply -f gcp-backend.yaml
   

   In diesem Beispiel ist GCP_BACKEND_NAME cr-gcp-backend.

4. Erstellen Sie einen Test-Pod, um die Verbindung von GKE zu Cloud Run zu prüfen:

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: testcurl
     namespace: default
   spec:
     containers:
     - name: curl
       image: curlimages/curl
       command: ["sleep", "3000"]
   EOF
   
   kubectl exec testcurl -c curl -- curl http://hello-world.gcpbackend/hello
   

   Ihre GKE-Arbeitslasten können jetzt auf den Cloud Run-Dienst zugreifen, indem sie HTTP-Anfragen an hello-world.gcpbackend/hello senden.

Sie sollten eindeutige Namen für GCPBackend verwenden, um Konflikte mit vorhandenen Kubernetes-Diensten oder Istio-Diensteinträgen zu vermeiden. Bei einem Konflikt gilt die folgende Rangfolge (von hoch nach niedrig): Kubernetes-Dienst, istio-ServiceEntry und GCPBackend.

Beachten Sie, dass sich der virtuelle Dienst und das GCPBackend im selben Namespace befinden müssen und der Cloud Run-Dienst im selben Projekt wie der Cloud Service Mesh-GKE-Cluster sein muss.

(Optional) Hostnamen von Cloud Run anstelle von Cloud DNS verwenden

Jedem Cloud Run-Dienst wird ein Hostname zugewiesen (z. B. hello-world.us-central1.run.app) und er ist global über DNS auflösbar. Sie können diesen Hostnamen direkt im GCPBackend-Hostnamen verwenden und die Cloud DNS-Konfiguration überspringen.

cat <<EOF | kubectl apply -f -
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: cr-gcp-backend
  namespace: NAMESPACE
spec:
  hostname: hello-world.us-central1.run.app
  type: CloudRun
  cloudrun:
    service: hello-world
    region: [us-central1]
EOF

Ihre GKE-Arbeitslasten können jetzt auf den Cloud Run-Dienst zugreifen, indem sie HTTP-Anfragen an hello-world.us-central1.run.app senden.

(Optional) Istio Virtual Service und/oder Destination Rule konfigurieren

Sie können den virtuellen Istio-Dienst oder die Istio-Zielregel für den GCPBackend-Hostnamen konfigurieren, um Nutzer- oder Clientrichtlinien für Anfragen an das GCPBackend festzulegen.

Im folgenden Beispiel wird eine Verzögerung von 5 Sekunden für 50% der Anfragen und ein Abbruch (HTTP-Status 503) für 10% der Anfragen an das GCPBackend eingefügt.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cr-virtual-service
  namespace: NAMESPACE
spec:
  hosts:
  - hello-world.us-central1.run.app
  gateways:
  - mesh
  http:
  - fault:
      delay:
        percentage:
          value: 50  # Delay 50% of requests
        fixedDelay: 5s
      abort:
        percentage:
          value: 10  # Abort 10% of requests
        httpStatus: 503
  - route:
    - destination:
        host: hello-world.us-central1.run.app
EOF

In diesem Beispiel ist VIRTUAL_SERVICE_NAME cr-virtual-service.

Fehlerbehebung

In diesem Abschnitt wird beschrieben, wie Sie häufige Fehler bei Cloud Service Mesh und Cloud Run beheben.

Cloud Run-Sidecar-Logs

Envoy-Fehler werden in Cloud Logging protokolliert.

Wenn dem Cloud Run-Dienstkonto beispielsweise nicht die Traffic Director-Clientrolle im Mesh-Netzwerkprojekt zugewiesen ist, wird ein Fehler wie der folgende protokolliert:

StreamAggregatedResources gRPC config stream to trafficdirector.googleapis.com:443 closed: 7, Permission 'trafficdirector.networks.getConfigs' denied on resource '//trafficdirector.googleapis.com/projects/525300120045/networks/mesh:test-mesh/nodes/003fb3e0c8927482de85f052444d5e1cd4b3956e82b00f255fbea1e114e1c0208dbd6a19cc41694d2a271d1ab04b63ce7439492672de4499a92bb979853935b03d0ad0' (or it may not exist).

CSDS

Der Traffic Director-Clientstatus kann mit CSDS abgerufen werden:

gcloud alpha container fleet mesh debug proxy-status --membership=<CLUSTER_MEMBERSHIP> --location=<CLUSTER_LOCATION>
External Clients:
....

Nächste Schritte

• Traffic von Cloud Run-Diensten an Cloud Service Mesh-Arbeitslasten in der GKE weiterleiten