O Cloud Service Mesh e o Traffic Director são agora o Cloud Service Mesh. Para mais informações, consulte a vista geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

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

Esta página mostra-lhe como encaminhar o tráfego de rede de forma segura a partir de cargas de trabalho da Cloud Service Mesh no GKE para serviços do Cloud Run.

Tenha em atenção que, ao encaminhar tráfego do GKE para o Cloud Run, não é necessário que o serviço do Cloud Run se junte à malha de serviços na nuvem. No entanto, o serviço do Cloud Run tem de estar no mesmo projeto que o cluster do GKE do Cloud Service Mesh. Esta limitação existe enquanto esta funcionalidade estiver disponível na pré-visualização pública.

Antes de começar

As secções seguintes pressupõem que:

Em alternativa, pode executar os seguintes comandos para implementar um serviço de exemplo do Cloud Run.

Gere um contexto kubeconfig para o seu cluster:
```
gcloud container clusters get-credentials CLUSTER_NAME --project=PROJECT_ID  --location=CLUSTER_LOCATION
```
Onde:
- CLUSTER_NAME é o nome do seu cluster.
- PROJECT_ID é o ID do projeto.
- CLUSTER_LOCATION é a região ou a zona do seu cluster.

Implemente um serviço de exemplo do Cloud Run:

gcloud run deploy hello-world \
  --image=us-docker.pkg.dev/cloudrun/container/hello \
  --no-allow-unauthenticated \
  --port=8080 \
  --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --region=us-central1 \
  --project=PROJECT_ID

Onde:

PROJECT_NUMBER é o número do seu projeto.
PROJECT_ID é o ID do projeto.

Configure o IAM

Para invocar serviços do Cloud Run, as verificações da gestão de identidade e de acesso (IAM) do Cloud Run têm de ser aprovadas. Tem de conceder a função de invocador do Cloud Run à conta de serviço Google. Também tem de configurar a conta de serviço do Kubernetes (KSA) do GKE para se fazer passar pela conta de serviço Google.

Execute os passos seguintes para permitir que uma conta de serviço do Kubernetes se faça passar por uma conta de serviço da Google.

Adicione uma associação de política de IAM a uma conta de serviço do IAM:
```
gcloud iam service-accounts add-iam-policy-binding PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]"
```
Onde:
- NAMESPACE é o nome do espaço de nomes. Para os efeitos deste guia, pode usar o espaço de nomes default.
- KSA é o nome da conta de serviço do Kubernetes. Para os fins deste guia, pode usar o KSA default.

Anotar a conta de serviço:

kubectl annotate serviceaccount KSA \
  --namespace NAMESPACE \
  iam.gke.io/gcp-service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

Conceda a função de invocador do Cloud Run à conta de serviço Google:

gcloud run services add-iam-policy-binding hello-world \
  --region=us-central1 \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
  --role="roles/run.invoker"

Configure um serviço do Cloud Run como um GCPBackend

Nesta secção, expõe o serviço do Cloud Run aos workloads do GKE através do GCPBackend. O GCPBackend é composto por:

Informações de front-end, especificamente, o nome do anfitrião e a porta que as cargas de trabalho do GKE usariam para chamar este GCPBackend.
Informações de back-end: os detalhes do serviço do Cloud Run, como o nome do serviço, a localização e o número do projeto.

O GCPBackend contém os detalhes do nome do anfitrião e da porta, bem como os detalhes do serviço na nuvem (nome do serviço, localização e número do projeto). As cargas de trabalho do GKE devem usar o nome do anfitrião e a porta do GCPBackend nos respetivos pedidos HTTP para aceder ao serviço do Cloud Run.

Para tornar o nome do anfitrião resolvível por DNS no cluster (por predefinição, não é resolvível), tem de configurar o DNS para resolver todos os anfitriões sob um nome do anfitrião escolhido para um endereço IP arbitrário. Google Cloud Até configurar esta entrada de DNS, o pedido falha. A configuração de DNS é uma configuração única por domínio personalizado. Google Cloud

Crie uma zona gerida:

gcloud dns managed-zones create prod \
    --description="zone for gcpbackend" \
    --dns-name=gcpbackend \
    --visibility=private \
    --networks=default

Neste exemplo, o nome DNS é gcpbackend e a rede VPC é default.

Configure o registo para tornar o domínio resolvível:

gcloud beta dns record-sets create *.gcpbackend \
  --ttl=3600 --type=A --zone=prod \
  --rrdatas=10.0.0.1

Crie o GCPBackend com um nome de anfitrião no domínio anterior:

cat <<EOF > gcp-backend.yaml
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: cr-gcp-backend
  namespace: NAMESPACE
spec:
  hostname: hello-world.gcpbackend
  type: CloudRun
  cloudrun:
    service: hello-world
    regions: [us-central1]
EOF
kubectl apply -f gcp-backend.yaml

Neste exemplo, GCP_BACKEND_NAME é cr-gcp-backend.

Crie um pod de teste para validar a conetividade do GKE ao Cloud Run:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: testcurl
  namespace: default
spec:
  containers:
  - name: curl
    image: curlimages/curl
    command: ["sleep", "3000"]
EOF

kubectl exec testcurl -c curl -- curl http://hello-world.gcpbackend/hello

Agora, as suas cargas de trabalho do GKE podem aceder ao serviço do Cloud Run enviando pedidos HTTP para hello-world.gcpbackend/hello.

Deve usar nomes distintos para o GCPBackend para evitar conflitos com os serviços Kubernetes ou as entradas de serviço do Istio existentes. Se existir um conflito, a ordem de precedência (de alta para baixa) é: serviço Kubernetes, ServiceEntry do Istio e GCPBackend.

Tenha em atenção que o serviço virtual e o GCPBackend têm de estar no mesmo espaço de nomes e o serviço do Cloud Run tem de estar no mesmo projeto que o cluster do GKE do Cloud Service Mesh.

(Opcional) Use o nome do anfitrião do Cloud Run em vez do Cloud DNS

A cada serviço do Cloud Run é atribuído um nome de anfitrião (por exemplo, hello-world.us-central1.run.app) e é resolvível por DNS a nível global. Pode usar este nome de anfitrião diretamente no nome de anfitrião do GCPBackend e ignorar a configuração do Cloud DNS.

cat <<EOF | kubectl apply -f -
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: cr-gcp-backend
  namespace: NAMESPACE
spec:
  hostname: hello-world.us-central1.run.app
  type: CloudRun
  cloudrun:
    service: hello-world
    region: [us-central1]
EOF

Agora, as suas cargas de trabalho do GKE podem aceder ao serviço do Cloud Run enviando pedidos HTTP para hello-world.us-central1.run.app.

(Opcional) Configure o serviço virtual do Istio e/ou a regra de destino

Pode configurar o serviço virtual do Istio ou a regra de destino do Istio para o nome do anfitrião do GCPBackend para definir políticas de consumidor ou cliente para pedidos ao GCPBackend.

O exemplo seguinte injeta um atraso de 5 s em 50% dos pedidos e anula (estado http 503) 10% dos pedidos enviados para o GCPBackend.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cr-virtual-service
  namespace: NAMESPACE
spec:
  hosts:
  - hello-world.us-central1.run.app
  gateways:
  - mesh
  http:
  - fault:
      delay:
        percentage:
          value: 50  # Delay 50% of requests
        fixedDelay: 5s
      abort:
        percentage:
          value: 10  # Abort 10% of requests
        httpStatus: 503
  - route:
    - destination:
        host: hello-world.us-central1.run.app
EOF

Neste exemplo, VIRTUAL_SERVICE_NAME é cr-virtual-service.

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?

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