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

Cette page explique comment acheminer 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 avec Cloud Service Mesh activé.

Si vous n'avez pas déployé de service GKE, 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 correspond à n'importe quel hôte DNS valide (par exemple, "mesh.private").

  2. Créez 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. 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 de service fourni. Sinon, remplacez GKE_SERVICE_NAME par un nom pour 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. Le fait d'avoir 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 sont ignorés 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 VirtualServices séparément.

Pour que les clients GKE reçoivent également la configuration VirtualService, la passerelle mesh ou mesh/default doit être ajoutée.

Le VirtualService externe du 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 associer un service Cloud Run à un maillage de services, procédez comme suit :

  1. Déterminez l'ID du maillage qui sous-tend 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 du maillage, en veillant également à vous connecter 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 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