Configurar um grupo de endpoints de rede entre projetos

Observação: este guia só oferece suporte ao Cloud Service Mesh com APIs Google Cloud e não é compatível com as APIs do Istio. Para mais informações, consulte Visão geral do Cloud Service Mesh.

Prévia

Este produto ou recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos gerais de serviço" dos Termos específicos de serviço. Os produtos e recursos pré-GA estão disponíveis no estado em que se encontram e podem ter suporte limitado. Para mais informações, consulte as descrições das fases de lançamento.

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

Nesta página, mostramos como criar uma configuração básica 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 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.

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 referência entre projetos de BackendServices 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:

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 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 você tiver esses papéis, também terá as permissões associadas, conforme descrito na documentação do IAM do Compute Engine.

As seguintes funções são necessárias nos dois projetos de carga de trabalho e de política:

• roles/iam.serviceAccountAdmin
• roles/serviceusage.serviceUsageAdmin
• papéis/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 de computação padrão do projeto de carga de trabalho:

gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member "serviceAccount:[e-mail]" \
    --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

1. Execute o comando a seguir para direcionar a Google Cloud CLI ao projeto de política e definir a zona de computação 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 da 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 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 ficar assim:

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

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

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

Para verificar a configuração, envie uma solicitação HTTP com o cabeçalho HOST definido como example-service para um VIP atrá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