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

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.

Hinweis

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 Ihres Clusters.
- PROJECT_ID ist die Projekt-ID Ihres Projekts.
- 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 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.

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

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 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:

Informationen zum Frontend, insbesondere zum Hostnamen und Port, die GKE-Arbeitslasten zum Aufrufen dieses GCP-Backends verwenden würden.
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 per DNS aufgelöst werden kann (standardmäßig ist dies nicht möglich), müssen Sie 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 DNS-Konfiguration Google Cloud 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 lautet der DNS-Name gcpbackend und das VPC-Netzwerk default.

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

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.

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), der global über DNS aufgelöst werden kann. Sie können diesen Hostnamen direkt im Hostnamen von „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 der folgende Fehler 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