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 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 projetoGoogle Cloud central, enquanto as equipes de serviço têm os próprios projetos de serviço 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.

Esta página mostra como criar uma configuração de referência de dois projetos em que o NEG no projeto A (chamado de projeto de carga de trabalho) é anexado ao BackendService no projeto B (chamado de projeto de política). O exemplo a seguir configura VMs de carga de trabalho na rede VPC padrão no projeto de carga de trabalho e demonstra que o cliente pode rotear para o projeto de carga de trabalho com base nas 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 NEG têm IPs exclusivos. Esse exemplo de configuração pode ser estendido para cenários mais complexos em que os workloads 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 para uma configuração de vários projetos:

  • Um único BackendService só pode ter 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).
  • 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

É necessário concluir os seguintes pré-requisitos antes de configurar NEGs entre projetos.

Ative as APIs necessárias

As APIs a seguir 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 este 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 seguintes papéis do IAM. Se você tiver esses papéis, 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 em ambos os projetos de políticas e de cargas de trabalho:

  • 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 comando a seguir para conceder essa permissão no projeto de política à conta de serviço de computação padrão 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 de carga de trabalho.

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

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

    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.

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

  3. 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 Google Cloud envie sondagens de verificação de integridade para back-ends na rede VPC padrão.

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

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

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

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

    Por exemplo, $NEG_LINK, que deve ser semelhante a este:

    $ echo ${NEG_LINK}
https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg

    Como alternativa, é possível recuperar 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 Google Cloud recursos de rede no projeto de política

  1. Aponte a Google Cloud CLI para o projeto de política:

    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 da malha é a chave que os proxies sidecar usam para solicitar a configuração da malha de serviço.

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

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

  5. Crie um HTTPRoute para direcionar todas as solicitações HTTP com cabeçalho de host example-service ao servidor no projeto de 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

É possível 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 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 é 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 pode ser qualquer IP.

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

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

A seguir