Encaminhe o tráfego dos serviços do Cloud Run para cargas de trabalho do Cloud Service Mesh no GKE

Esta página mostra como encaminhar o tráfego de rede de forma segura dos serviços do Cloud Run para as cargas de trabalho do Cloud Service Mesh no GKE para usar as APIs Istio e tirar partido de um sidecar do Envoy totalmente gerido.

Antes de começar

As secções seguintes partem do princípio de que tem um cluster do GKE com a Cloud Service Mesh ativada.

Se não tiver um serviço do GKE implementado, use o seguinte comando para implementar um serviço de exemplo:

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

Configure um domínio personalizado para anfitriões VirtualService

Um serviço virtual define regras de encaminhamento de tráfego. Em seguida, todo o tráfego correspondente é enviado para um serviço de destino designado

  1. Para criar uma nova zona gerida:

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

    where:

    • ZONE_NAME é um nome para a sua zona (exemplo: "prod").
    • DNS_SUFFIX é qualquer anfitrião de DNS válido (exemplo: "mesh.private").

  2. Crie um conjunto de registos de recursos:

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

    Certifique-se de que o IP (RFC 1918 obrigatório) não está a ser usado. Em alternativa, reserve um IP interno estático.

  3. Exporte um VirtualService para clientes externos do Cloud Run:

    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

    where:

    • VIRTUAL_SERVICE_NAME é um nome para o seu VirtualService.
    • NAMESPACE é default se estiver a usar o serviço de exemplo fornecido; caso contrário, substitua NAMESPACE pelo nome do seu espaço de nomes.
    • GKE_SERVICE_NAME é ads se estiver a usar o serviço de exemplo fornecido; caso contrário, substitua GKE_SERVICE_NAME por um nome para o seu serviço do GKE.

Embora seja possível adicionar um gateway external-mesh como destino a um VirtualService pré-existente, deve estabelecer um VirtualService distinto para exportar um serviço Kubernetes para clientes externos do Cloud Run. Ter um VirtualService separado facilita a gestão dos serviços exportados e das respetivas configurações sem afetar os clientes do GKE existentes. Além disso, alguns campos em VirtualServices são ignorados para a malha externa, mas continuam a funcionar conforme previsto para os serviços GKE.VirtualServices Assim, a gestão e a resolução de problemas do VirtualServices separadamente pode ser vantajosa.

Para que os clientes do GKE também recebam a configuração VirtualService, tem de adicionar o gateway mesh ou mesh/default.

O VirtualService externo da malha tem de ser definido no mesmo espaço de nomes que o serviço Kubernetes no destino VirtualService.

Configure um serviço do Cloud Run para aderir a uma malha de serviço

Para associar um serviço do Cloud Run a uma malha de serviços, siga estes passos:

  1. Determine o ID da malha que suporta o cluster do GKE do 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. Implemente um serviço do Cloud Run com o ID da malha, certificando-se de que também se liga à rede VPC do cluster:

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

  3. Verifique se o serviço do Cloud Run consegue enviar um pedido para a carga de trabalho do 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"

    A saída deve ser uma resposta HTTP 200 válida.

Resolução de problemas

Esta secção mostra-lhe como resolver problemas comuns com o Cloud Service Mesh e o Cloud Run.

Registos de sidecar do Cloud Run

Os erros do Envoy são registados no Registos na nuvem.

Por exemplo, é registado um erro como o seguinte se a conta de serviço do Cloud Run não tiver a função de cliente do Traffic Director no projeto da malha:

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

O estado do cliente do Traffic Director pode ser obtido através do CSDS:

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

O que se segue?