Instrada 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 workload 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

Configura un dominio personalizzato per gli host VirtualService

Un servizio virtuale definisce le regole di routing del traffico. Tutto 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 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 target a un VirtualService preesistente, devi stabilire un VirtualService distinto per esportare un servizio Kubernetes ai client Cloud Run esterni. Avere un VirtualService separato semplifica la gestione dei servizi esportati e delle relative configurazioni senza influire sui client GKE esistenti. Inoltre, alcuni campi in VirtualServices vengono ignorati per i VirtualServices esterni al mesh, ma continuano a funzionare come previsto per i servizi GKE. Pertanto, la gestione e la risoluzione dei problemi di VirtualServices separatamente potrebbe essere vantaggiosa.

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

Il VirtualService esterno al 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 aggiungere un servizio Cloud Run a un mesh di servizi:

  1. Determina l'ID mesh che supporta il 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 deve essere una risposta HTTP 200 valida.

Risoluzione dei problemi

Questa sezione mostra come risolvere i problemi relativi agli errori comuni con 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 trafficdirector 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 trafficdirector può essere recuperato utilizzando CSDS:

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

Passaggi successivi