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.

Configure um grupo de pontos finais de rede entre projetos

A funcionalidade de grupo de pontos finais de rede (NEG) entre projetos permite aos clientes anexar NEGs de um projeto diferente a um Traffic Director/Cloud Service Mesh BackendService, o que permite os seguintes exemplos de utilização:

Numa implementação com vários projetos, BackendServices, juntamente com as respetivas políticas de encaminhamento e tráfego associadas, num projeto centralizado, com pontos finais de back-end de diferentes projetos.
Numa implementação com vários projetos, pode gerir todos os seus recursos de computação (VMs do Compute Engine, NEGs do GKE, etc.) num únicoGoogle Cloud projeto Google Cloud central, enquanto as equipas de serviço detêm os seus próprios projetos de serviço, onde definem políticas de serviço expressas em BackendServices e rotas de encaminhamento de serviços no respetivo projeto de serviço. Isto delega a gestão dos respetivos serviços, mantendo um controlo rigoroso sobre os recursos de computação que podem ser partilhados entre diferentes equipas de serviços.

Esta página mostra como criar uma configuração de 2 projetos de base em que a NEG no projeto B (denominado projeto de carga de trabalho) está anexada à BackendService no projeto A (denominado projeto de política). O exemplo seguinte configura VMs de carga de trabalho na rede VPC predefinida no projeto de carga de trabalho e demonstra que o cliente pode encaminhar para o projeto de carga de trabalho com base nas configurações no projeto de políticas.

Exemplo de NEG entre projetos de base

Numa configuração mais sofisticada, é necessária uma solução como a VPC partilhada para um plano de dados interligado em vários projetos. Isto também implica que os pontos finais NEG têm IPs únicos. Esta configuração de exemplo pode ser expandida para cenários mais complexos em que as cargas de trabalho estão numa rede VPC partilhada que abrange vários projetos.

Limitações

Aplicam-se as limitações gerais do Traffic Director e as limitações do BackendService/NetworkEndpointGroup.

As seguintes limitações também se aplicam, mas podem não ser específicas de uma configuração com vários projetos:

Um único BackendService só pode suportar até 50 back-ends(incluindo NEGs e MIGs).
Apenas são suportados NEGs zonais do tipo GCP_VM_IP_PORT.
A referência de BackendServices entre projetos a grupos de instâncias (geridos ou não geridos) não é suportada.
Não é suportada a listagem de NEGs entre projetos que podem ser anexados a um determinado BackendService.
Não é suportada a listagem de BackendServices entre projetos que estejam a usar um NEG específico.

Antes de começar

Tem de concluir os seguintes pré-requisitos antes de poder configurar NEGs entre projetos.

Ative as APIs necessárias

As seguintes APIs são necessárias para concluir este guia:

osconfig.googleapis.com
trafficdirector.googleapis.com
compute.googleapis.com
networkservices.googleapis.com

Execute o seguinte comando para ativar as APIs necessárias no projeto de carga de trabalho e no projeto de políticas:

gcloud services enable --project PROJECT_ID \
    osconfig.googleapis.com \
    trafficdirector.googleapis.com \
    compute.googleapis.com \
    networkservices.googleapis.com

Conceda as autorizações de IAM necessárias

Tem de ter autorizações de gestão de identidade e de acesso (IAM) suficientes para concluir este guia. Se tiver a função de proprietário ou editor do projeto (roles/owner ou roles/editor) no projeto onde está a ativar o Cloud Service Mesh, tem automaticamente as autorizações corretas.

Caso contrário, tem de conceder todas as seguintes funções de IAM. Se tiver estas funções, também tem as respetivas autorizações associadas, conforme descrito na documentação do IAM do Compute Engine.

As seguintes funções são necessárias tanto no projeto de carga de trabalho como no projeto de política:

roles/iam.serviceAccountAdmin
roles/serviceusage.serviceUsageAdmin
roles/compute.networkAdmin

As seguintes funções são necessárias apenas no projeto da carga de trabalho:

roles/compute.securityAdmin
roles/container.admin
Qualquer função que inclua as seguintes autorizações. A função predefinida mais detalhada que inclui todas as autorizações necessárias para anexar um NEG a um BackendService é roles/compute.loadBalancerServiceUser
- compute.networkEndpointGroups.get
- compute.networkEndpointGroups.use

Além disso, os clientes xDS geridos pelo Traffic Director (como o proxy Envoy) têm de ter as autorizações em roles/trafficdirector.client. Para fins de demonstração, pode usar o seguinte comando para conceder esta autorização no projeto de políticas à conta de serviço de computação predefinida do projeto de carga de trabalho:

gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member "serviceAccount:WORKLOAD_PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role "roles/trafficdirector.client"

onde

POLICY_PROJECT_ID é o ID do projeto da política.
WORKLOAD_PROJECT_NUMBER é o número do projeto do projeto da carga de trabalho.

Configure um back-end de serviço no projeto de carga de trabalho

