Configure um grupo de pontos finais de rede entre projetos

Nota: este guia só suporta a Cloud Service Mesh com Google Cloud APIs e não suporta as APIs Istio. Para mais informações, consulte o artigo Vista geral do Cloud Service Mesh.

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 A (denominado projeto de carga de trabalho) está anexada à BackendService no projeto B (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.

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:[e-mail]" \
    --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

1. Execute o seguinte comando para direcionar a Google Cloud CLI para o projeto de política e definir a Google Cloud zona de computação preferencial:

   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.

2. 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
   

3. 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.

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

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

5. 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
   

6. 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

1. Direcione a Google Cloud CLI para o projeto de políticas:

   gcloud config set project POLICY_PROJECT_ID
   

2. 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.

3. 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
   

4. 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
   

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