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

Configurar grupo de endpoints de rede entre projetos

Com o recurso de grupo de endpoints de rede (NEG) entre projetos, os clientes podem anexar NEGs de um projeto diferente a um BackendService do Traffic Director/Cloud Service Mesh, permitindo os seguintes casos de uso:

Em uma implantação de vários projetos, BackendServices com as políticas de roteamento e tráfego associadas em um projeto centralizado, com endpoints de back-end de projetos diferentes.
Em uma implantação de vários projetos, é possível gerenciar todos os recursos de computação (VMs do Compute Engine, NEGs do GKE etc.) em um único projeto central doGoogle Cloud , enquanto as equipes de serviço têm os próprios projetos de serviço do Google Cloud , em que definem políticas de serviço expressas em BackendServices e rotas de roteamento de serviço no respectivo projeto de serviço. Isso delega o gerenciamento dos serviços, mantendo um controle rígido sobre os recursos de computação que podem ser compartilhados entre diferentes equipes de serviços.

Nesta página, mostramos como criar uma configuração básica de dois projetos em que o NEG no projeto B (chamado de projeto de carga de trabalho) é anexado ao BackendService no projeto A (chamado de projeto de política). O exemplo a seguir configura VMs de carga de trabalho na rede VPC padrão do projeto de carga de trabalho e demonstra que o cliente pode fazer o roteamento no projeto de carga de trabalho com base nas configurações do projeto de política.

Exemplo de NEG de referência entre projetos

Em uma configuração mais sofisticada, uma solução como a VPC compartilhada é necessária para um plano de dados interconectado em vários projetos. Isso também implica que os endpoints do NEG têm IPs exclusivos. Essa configuração de exemplo pode ser estendida a cenários mais complicados em que as cargas de trabalho estão em uma rede VPC compartilhada que abrange vários projetos.

Limitações

As limitações gerais do Traffic Director e as limitações do BackendService/NetworkEndpointGroup se aplicam.

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

Um único BackendService pode oferecer suporte a até 50 back-ends(incluindo NEGs e MIGs).
Somente NEGs zonais do tipo GCP_VM_IP_PORT são aceitos.
Não há suporte para BackendServices entre projetos e grupos de instâncias (gerenciados ou não gerenciados).
Não é possível listar NEGs entre projetos que podem ser anexados a um determinado BackendService.
Não é possível listar BackendServices entre projetos que usam um NEG específico.

Antes de começar

Antes de configurar NEGs entre projetos, você precisa atender aos seguintes pré-requisitos:

Ativar 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 comando a seguir para ativar as APIs necessárias no projeto de carga de trabalho e no projeto de política:

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

Conceder as permissões necessárias do IAM

Você precisa ter permissões suficientes do Identity and Access Management (IAM) para concluir este guia. Se você tem o papel de proprietário ou editor (roles/owner ou roles/editor) do projeto em que está ativando o Cloud Service Mesh, você já tem as permissões corretas.

Caso contrário, conceda todos os papéis do IAM a seguir. Se tiver esses papéis, você também terá as permissões associadas, conforme descrito na documentação do IAM do Compute Engine.

Os seguintes papéis são necessários nos dois projetos de carga de trabalho e de política:

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

Os seguintes papéis são necessários apenas no projeto da carga de trabalho:

roles/compute.securityAdmin
roles/container.admin
Qualquer papel que inclua as seguintes permissões. O papel predefinido mais granular que inclui todas as permissõ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 gerenciados pelo Traffic Director (como o proxy Envoy) precisam ter as permissões em roles/trafficdirector.client. Para fins de demonstração, use o comando a seguir para conceder essa permissão no projeto de política à conta de serviço padrão do Compute 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"

em que

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

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

Execute o comando a seguir para direcionar a CLI do Google Cloud ao projeto de carga de trabalho e definir a zona do Compute preferida do Google Cloud :
```
gcloud config set project WORKLOAD_PROJECT_ID
gcloud config set compute/zone ZONE
```
em que
- 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 a seguir cria um cluster zonal do GKE. No entanto, esse recurso 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 plano de controle do Google Cloud envie sondagens de verificação de integridade para back-ends na rede VPC padrão.

Mude o contexto atual do kubectl para o cluster recém-criado:

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

Crie e implante o 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 comando a seguir para armazenar a referência ao NEG em uma variável:
```
NEG_LINK=$(gcloud compute network-endpoint-groups describe example-neg --format="value(selfLink)")
```
O controlador de NEG cria automaticamente um NetworkEndpointGroup zonal para os back-ends de serviço em cada zona. Neste exemplo, o nome do NEG é codificado como example-neg. Armazenar como uma variável será útil na próxima sessão ao anexar esse NEG a um BackendService no projeto de política.

Se você usar o exemplo $NEG_LINK, ele vai ser semelhante a isto:
```
$ echo ${NEG_LINK}
https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
```
Como alternativa, recupere 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"
```

Configurar recursos de rede do Google Cloud no projeto de política

Aponte a CLI do Google Cloud para o projeto de política:
```
gcloud config set project POLICY_PROJECT_ID
```
Configure 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 solicitar a configuração da malha de serviço.

Configure um BackendService de referência com uma verificação de integridade:

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

Anexe o NetworkEndpointGroup criado na seçã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 uma HTTPRoute para direcionar todas as solicitações HTTP com o cabeçalho de host example-service ao 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

em que POLICY_PROJECT_NUMBER é o número do projeto de política.

Verifique a configuração

Para verificar a configuração, envie uma solicitação HTTP com o cabeçalho HOST definido como example-service para um VIP por trás de um proxy sidecar gerenciado pelo Traffic Director:

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

A saída é semelhante a:

{"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"}

Como todo o tráfego de saída dos pods é interceptado por um sidecar do Envoy em uma malha de serviço, e a HTTPRoute anterior está configurada para enviar todo o tráfego para o serviço do Kubernetes "whereami" com base apenas no atributo L7 (cabeçalho do host). Para fins de exemplo, o VIP neste comando é 10.0.0.1, mas pode ser qualquer IP.

O proxy sidecar precisa solicitar configurações associadas ao recurso de malha no projeto de política. Para isso, verifique se o ID do nó está definido no seguinte formato:

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

A seguir

Configurar uma rota de malha entre projetos