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

Questa pagina mostra come instradare in modo sicuro il traffico di rete dai servizi Cloud Run ai carichi di lavoro Cloud Service Mesh su GKE per utilizzare le API Istio e sfruttare un sidecar Envoy completamente gestito.

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

Configurare un dominio personalizzato per gli host VirtualService

Un servizio virtuale definisce le regole di routing 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 richiesto) 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 destinazione a un VirtualService preesistente, devi stabilire un VirtualService distinto per esportare un servizio Kubernetes in 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 in 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 potrebbe essere vantaggiosa.

Per consentire ai client GKE di ricevere anche la configurazione VirtualService, deve essere aggiunto il gateway mesh o mesh/default.

VirtualService esterno del mesh deve essere definito nello stesso spazio dei nomi del servizio Kubernetes nella destinazione VirtualService.

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

Per unire un servizio Cloud Run a un mesh di servizi:

  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 carico di lavoro 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 gli errori comuni con Cloud Service Mesh e Cloud Run.

Log di Cloud Run Sidecar

Gli errori di Envoy vengono registrati in Cloud Logging.

Ad esempio, se al account di servizio Cloud Run non viene assegnato il ruolo client trafficdirector nel progetto mesh, verrà registrato un errore come il 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