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

Cette page explique comment router de manière sécurisée le trafic réseau des services Cloud Run vers les charges de travail Cloud Service Mesh sur GKE afin d'utiliser les API Istio et de profiter d'un side-car Envoy entièrement géré.

Avant de commencer

Les sections suivantes supposent que vous disposez d'un cluster GKE sur lequel Cloud Service Mesh est activé.

Si aucun service GKE n'est déployé, utilisez la commande suivante pour déployer un exemple de service :

cat <<EOF > /tmp/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: ads
spec:
  ports:
  - port: 9999
    targetPort: 8000
  selector:
    run: ads
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ads
spec:
  replicas: 1
  selector:
    matchLabels:
      run: ads
  template:
    metadata:
      labels:
        run: ads
    spec:
      containers:
      - image: docker.io/waip/simple-http:v1.0.1
        name: my-http2-svc
        ports:
        - protocol: TCP
          containerPort: 8000
      securityContext:
        fsGroup: 1337
EOF
kubectl apply -f /tmp/service.yaml

Configurer un domaine personnalisé pour les hôtes VirtualService

Un service virtuel définit des règles de routage du trafic. Tout trafic correspondant est ensuite envoyé à un service de destination nommé.

  1. Pour créer une zone gérée :

    gcloud dns managed-zones create ZONE_NAME \
  --description="zone for service mesh routes" \
  --dns-name=DNS_SUFFIX. \
  --networks=default \
  --visibility=private

    où :

    • ZONE_NAME est le nom de votre zone (par exemple, « prod »).
    • DNS_SUFFIX est n'importe quel hôte DNS valide (par exemple, « mesh.private »).

  2. Pour créer un jeu d'enregistrements de ressources :

    IP=10.0.0.1
gcloud dns record-sets create '*.'"DNS_SUFFIX." --type=A --zone="ZONE_NAME" \
  --rrdatas=10.0.0.1 --ttl 3600

    Assurez-vous que l'adresse IP (RFC 1918 requise) n'est pas utilisée. Vous pouvez également réserver une adresse IP interne statique.

  3. Pour exporter un VirtualService pour les clients Cloud Run externes :

    cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: VIRTUAL_SERVICE_NAME
  namespace: NAMESPACE
spec:
  hosts:
  - GKE_SERVICE_NAME.DNS_SUFFIX
  gateways:
  - external-mesh
  http:
  - route:
    - destination:
        host: GKE_SERVICE_NAME
EOF
kubectl apply -f virtual-service.yaml

    où :

    • VIRTUAL_SERVICE_NAME est le nom de votre VirtualService.
    • NAMESPACE est default si vous utilisez l'exemple de service fourni . Sinon, remplacez NAMESPACE par le nom de votre espace de noms.
    • GKE_SERVICE_NAME est ads si vous utilisez l'exemple fourni de service. Sinon, remplacez GKE_SERVICE_NAME par le nom de votre service GKE.

Bien qu'il soit possible d'ajouter une passerelle external-mesh en tant que cible à un VirtualService préexistant, vous devez établir un VirtualService distinct pour exporter un service Kubernetes vers des clients Cloud Run externes. Un VirtualService distinct facilite la gestion des services exportés et de leurs configurations sans affecter les clients GKE existants. De plus, certains champs de VirtualServices ne sont pas pris en compte pour les VirtualServices externes au maillage, mais continuent de fonctionner comme prévu pour les services GKE. Il peut donc être avantageux de gérer et de dépanner les VirtualServices séparément.

Pour que les clients GKE reçoivent également la configuration VirtualService, vous devez ajouter la passerelle mesh ou mesh/default.

Le VirtualService externe au maillage doit être défini dans le même espace de noms que le service Kubernetes dans la destination VirtualService.

Configurer un service Cloud Run pour qu'il rejoigne un maillage de services

Pour qu'un service Cloud Run rejoigne un maillage de services, procédez comme suit :

  1. Déterminez l'ID de maillage qui sauvegarde le cluster GKE Cloud Service Mesh :

    MESH=$(kubectl get controlplanerevision --namespace istio-system -o json | jq -r '.items[0].metadata.annotations["mesh.cloud.google.com/external-mesh"]')

  2. Déployez un service Cloud Run à l'aide de l'ID de maillage, en veillant à vous connecter également au réseau VPC du cluster :

    gcloud alpha run deploy --mesh "$MESH" --network default \
  mesh-svc --image=fortio/fortio \
  --region=REGION --project=PROJECT_ID --no-allow-unauthenticated

  3. Vérifiez que le service Cloud Run peut envoyer une requête à la charge de travail GKE :

    TEST_SERVICE_URL=$(gcloud run services describe mesh-svc --region REGION --format="value(status.url)" --project=PROJECT_ID)

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" "$TEST_SERVICE_URL/fortio/fetch/GKE_SERVICE_NAME.DNS_SUFFIX"

    La sortie doit être une réponse HTTP 200 valide.

Dépannage

Cette section 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 semblable à la suivante 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 trafficdirector 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:
....

Étape suivante