Cloud Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

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

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

Hinweis: Wenn Sie Traffic von GKE an Cloud Run weiterleiten, 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 sich diese Funktion in der öffentlichen Vorschau befindet.

Hinweise

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

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

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.
- CLUSTER_LOCATION ist die Region oder Zone Ihres Clusters.

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=PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --region=us-central1 \
  --project=PROJECT_ID

Wobei:

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

IAM konfigurieren

Damit Cloud Run-Dienste aufgerufen werden können, müssen die Cloud Run-IAM-Prüfungen (Identity and Access Management) bestanden werden. Sie müssen dem Google-Dienstkonto die Rolle „Cloud Run Invoker“ 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.

Fügen Sie einem IAM-Dienstkonto eine IAM-Richtlinienbindung hinzu:
```
gcloud iam service-accounts add-iam-policy-binding PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --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 die KSA default verwenden.

Annotieren Sie das Dienstkonto:

kubectl annotate serviceaccount KSA \
  --namespace NAMESPACE \
  iam.gke.io/gcp-service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

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:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
  --role="roles/run.invoker"

Cloud Run-Dienst als GCPBackend konfigurieren

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

Frontend-Informationen, insbesondere der Hostname und Port, die von GKE-Arbeitslasten verwendet werden, um diesen GCPBackend aufzurufen.
Back-End-Informationen: Die Details des Cloud Run-Dienstes, z. B. Dienstname, Standort und Projektnummer.

Das GCPBackend enthält den Hostnamen und die 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 innerhalb des Clusters DNS-auflösbar ist (standardmäßig ist er nicht auflösbar), müssen Sie 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.

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 ist der DNS-Name gcpbackend und das VPC-Netzwerk default.

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

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.

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 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-Service-Einträgen zu vermeiden. Wenn es zu einem Konflikt kommt, gilt die folgende Prioritätsreihenfolge (hoch bis niedrig): Kubernetes-Dienst, Istio-ServiceEntry und GCPBackend.

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

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

Jedem Cloud Run-Dienst wird ein Hostname zugewiesen (z. B. hello-world.us-central1.run.app), der global per DNS aufgelöst werden kann. 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 -Zielregel konfigurieren

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

Im folgenden Beispiel wird eine Verzögerung von 5 Sekunden bei 50% der Anfragen eingefügt und 10% der Anfragen, die an das GCPBackend gesendet werden, werden abgebrochen (HTTP-Status 503).

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 mit 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-Projekt zugewiesen wird, 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 GKE weiterleiten