Execute o seguinte comando para direcionar a CLI do Google Cloud para o projeto de carga de trabalho e definir a zona de computação preferencial: Google Cloud
```
gcloud config set project WORKLOAD_PROJECT_ID
gcloud config set compute/zone ZONE
```
onde
- WORKLOAD_PROJECT_ID é o ID do projeto da carga de trabalho.
- ZONE é a zona do cluster do GKE, por exemplo, us-central1.
Crie um cluster do GKE. Para fins de demonstração, o comando seguinte cria um cluster do GKE zonal. No entanto, esta funcionalidade também funciona em clusters regionais do GKE.
```
gcloud container clusters create test-cluster \
    --scopes=https://www.googleapis.com/auth/cloud-platform
    --zone=ZONE
```

Crie uma regra de firewall:

gcloud compute firewall-rules create http-allow-health-checks \
    --network=default \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --rules=tcp:80

Uma regra de firewall permite que o Google Cloud plano de controlo envie sondas de verificação de estado para back-ends na rede da VPC predefinida.

Altere o contexto atual do kubectl para o cluster criado recentemente:

gcloud container clusters get-credentials test-cluster \
    --zone=ZONE

Crie e implemente a app de exemplo whereami:

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whereami
  template:
    metadata:
      labels:
        app: whereami
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: whereami
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-neg"}}}'
spec:
  selector:
    app: whereami
  ports:
  - port: 8080
    targetPort: 8080
EOF

Execute o seguinte comando para armazenar a referência ao NEG numa variável:
```
NEG_LINK=$(gcloud compute network-endpoint-groups describe example-neg --format="value(selfLink)")
```
O controlador NEG cria automaticamente um NetworkEndpointGroup zonal para os back-ends de serviço em cada zona. Neste exemplo, o nome do NEG está codificado de forma rígida para example-neg. Armazená-lo como uma variável é útil na sessão seguinte quando anexar este NEG a um BackendService no projeto de políticas.

Se usar o exemplo $NEG_LINK, o resultado deve ser semelhante ao seguinte:
```
$ echo ${NEG_LINK}
https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
```
Em alternativa, pode obter o URL do NEG lendo a anotação neg-status no serviço:
```
kubectl get service whereami -o jsonpath="{.metadata.annotations['cloud\.google\.com/neg-status']}"
NEG_LINK="https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT_ID/zones/ZONE/networkEndpointGroups/example-neg"
```

Configure Google Cloud recursos de rede no projeto de políticas

Direcione a Google Cloud CLI para o projeto de políticas:
```
gcloud config set project POLICY_PROJECT_ID
```
Configura um recurso de malha:
```
gcloud network-services meshes import example-mesh --source=- --location=global << EOF
name: example-mesh
EOF
```
O nome do recurso de malha é a chave que os proxies sidecar usam para pedir a configuração da malha de serviço.

Configure uma base de referência BackendService com uma verificação de funcionamento:

gcloud compute health-checks create http http-example-health-check

gcloud compute backend-services create example-service \
  --global \
  --load-balancing-scheme=INTERNAL_SELF_MANAGED \
  --protocol=HTTP \
  --health-checks http-example-health-check

Anexa o NetworkEndpointGroup criado na secção anterior ao BackendService:

gcloud compute backend-services add-backend example-service --global \
  --network-endpoint-group=${NEG_LINK} \
  --balancing-mode=RATE \
  --max-rate-per-endpoint=5

Crie um HTTPRoute para direcionar todos os pedidos HTTP com o cabeçalho do anfitrião example-service para o servidor no projeto da carga de trabalho:

gcloud network-services http-routes import example-route --source=- --location=global << EOF
name: example-route
hostnames:
- example-service
meshes:
- projects/POLICY_PROJECT_NUMBER/locations/global/meshes/example-mesh
rules:
- action:
    destinations:
    - serviceName: "projects/POLICY_PROJECT_NUMBER/locations/global/backendServices/example-service"
EOF

onde POLICY_PROJECT_NUMBER é o número do projeto do projeto de políticas.

Valide a configuração

Pode validar a configuração enviando um pedido HTTP com o cabeçalho HOST definido como example-service para um VIP atrás de um proxy sidecar gerido pelo Traffic Director:

curl -H "Host: example-service" http://10.0.0.1/

O resultado é semelhante ao seguinte:

{"cluster_name":"test-cluster","gce_instance_id":"4879146330986909656","gce_service_account":"...","host_header":"example-service","pod_name":"whereami-7fbffd489-nhkfg","pod_name_emoji":"...","project_id":"...","timestamp":"2024-10-15T00:42:22","zone":"us-west1-a"}

Tenha em atenção que, uma vez que todo o tráfego de saída dos pods é intercetado por um sidecar do Envoy numa malha de serviços, e o HTTPRoute anterior está configurado para enviar todo o tráfego para o serviço Kubernetes "whereami" puramente com base no atributo L7 (cabeçalho do anfitrião). Para fins de exemplo, o VIP neste comando é 10.0.0.1, mas o VIP pode ser qualquer IP.

O proxy sidecar deve pedir configurações associadas ao recurso de malha no projeto de política. Para o fazer, certifique-se de que o ID do nó está definido no seguinte formato:

projects/POLICY_PROJECT_NUMBER/networks/mesh:example-mesh/nodes/UUID"

O que se segue?

Configure uma rota de malha entre projetos