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.

Esta página foi traduzida pela API Cloud Translation.

Configurar um grupo de endpoints de rede entre projetos

O recurso de grupo de endpoints de rede (NEG) entre projetos permite que os clientes vinculem 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 e as políticas de roteamento e tráfego associadas a ele são centralizados em um projeto. com endpoints de back-end de diferentes projetos.
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 uma única central um projeto do Google Cloud, e as equipes de serviço são proprietárias do próprio serviço do Google Cloud. projetos em que elas definem as 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 próximo sobre os recursos que podem ser compartilhados entre equipes de serviço diferentes.

Nesta página, mostramos como criar uma configuração de referência de dois projetos em que o NEG o projeto A (chamado de projeto de carga de trabalho) está anexado ao BackendService no projeto B (conhecido como projeto de política). O seguinte exemplo, configura VMs de carga de trabalho na rede VPC padrão do projeto de carga de trabalho e demonstra que o cliente pode encaminhar para o projeto de carga de trabalho com base na as configurações no 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 de NEG têm IPs exclusivos. Essa configuração de exemplo pode ser estendida cenários complicados em que as cargas de trabalho estão em uma rede VPC compartilhada abrangendo vários projetos.

Limitações

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

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

Um único BackendService oferece 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 referência de BackendServices entre projetos e grupos de instâncias (gerenciados ou não gerenciados).
A listagem dos NEGs entre projetos que podem ser anexados a um determinado BackendService é não tem suporte.
Não é possível listar os BackendServices entre projetos que usam um NEG específico suporte.

Antes de começar

É necessário concluir os seguintes pré-requisitos antes de 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 comando abaixo 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 esta guia. Se você tem o papel de proprietário ou editor (roles/owner ou roles/editor) do projeto em que está ativando a Cloud Service Mesh, você já tem as permissões corretas.

Caso contrário, você precisa conceder todos os papéis do IAM a seguir. Se você tiver esses papéis, você também tem as permissões associadas a eles, conforme descrito em as Documentação do IAM do Compute Engine.

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

roles/iam.serviceAccountAdmin
roles/serviceusage.serviceUsageAdmin
papéis/compute.networkAdmin

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

roles/compute.securityAdmin
roles/container.admin
Qualquer função 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 seguinte comando para conceder essa permissão no projeto de política para a 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 de política.
WORKLOAD_PROJECT_NUMBER é o número do projeto da carga de trabalho. projeto.

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

Execute o comando a seguir para apontar a Google Cloud CLI para o projeto de política e defina a zona do Compute do Google Cloud preferida:
```
gcloud config set project WORKLOAD_PROJECT_ID
gcloud config set compute/zone ZONE
```
em que
- WORKLOAD_PROJECT_ID é o ID do projeto de 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 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
```

Criar 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 a verificação de integridade faz sondagem em back-ends na rede VPC padrão.

Altere 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: gcr.io/google-samples/whereami:v1.2.20
        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 NEG é fixado em example-neg. Armazená-lo como uma variável será útil na próxima sessão ao anexar esse NEG a um BackendService no projeto de política.

O exemplo de $NEG_LINK deve ser semelhante ao seguinte:
```
$ 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 o valor 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
```
Configura um recurso de malha:
```
gcloud network-services meshes import example-mesh --source=- --location=global << EOF
name: example-mesh
EOF
```
O nome do recurso da malha é a chave que os proxies de arquivo secundário 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

Criar um HTTPRoute para direcionar todas as solicitações HTTP com cabeçalho do 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

Você pode verificar a configuração enviando uma solicitação HTTP com o cabeçalho HOST definido como example-service para um VIP por trás de um proxy sidecar gerenciado do 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 é configurada para enviar todo o tráfego para o serviço "whereami" do Kubernetes com base no atributo L7 (cabeçalho do host). Por exemplo, o VIP neste comando é 10.0.0.1, mas o VIP pode ser qualquer IP.

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

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

A seguir

Configurar a rota de mesh entre projetos