Traffic von Cloud Run-Diensten an Cloud Service Mesh-Arbeitslasten in GKE weiterleiten

Auf dieser Seite erfahren Sie, wie Sie Netzwerkverkehr sicher von Cloud Run-Diensten zu Cloud Service Mesh-Arbeitslasten in GKE leiten, um Istio APIs und einen vollständig verwalteten Envoy-Sidecar zu verwenden.

Hinweise

In den folgenden Abschnitten wird davon ausgegangen, dass Sie einen GKE-Cluster mit aktiviertem Cloud Service Mesh haben.

Wenn Sie noch keinen GKE-Dienst bereitgestellt haben, können Sie mit dem folgenden Befehl einen Beispieldienst bereitstellen:

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

Benutzerdefinierte Domain für VirtualService-Hosts konfigurieren

Ein virtueller Dienst definiert Traffic-Routingregeln. Übereinstimmender Traffic wird dann an einen benannten Zieldienst gesendet.

  1. So erstellen Sie eine neue verwaltete Zone:

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

    Dabei gilt:

    • ZONE_NAME ist der Name Ihrer Zone (z. B. „prod“).
    • DNS_SUFFIX ist ein beliebiger gültiger DNS-Host (z. B. „mesh.private“).

  2. So erstellen Sie einen Ressourceneintrag:

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

    Die IP-Adresse (RFC 1918 erforderlich) darf nicht verwendet werden. Alternativ können Sie eine statische interne IP-Adresse reservieren.

  3. VirtualService für externe Cloud Run-Kunden exportieren:

    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

    Dabei gilt:

    • VIRTUAL_SERVICE_NAME ist der Name Ihrer VirtualService.
    • NAMESPACE ist default, wenn Sie den bereitgestellten Beispieldienst verwenden. Andernfalls ersetzen Sie NAMESPACE durch den Namen Ihres Namespace.
    • GKE_SERVICE_NAME ist ads, wenn Sie den bereitgestellten Beispieldienst verwenden. Andernfalls ersetzen Sie GKE_SERVICE_NAME durch einen Namen für Ihren GKE-Dienst.

Es ist zwar möglich, einem vorhandenen VirtualService ein external-mesh-Gateway als Ziel hinzuzufügen, Sie sollten jedoch ein eigenes VirtualService erstellen, um einen Kubernetes-Dienst in externe Cloud Run-Clients zu exportieren. Eine separate VirtualService erleichtert die Verwaltung der exportierten Dienste und ihrer Konfigurationen, ohne dass dies Auswirkungen auf vorhandene GKE-Clients hat. Außerdem werden einige Felder in VirtualServices für externe Mesh-VirtualServices ignoriert, funktionieren aber weiterhin wie erwartet für GKE-Dienste. Daher kann es vorteilhaft sein, VirtualServices separat zu verwalten und Fehler separat zu beheben.

Damit GKE-Clients auch die VirtualService-Konfiguration erhalten, muss das mesh- oder mesh/default-Gateway hinzugefügt werden.

Die externe Mesh-VirtualService muss im selben Namespace wie der Kubernetes-Dienst im VirtualService-Ziel definiert sein.

Cloud Run-Dienst für die Teilnahme an einem Service Mesh konfigurieren

So verknüpfen Sie einen Cloud Run-Dienst mit einem Service Mesh:

  1. Ermitteln Sie die Mesh-ID, die dem Cloud Service Mesh-GKE-Cluster zugrunde liegt:

    MESH=$(kubectl get controlplanerevision --namespace istio-system -o json | jq -r '.items[0].metadata.annotations["mesh.cloud.google.com/external-mesh"]')

  2. Stellen Sie einen Cloud Run-Dienst mit der Mesh-ID bereit und achten Sie darauf, auch eine Verbindung zum VPC-Netzwerk des Clusters herzustellen:

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

  3. Prüfen Sie, ob der Cloud Run-Dienst eine Anfrage an die GKE-Arbeitslast senden kann:

    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"

    Die Ausgabe sollte eine gültige HTTP 200-Antwort sein.

Fehlerbehebung

In diesem Abschnitt erfahren Sie, wie Sie häufige Fehler bei Cloud Service Mesh und Cloud Run beheben.

Cloud Run-Sidecar-Logs

Envoy-Fehler werden in Cloud Logging protokolliert.

Wenn dem Cloud Run-Dienstkonto im Mesh-Projekt nicht die Rolle „TrafficDirector-Client“ zugewiesen ist, wird beispielsweise der folgende Fehler protokolliert:

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

Der Traffic Director-Clientstatus kann mit CSDS abgerufen werden:

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

Nächste Schritte