Cloud Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Acheminer le trafic des charges de travail Cloud Service Mesh vers les services Cloud Run

Cette page vous explique comment acheminer de manière sécurisée le trafic réseau des charges de travail Cloud Service Mesh sur GKE vers les services Cloud Run.

Notez que lorsque vous acheminez du trafic de GKE vers Cloud Run, il n'est pas nécessaire que le service Cloud Run rejoigne le maillage de services cloud. Toutefois, le service Cloud Run doit se trouver dans le même projet que le cluster GKE Cloud Service Mesh. Cette limite existe tant que cette fonctionnalité est disponible en version Preview publique.

Avant de commencer

Les sections suivantes supposent que vous avez :

Vous pouvez également exécuter les commandes suivantes pour déployer un exemple de service Cloud Run.

Générez un contexte kubeconfig pour votre cluster :
```
gcloud container clusters get-credentials CLUSTER_NAME --project=PROJECT_ID  --location=CLUSTER_LOCATION
```
Où :
- CLUSTER_NAME est le nom de votre cluster.
- PROJECT_ID est l'ID de votre projet.
- CLUSTER_LOCATION est la région ou la zone de votre cluster.

Déployez un exemple de service Cloud Run :

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

Où :

PROJECT_NUMBER est le numéro de votre projet.
PROJECT_ID est l'ID de votre projet.

Configurer IAM

Pour appeler des services Cloud Run, les vérifications Cloud Run Identity and Access Management (IAM) doivent être réussies. Vous devez attribuer le rôle Demandeur Cloud Run au compte de service Google. Vous devez également configurer le compte de service Kubernetes (KSA) GKE pour qu'il emprunte l'identité du compte de service Google.

Procédez comme suit pour autoriser un compte de service Kubernetes à emprunter l'identité d'un compte de service Google.

Ajoutez une liaison de stratégie IAM à un compte de service IAM :
```
gcloud iam service-accounts add-iam-policy-binding PROJECT_NUMBER[email protected] \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]"
```
Où :
- NAMESPACE est le nom de l'espace de noms. Pour les besoins de ce guide, vous pouvez utiliser l'espace de noms default.
- KSA est le nom du compte de service Kubernetes. Pour les besoins de ce guide, vous pouvez utiliser la zone KSA default.

Annotez le compte de service :

kubectl annotate serviceaccount KSA \
  --namespace NAMESPACE \
  iam.gke.io/gcp-service-account=PROJECT_NUMBER[email protected]

Attribuez le rôle Demandeur Cloud Run au compte de service Google :

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

Configurer un service Cloud Run en tant que GCPBackend

Dans cette section, vous allez exposer le service Cloud Run aux charges de travail GKE à l'aide de GCPBackend. GCPBackend se compose des éléments suivants :

Informations sur le frontend, en particulier le nom d'hôte et le port que les charges de travail GKE utiliseraient pour appeler ce GCPBackend.
Informations de backend : détails du service Cloud Run, tels que le nom du service, l'emplacement et le numéro de projet.

GCPBackend contient le nom d'hôte et les informations sur le port, ainsi que les informations sur le service Cloud (nom du service, emplacement et numéro de projet). Les charges de travail GKE doivent utiliser le nom d'hôte et le port GCPBackend dans leurs requêtes HTTP pour accéder au service Cloud Run.

Pour que le nom d'hôte soit résolvable par DNS dans le cluster (par défaut, il ne l'est pas), vous devez configurer Google Cloud DNS pour résoudre tous les hôtes sous un nom d'hôte choisi en une adresse IP arbitraire. Tant que vous n'aurez pas configuré cette entrée DNS, la requête échouera. La configuration DNS Google Cloud est une configuration unique par domaine personnalisé.

Créez une zone gérée :

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

Dans cet exemple, le nom DNS est gcpbackend et le réseau VPC est default.

Configurez l'enregistrement pour que le domaine soit résolvable :

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

Créez le GCPBackend avec un nom d'hôte sous le domaine précédent :

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

Dans cet exemple, GCP_BACKEND_NAME est cr-gcp-backend.

Créez un pod de test pour vérifier la connectivité entre GKE et Cloud Run :

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

Vos charges de travail GKE peuvent désormais accéder au service Cloud Run en envoyant des requêtes HTTP à hello-world.gcpbackend/hello.

Vous devez utiliser des noms distincts pour GCPBackend afin d'éviter tout conflit avec les services Kubernetes ou les entrées de service Istio existants. En cas de conflit, l'ordre de priorité (du plus élevé au plus bas) est le suivant : service Kubernetes, istio ServiceEntry et GCPBackend.

Notez que le service virtuel et le GCPBackend doivent se trouver dans le même espace de noms, et que le service Cloud Run doit se trouver dans le même projet que le cluster GKE Cloud Service Mesh.

(Facultatif) Utiliser le nom d'hôte de Cloud Run au lieu de Cloud DNS

Chaque service Cloud Run se voit attribuer un nom d'hôte (par exemple, hello-world.us-central1.run.app) et peut être résolu par DNS à l'échelle mondiale. Vous pouvez utiliser ce nom d'hôte directement dans le nom d'hôte GCPBackend et ignorer la configuration Cloud DNS.

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

Vos charges de travail GKE peuvent désormais accéder au service Cloud Run en envoyant des requêtes HTTP à hello-world.us-central1.run.app.

(Facultatif) Configurer le service virtuel et/ou la règle de destination Istio

Vous pouvez configurer un service virtuel Istio ou une règle de destination Istio pour le nom d'hôte GCPBackend afin de définir des règles pour les consommateurs ou les clients pour les requêtes adressées à GCPBackend.

L'exemple suivant injecte un délai de cinq secondes à 50 % des requêtes et un abandon (état HTTP 503) à 10 % des requêtes envoyées à GCPBackend.

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

Dans cet exemple, VIRTUAL_SERVICE_NAME est cr-virtual-service.

Dépannage

Cette section vous explique comment résoudre les erreurs courantes liées à Cloud Service Mesh et Cloud Run.

Journaux de side-car Cloud Run

Les erreurs Envoy sont consignées dans Cloud Logging.

Par exemple, une erreur telle que celle ci-dessous sera consignée si le compte de service Cloud Run ne dispose pas du rôle client TrafficDirector dans le projet de maillage :

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

L'état du client Traffic Director peut être récupéré à l'aide de CSDS :

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

Étapes suivantes

Router le trafic des services Cloud Run vers les charges de travail Cloud Service Mesh sur GKE