Instrada il traffico dai servizi Cloud Run ai workload Cloud Service Mesh su GKE

La connessione dei servizi Cloud Run a Cloud Service Mesh consente di instradare in modo sicuro il traffico ai workload su GKE. Questa configurazione utilizza le API Istio e un proxy sidecar Envoy completamente gestito per gestire la comunicazione dei servizi tra gli ambienti.

Prima di iniziare

Le sezioni seguenti presuppongono che tu disponga di un cluster GKE con Cloud Service Mesh abilitato.

Se non hai eseguito il deployment di un servizio GKE, utilizza il seguente comando per eseguire il deployment di un servizio di esempio:

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

Configura un dominio personalizzato per gli host VirtualService

Un servizio virtuale definisce le regole di instradamento del traffico. Il traffico corrispondente viene quindi inviato a un servizio di destinazione denominato

  1. Crea una nuova zona gestita:

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

    dove:

    • ZONE_NAME è un nome per la zona (ad esempio "prod").
    • DNS_SUFFIX è un host DNS valido (ad esempio "mesh.private").

  2. Crea un set di record di risorse:

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

    Assicurati che l'IP (RFC 1918 obbligatorio) non sia utilizzato. In alternativa, prenota un IP interno statico.

  3. Esporta un VirtualService per i client Cloud Run esterni:

    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

    dove:

    • VIRTUAL_SERVICE_NAME è un nome per il tuo VirtualService.
    • NAMESPACE è default se utilizzi il servizio di esempio fornito; in caso contrario, sostituisci NAMESPACE con il nome del tuo spazio dei nomi.
    • GKE_SERVICE_NAME è ads se utilizzi il servizio di esempio fornito; in caso contrario, sostituisci GKE_SERVICE_NAME con un nome per il tuo servizio GKE.

Sebbene sia possibile aggiungere un gateway external-mesh come target a un VirtualService preesistente, devi stabilire un VirtualService distinto per esportare un servizio Kubernetes ai client Cloud Run esterni. La presenza di un VirtualService separato facilita la gestione dei servizi esportati e delle relative configurazioni senza influire sui client GKE esistenti. Inoltre, alcuni campi di VirtualServices vengono ignorati per il mesh esterno VirtualServices, ma continuano a funzionare come previsto per i servizi GKE. Pertanto, la gestione e la risoluzione dei problemi di VirtualServices separatamente possono essere vantaggiose.

Affinché anche i client GKE ricevano la configurazione VirtualService, è necessario aggiungere il gateway mesh o mesh/default.

La risorsa VirtualService esterna del mesh deve essere definita nello stesso spazio dei nomi del servizio Kubernetes nella destinazione VirtualService.

Configura un servizio Cloud Run per l'unione a un mesh di servizi

Per unire un servizio Cloud Run a un mesh di servizi, segui questi passaggi:

  1. Determina l'ID mesh che supporta il cluster GKE di 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. Esegui il deployment di un servizio Cloud Run utilizzando l'ID mesh, assicurandoti di connetterti anche alla rete VPC del cluster:

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

  3. Verifica che il servizio Cloud Run sia in grado di inviare una richiesta al workload 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"

    L'output deve essere una risposta HTTP 200 valida.

Risoluzione dei problemi

Questa sezione mostra come risolvere i problemi comuni di Cloud Service Mesh e Cloud Run.

Log sidecar di Cloud Run

Gli errori di Envoy vengono registrati in Cloud Logging.

Ad esempio, se al account di servizio Cloud Run non viene assegnato il ruolo client Traffic Director nel progetto mesh, verrà registrato un errore simile al seguente:

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

Lo stato del client Traffic Director può essere recuperato utilizzando CSDS:

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

Passaggi successivi