Indirizza 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 di 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 abbia 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 instradamento del traffico. Tutto il traffico corrispondente viene quindi inviato a un servizio di destinazione nominato

  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 tua 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 (obbligatorio RFC 1918) non sia utilizzato. In alternativa, prenota un IP interno statico.

  3. Esporta un file 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 dello 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. Avere un VirtualService distinto facilita la gestione dei servizi esportati e delle relative configurazioni senza influire sui client GKE esistenti. Inoltre, alcuni campi in VirtualServices vengono ignorati per VirtualServices esterno mesh, ma continuano a funzionare come previsto per i servizi GKE. Pertanto, la gestione e la risoluzione dei problemi relativi a VirtualServices separatamente potrebbe essere vantaggiosa.

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

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

Configurare un servizio Cloud Run per partecipare a un mesh di servizi

Per unire un servizio Cloud Run a un mesh di servizi, svolgi i seguenti passaggi:

  1. Determina l'ID mesh alla base del 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. 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 dovrebbe essere una risposta HTTP 200 valida.

Risoluzione dei problemi

Questa sezione mostra come risolvere gli errori comuni di Cloud Service Mesh e Cloud Run.

Log del sidecar Cloud Run

Gli errori di Envoy vengono registrati in Cloud Logging.

Ad esempio, se all'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 trafficdirector può essere recuperato utilizzando CSDS:

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

Passaggi successivi