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

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Hinweis: Dieser Leitfaden unterstützt nur Cloud Service Mesh mit Istio APIs und nicht die APIs von Google Cloud . Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

Auf dieser Seite erfahren Sie, wie Sie Netzwerkverkehr von Cloud Service Mesh-Arbeitslasten in GKE sicher an Cloud Run-Dienste weiterleiten.

Beim Weiterleiten von Traffic von GKE zu Cloud Run muss der Cloud Run-Dienst nicht dem Cloud Service Mesh beitreten. Der Cloud Run-Dienst muss sich jedoch im selben Projekt wie der Cloud Service Mesh-GKE-Cluster befinden. Diese Einschränkung gilt, solange diese Funktion in der öffentlichen Vorschau verfügbar ist.

Hinweise

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

1. GKE-Cluster mit aktiviertem Cloud Service Mesh
2. Sie haben einen Cloud Run-Dienst bereitgestellt.

Alternativ können Sie die folgenden Befehle ausführen, um einen Beispiel-Cloud Run-Dienst 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 Ihres Clusters.
   • PROJECT_ID ist die Projekt-ID Ihres Projekts.
   • CLUSTER_LOCATION ist die Region oder Zone Ihres Clusters.

2. Beispiel-Cloud Run-Dienst bereitstellen:

   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

Damit Cloud Run-Dienste aufgerufen werden können, müssen die Cloud Run Identity and Access Management (IAM)-Prüfungen bestanden werden. Sie müssen dem Google-Dienstkonto die Rolle Cloud Run-Aufrufer zuweisen. Außerdem müssen Sie das GKE-Kubernetes-Dienstkonto (Kubernetes service account, KSA) so konfigurieren, dass es die Identität des Google-Dienstkontos annimmt.

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 Name des Namespace. Für die Zwecke dieses Leitfadens können Sie den Namespace default verwenden.
   • KSA ist der Name des Kubernetes-Dienstkontos. Für diesen Leitfaden können Sie die 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 GCP-Backend konfigurieren

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

1. Informationen zum Frontend, insbesondere zum Hostnamen und Port, die GKE-Arbeitslasten zum Aufrufen dieses GCP-Backends verwenden würden.
2. Back-End-Informationen: Details zum Cloud Run-Dienst, z. B. Dienstname, Standort und Projektnummer.

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

Damit der Hostname im Cluster aufgelöst werden kann (standardmäßig ist das nicht möglich), 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. Solange Sie diesen DNS-Eintrag nicht konfiguriert haben, schlägt die Anfrage fehl. Die Google Cloud -DNS-Konfiguration muss nur einmal pro benutzerdefinierter Domain eingerichtet werden.

1. So 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 so ein, dass 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 GCP-Backend 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 zwischen GKE und 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 über HTTP-Anfragen an hello-world.gcpbackend/hello auf den Cloud Run-Dienst zugreifen.

Sie sollten eindeutige Namen für GCPBackend verwenden, um Konflikte mit vorhandenen Kubernetes-Diensten oder Istio-Diensteinträgen zu vermeiden. Bei Konflikten hat der Kubernetes-Dienst Vorrang vor dem Istio ServiceEntry und dem GCPBackend.

Der virtuelle Dienst und das GCP-Backend müssen sich im selben Namensbereich befinden und der Cloud Run-Dienst muss sich im selben Projekt wie der Cloud Service Mesh-GKE-Cluster befinden.

Optional: Hostname 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 kann global über DNS aufgelöst werden. Sie können diesen Hostnamen direkt im Hostnamen „GCPBackend“ 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 über HTTP-Anfragen an hello-world.us-central1.run.app auf den Cloud Run-Dienst zugreifen.

(Optional) Istio-virtuellen Dienst und/oder Zielregel konfigurieren

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

Im folgenden Beispiel wird bei 50% der Anfragen eine Verzögerung von 5 Sekunden und bei 10% der Anfragen, die an das GCP-Backend gesendet werden, ein Abbruch (HTTP-Status 503) ausgelöst.

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 erfahren Sie, 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 im Mesh-Projekt nicht die Rolle „TrafficDirector-Client“ zugewiesen ist, wird beispielsweise 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 GKE weiterleiten