Configurar pods do Google Kubernetes Engine usando injeção automática do Envoy

Visão geral

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

Em uma malha de serviço, o código do aplicativo não precisa saber sobre sua configuração de rede. Em vez disso, seus aplicativos se comunicam por meio de um plano de dados, que é configurado por um plano de controle que gerencia a rede de serviços. Neste guia, o Cloud Service Mesh é seu plano de controle, e os proxies sidecar do Envoy são seu plano de dados.

O injetor do sidecar do Envoy facilita a adição de proxies sidecar do Envoy aos pods do Google Kubernetes Engine. Quando o injetor do sidecar do Envoy adiciona um proxy, ele também configura esse proxy para lidar com o tráfego de aplicativos e se conectar Cloud Service Mesh para configuração.

No guia, você aprende a configurar o Cloud Service Mesh com no Google Kubernetes Engine. Estas etapas representam a base que pode ser estendida a casos de uso avançados, como uma malha de serviço que se estende por vários clusters do Google Kubernetes Engine e, possivelmente, VMs do Compute Engine. Você também pode usar essas instruções se estiver configurando o Cloud Service Mesh com a VPC compartilhada.

O processo de configuração envolve:

1. criação um cluster do GKE para suas cargas de trabalho;
2. instalação do injetor do sidecar do Envoy e ativação da injeção;
3. implantação de um cliente de amostra e verificação da injeção;
4. implantação de um serviço do Kubernetes para testes;
5. Como configurar o Cloud Service Mesh com o Cloud Load Balancing para rotear o tráfego ao serviço de teste.
6. verificação da configuração enviando uma solicitação do cliente de amostra para o serviço de teste.

Visão geral dos componentes implantados como parte deste guia de configuração (clique para ampliar)

Pré-requisitos

Antes de seguir as instruções deste guia, conclua o pré-requisito tarefas descritas em Prepare-se para configurar APIs de roteamento de serviço com cargas de trabalho Envoy e sem proxy.

Para informações sobre a versão do Envoy compatível, consulte as notas da versão do Cloud Service Mesh.

Observação: o injetor do sidecar e o proxy injetado são baseados no injetor do sidecar do Istio. Não instale o injetor do sidecar do Envoy se você já tiver implantado o Istio ao cluster do GKE, porque isso pode causar conflitos de injeção.

Pré-requisitos adicionais com a VPC compartilhada

Se você estiver configurando o Cloud Service Mesh em um ambiente de VPC compartilhada, verifique o seguinte.

• Você tem as permissões e funções corretas para a VPC compartilhada.
• Você configurou os projetos e o faturamento corretos.
• Você ativou o faturamento nos projetos.
• Você ativou as APIs Cloud Service Mesh e GKE em cada projeto, incluindo o projeto host.
• Você configurou as contas de serviço corretas para cada projeto.
• Você criou uma rede e sub-redes VPC.
• Você ativou a VPC compartilhada.

Para mais informações, consulte VPC compartilhada.

Configurar papéis do IAM

Este exemplo de configuração de papel do IAM pressupõe que o projeto host da VPC compartilhada tenha duas sub-redes e que haja dois projetos de serviço na VPC compartilhada.

1. No Cloud Shell, crie uma pasta de trabalho (WORKDIR) em que você cria os arquivos associados a esta seção:

   mkdir -p ~/td-shared-vpc
   cd ~/td-shared-vpc
   export WORKDIR=$(pwd)
   

2. Configure permissões de IAM no projeto de host para que os projetos de serviço possam usar os recursos na VPC compartilhada.

   Nesta etapa, você configura as permissões do IAM para que subnet-1 possa ser acessado pelo projeto de serviço 1 e subnet-2 pelo projeto de serviço 2. Atribua o papel do IAM de usuário da rede do Compute (roles/compute.networkUser) à conta de serviço padrão de computação do Compute Engine e à conta de serviço das APIs do Google Cloud em cada projeto de serviço para cada sub-rede.

   1. Para o projeto de serviço 1, configure as permissões do IAM para subnet-1:

      export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag')
      
      cat > subnet-1-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_1_API_SA}
        - serviceAccount:${SVC_PROJECT_1_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_1_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-1 \
      subnet-1-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_1}
      

   2. Para o projeto de serviço 2, configure as permissões do IAM para subnet-2:

      export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag')
      
      cat > subnet-2-policy.yaml <<EOF
      bindings:
      - members:
        - serviceAccount:${SVC_PROJECT_2_API_SA}
        - serviceAccount:${SVC_PROJECT_2_GKE_SA}
        role: roles/compute.networkUser
      etag: ${SUBNET_2_ETAG}
      EOF
      
      gcloud beta compute networks subnets set-iam-policy subnet-2 \
      subnet-2-policy.yaml \
          --project ${HOST_PROJECT} \
          --region ${REGION_2}
      

3. Para cada projeto de serviço, você precisa conceder o papel do IAM de Usuário do agente de serviço de host do Kubernetes Engine (roles/container.hostServiceAgentUser) à conta de serviço do GKE no projeto host:

   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   
   gcloud projects add-iam-policy-binding ${HOST_PROJECT} \
       --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \
       --role roles/container.hostServiceAgentUser
   

   Com esse papel, a conta de serviço do GKE do projeto de serviço usa a conta de serviço do GKE do projeto host para configurar os recursos de rede compartilhados.

4. Para cada projeto de serviço, conceda à instância de serviço Compute Engine conta o Papel do IAM de Leitor de rede do Compute (roles/compute.networkViewer) no projeto host.

   gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \
       --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \
       --role roles/compute.networkViewer
   
   gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \
       --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \
       --role roles/compute.networkViewer
   

   Quando o proxy sidecar do Envoy se conecta ao serviço xDS (API Traffic Director), o proxy usa a conta de serviço do host da máquina virtual (VM) do Compute Engine ou da instância do nó do GKE. A conta de serviço precisa ter a permissão compute.globalForwardingRules.get do IAM no nível do projeto. O papel de Visualizador de rede do Compute é suficiente para esta etapa.

Como criar um cluster do GKE para suas cargas de trabalho

Os clusters do GKE precisam atender aos seguintes requisitos para oferecer suporte ao Cloud Service Mesh:

• O suporte ao grupo de endpoints da rede precisa estar ativado. Para mais informações e exemplos, consulte Grupos de endpoints de rede autônomos.
• A conta de serviço dos nós/pods do GKE precisa ter permissão para acessar a API Traffic Director. Para mais informações sobre os requisitos de acesso, consulte Ative a conta de serviço para acessar a API Traffic Director.

Como criar o cluster do GKE

Crie um cluster do GKE chamado traffic-director-cluster na zona de sua preferência, por exemplo, us-central1-a.

gcloud container clusters create traffic-director-cluster \
  --zone ZONE \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

Como apontar o kubectl para o cluster recém-criado

Altere o contexto atual de kubectl para o cluster recém-criado emitindo o seguinte comando:

gcloud container clusters get-credentials traffic-director-cluster \
    --zone ZONE

Como instalar o injetor do sidecar do Envoy

Nas seções a seguir, fornecemos instruções para instalar o injetor do sidecar do Envoy. Quando o injetor do sidecar está ativado, ele implanta automaticamente proxies sidecar para cargas de trabalho novas e atuais do Google Kubernetes Engine. Como o injetor do sidecar do Envoy é executado dentro do cluster do GKE, você precisa instalá-lo uma vez em cada cluster se estiver usando o Cloud Service Mesh para oferecer suporte a uma malha de serviço de vários clusters.

Como fazer o download do injetor do sidecar

Faça o download e extraia o injetor do sidecar do Envoy.

wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz
tar -xzvf td-sidecar-injector-xdsv3.tgz
cd td-sidecar-injector-xdsv3

Como configurar o injetor do sidecar

Se você estiver usando APIs mais antigas, configure o injetor do sidecar editando o arquivo specs/01-configmap.yaml para:

• Preencha TRAFFICDIRECTOR_GCP_PROJECT_NUMBER substituindo YOUR_PROJECT_NUMBER_HERE pelo número do projeto. O número do projeto é o identificador numérico dele. Para informações sobre como conseguir uma lista de todos os projetos, consulte Como identificar projetos.
• Preencha TRAFFICDIRECTOR_NETWORK_NAME substituindo YOUR_NETWORK_NAME_HERE pelo nome da rede da nuvem privada virtual do Google Cloud que você quer usar com a Cloud Service Mesh. Anote o nome dessa rede VPC, porque você precisará dele mais tarde ao configurar o Cloud Service Mesh.

Se você estiver usando as novas APIs de roteamento de serviço, que estão em visualização no momento:

• Preencha TRAFFICDIRECTOR_MESH_NAME substituindo "" pelo nome da malha de serviço para conseguir a configuração de uma malha de serviço.
  • Observe que, se você estiver configurando um Gateway, não use o injetor do sidecar. Você implanta um proxy do Envoy como um pod.

Por exemplo, o arquivo pode ser assim:

$ cat specs/01-configmap.yaml

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: istio
    namespace: istio-system
  data:
    mesh: |-
      defaultConfig:
        discoveryAddress: trafficdirector.googleapis.com:443

        # Envoy proxy port to listen on for the admin interface.
        proxyAdminPort: 15000

        proxyMetadata:
          # Google Cloud Project number where Cloud Service Mesh resources are configured.
          # This is a numeric identifier of your project (e.g. "111222333444").
          # You can get a list of all your projects with their corresponding numbers by
          # using "gcloud projects list" command or looking it up under "Project info"
          # section of your Google Cloud console.
          # If left empty, configuration will be attempted to be fetched for the Google Cloud
          # project associated with service credentials.
          # Leaving empty is not recommended as it is not guaranteed to work in future
          # releases.
          TRAFFICDIRECTOR_GCP_PROJECT_NUMBER: "YOUR_PROJECT_NUMBER_HERE"

          # Google Cloud VPC network name for which the configuration is requested (This is the VPC
          # network name referenced in the forwarding rule in Google Cloud API). If left empty,
          # configuration will be attempted to be fetched for the VPC network over which
          # the request to Cloud Service Mesh (trafficdirector.googleapis.com) is sent out.
          # Leaving empty is not recommended as it is not guaranteed to work in future
          # releases.
          TRAFFICDIRECTOR_NETWORK_NAME: "default"

Observação: se você tiver uma configuração de VPC compartilhada, substitua o TRAFFICDIRECTOR_NETWORK_NAME pelo nome da rede configurada no projeto host.

Também é possível ativar a geração de registros e o rastreamento para cada proxy que é injetado automaticamente. Para mais informações sobre essas configurações, consulte Como configurar atributos adicionais para proxies sidecar. Quando você usa o injetor de arquivo secundário, o valor de TRAFFICDIRECTOR_ACCESS_LOG_PATH só pode ser definido como um arquivo no diretório /etc/envoy/. Por exemplo, o diretório /etc/envoy/access.log é um local válido.

TRAFFICDIRECTOR_INTERCEPTION_PORT não pode ser configurado neste ConfigMap, porque ele já está configurado pelo injetor do sidecar.

Como instalar o injetor do sidecar no cluster do GKE

1. Implante o injetor do sidecar.

   kubectl apply -f specs/
   

2. Verifique se o injetor do sidecar está em execução.

   kubectl get pods -A | grep istiod
   

   Com isso, será retornada uma resposta semelhante a esta:

   istio-system   istiod-6b475bfdf9-79965  1/1 Running   0   11s
   

Observação: o injetor e o proxy injetado são baseados nas implementações do Istio, para que os componentes baseados no Istio estejam presentes nos clusters. Você não precisa instalar outros componentes do Istio. Tudo a configuração necessária para o Cloud Service Mesh é capturada neste guia.

Como abrir uma porta em um cluster particular

Se você estiver seguindo as instruções da Como configurar a segurança do serviço do Cloud Service Mesh com o Envoy, pule esta seção e avance para a próxima, Como ativar a injeção do sidecar.

Se você estiver instalando o injetor de arquivo secundário do Envoy em um cluster particular, será necessário abrir a porta TCP 9443 na regra de firewall para os nós mestres para que o webhook funcione corretamente.

As etapas a seguir descrevem como atualizar a regra de firewall. Observe que o update substitui a regra de firewall atual. Portanto, inclua as portas padrão 443 (HTTPS) e 10250 (kubelet) e também a nova porta que você quer abrir.

1. Encontre o intervalo de origem (master-ipv4-cidr) do cluster. No comando a seguir, substitua CLUSTER_NAME pelo nome do seu cluster, ou seja, traffic-director-cluster:

   FIREWALL_RULE_NAME=$(gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master" \
    --format="value(name)")
   

2. Atualize a regra de firewall para abrir a porta TCP 9443 para ativar a injeção automática:

   gcloud compute firewall-rules update ${FIREWALL_RULE_NAME} \
    --allow tcp:10250,tcp:443,tcp:9443
   

Como ativar a injeção do sidecar

O comando a seguir ativa a injeção do namespace default. O injetor do sidecar injeta contêineres de sidecar em pods criados nesse namespace:

kubectl label namespace default istio-injection=enabled

Verifique se o namespace default está ativado corretamente executando o seguinte comando:

kubectl get namespace -L istio-injection

Isso retornará:

NAME              STATUS   AGE     ISTIO-INJECTION
default           Active   7d16h   enabled
istio-system      Active   7d15h

Se você estiver configurando a segurança do serviço para o Cloud Service Mesh com o Envoy, volte para a seção Como configurar um serviço de teste no guia de configuração.

Como implantar um cliente de amostra e verificar a injeção

Nesta seção, mostramos como implantar um pod de amostra que executa o Busybox, que fornece uma interface simples para alcançar um serviço de teste. Em uma implantação real, você implantaria seu próprio aplicativo cliente.

kubectl create -f demo/client_sample.yaml

O pod do Busybox consiste em dois contêineres. O primeiro contêiner é o cliente com base na imagem do Busybox, e o segundo é o proxy Envoy inserido pelo injetor do sidecar. Para mais informações sobre o pod, execute o comando a seguir:

kubectl describe pods -l run=client

Isso retornará:

…
Init Containers:
# Istio-init sets up traffic interception for the pod.
  Istio-init:
…
Containers:
# busybox is the client container that runs application code.
  busybox:
…
# Envoy is the container that runs the injected Envoy proxy.
  envoy:
…

Como implantar um serviço do Kubernetes para testes

Nas seções a seguir, você verá instruções para configurar um serviço de teste que será usado posteriormente neste guia para fornecer uma verificação completa da configuração.

Como configurar serviços do GKE com NEGs

Os serviços do GKE precisam ser expostos por grupos de endpoints de rede (NEGs) para que você possa configurá-los como back-ends de um back-end do Cloud Service Mesh serviço. Adicione a anotação NEG à especificação de serviço do Kubernetes e escolha um nome (substituindo NEG-NAME no exemplo abaixo) para encontrá-lo facilmente depois. O nome será necessário ao anexar o NEG ao serviço de back-end do Cloud Service Mesh. Consulte Como nomear NEGs para mais informações sobre anotações de NEG.

Observação: o pacote trafficdirector_service_sample.yaml fornecido com este guia de configuração usa o nome NEG service-test-neg.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

Essa anotação cria um NEG independente que contém endpoints correspondentes aos endereços IP e às portas dos pods do serviço. Para mais informações e exemplos, consulte Grupos de endpoints de rede autônomos.

Veja no exemplo de serviço a seguir a anotação NEG. O serviço exibe o nome do host por HTTP na porta 80. Use o comando a seguir para receber o serviço e implantá-lo no cluster do GKE.

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

Verifique se o novo serviço foi criado e se o pod do aplicativo está em execução:

kubectl get svc

A resposta será semelhante a:

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

Verifique se o pod de aplicativo associado a este serviço está em execução:

kubectl get pods

Isso retorna:

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       2/2       Running   0          6m
busybox-5dcf86f4c7-jvvdd    2/2       Running   0          10m
[..skip..]

Observação: como o injetor do sidecar está ativado no namespace padrão, os proxies sidecar também são injetados no pod do serviço de teste quando ele é criado. O o injetor do sidecar só configura a interceptação para o tráfego de saída. proxy sidecar do serviço não está envolvido na manipulação do tráfego de entrada do exemplo de cliente.

Como salvar o nome do NEG

Encontre o NEG criado no exemplo acima e registre o nome dele para a configuração da Cloud Service Mesh na próxima seção.

gcloud compute network-endpoint-groups list

Isso retorna o resultado a seguir:

NAME                       LOCATION            ENDPOINT_TYPE       SIZE
service-test-neg           ZONE     GCE_VM_IP_PORT      1

Salve o nome do NEG na variável NEG_NAME:

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

Observação: se você nomeou seu NEG, conforme discutido em Como configurar serviços do GKE com NEGs, o nome do NEG corresponde ao nome que você forneceu na especificação do serviço do Kubernetes. Se você não tiver nomeado o NEG, um nome será gerado automaticamente para você.

Como configurar o Cloud Service Mesh com componentes do Cloud Load Balancing

Nesta seção, você configura o Cloud Service Mesh usando recursos de balanceamento de carga do Compute Engine. Isso permite que o proxy sidecar do cliente de amostra receba a configuração do Cloud Service Mesh. As solicitações de saída do cliente de amostra são processadas pelo proxy secundário e encaminhadas para o serviço de teste.

Você precisa configurar os componentes a seguir:

• Uma verificação de integridade Para mais informações sobre verificações de integridade, leia Conceitos de verificação de integridade e Como criar verificações de integridade.
• Um serviço de back-end Para mais informações sobre serviços de back-end, leia Serviços de back-end.
• Um mapa de regras de roteamento Isso inclui a criação de uma regra de encaminhamento, um proxy HTTP de destino e um mapa de URL. Para mais informações, acesse Como usar regras de encaminhamento para o Cloud Service Mesh, Como usar proxies de destino para o Cloud Service Mesh, e Como usar mapas de URL.

Como criar a verificação de integridade e a regra de firewall

Use as instruções a seguir para criar uma verificação de integridade e a regra de firewall necessária para as sondagens. Para mais informações, consulte Regras de firewall para verificações de integridade.

Console

1. Acesse a página "Verificações de integridade" no Console do Google Cloud.
   Acessar a página "Verificações de integridade"
2. Clique em Criar verificação de integridade.
3. Para o nome, insira td-gke-health-check.
4. Como protocolo, selecione HTTP.

5. Clique em Criar.

6. Acesse a página de políticas de firewall no console do Google Cloud.
   Acessar a página "Políticas de firewall"

7. Clique em Criar regras de firewall.

8. Na página Criar regra de firewall, forneça estas informações:

   • Nome: informe um nome para a regra. Neste exemplo, use fw-allow-health-checks.
   • Rede: escolha uma rede VPC.
   • Prioridade: informe um número para a prioridade. Números mais baixos têm prioridades mais altas. Certifique-se de que a regra de firewall tenha uma prioridade mais alta que outras regras que podem negar o tráfego de entrada.
   • Direção do tráfego: escolha entrada.
   • Ação se houver correspondência: escolha Permitir.
   • Destinos: escolha Todas as instâncias na rede.
   • Filtro de origem: escolha o tipo de intervalo de IP correto.
   • Intervalos de IP de origem: 35.191.0.0/16,130.211.0.0/22
   • Filtro de destino: selecione o tipo de IP.
   • Protocolos e portas: clique em Portas e protocolos especificados e marque tcp. O TCP é o protocolo subjacente a todos os protocolos de verificação de integridade.
   • Clique em Criar.

gcloud

1. Crie a verificação de integridade.

   gcloud compute health-checks create http td-gke-health-check \
     --use-serving-port
   

2. Crie a regra de firewall para permitir os intervalos de endereços IP do verificador de integridade.

   gcloud compute firewall-rules create fw-allow-health-checks \
     --action ALLOW \
     --direction INGRESS \
     --source-ranges 35.191.0.0/16,130.211.0.0/22 \
     --rules tcp
   

Como criar o serviço de back-end

Crie um serviço de back-end global com o esquema de balanceamento de carga INTERNAL_SELF_MANAGED. No Console do Google Cloud, o esquema de balanceamento de carga é definido implicitamente. Adicione a verificação de integridade ao serviço de back-end.

Console

1. Acesse a página "Cloud Service Mesh" no console do Google Cloud.

   Acessar a página do Cloud Service Mesh

2. Na guia Serviços, clique em Criar serviço.

3. Clique em Continuar.

4. Como nome do serviço, insira td-gke-service.

5. Selecione Rede, que você configurou no ConfigMap do Cloud Service Mesh.

6. Em Tipo de back-end, selecione Grupos de endpoints de rede.

7. Selecione o grupo de endpoints de rede que você criou.

8. Defina o RPS máximo como 5.

9. Defina o Modo de balanceamento como Taxa.

10. Clique em Concluído.

11. Em Verificação de integridade, selecione td-gke-health-check, que é a verificação de integridade que você criou.

12. Clique em Continuar.

gcloud

1. Crie o serviço de back-end e associe a verificação de integridade a ele.

   gcloud compute backend-services create td-gke-service \
    --global \
    --health-checks td-gke-health-check \
    --load-balancing-scheme INTERNAL_SELF_MANAGED
   

2. Adicione o NEG criado anteriormente como um back-end ao serviço de back-end. Se você estiver configurando o Cloud Service Mesh com um proxy TCP de destino, use o modo de balanceamento UTILIZATION. Se você estiver usando um proxy de destino HTTP ou HTTPS, poderá usar o modo RATE.

   gcloud compute backend-services add-backend td-gke-service \
    --global \
    --network-endpoint-group ${NEG_NAME} \
    --network-endpoint-group-zone ZONE \
    --balancing-mode [RATE | UTILIZATION] \
    --max-rate-per-endpoint 5
   

Como criar o mapa de regras de roteamento

O mapa de regras de roteamento define como o Cloud Service Mesh roteia o tráfego da rede mesh. Como parte do mapa de regras de roteamento, configure um endereço IP virtual (VIP) e um conjunto de regras de gerenciamento de tráfego associadas, como roteamento baseado em host. Quando um aplicativo envia uma solicitação ao VIP, o proxy sidecar do Envoy anexado faz o seguinte:

1. Intercepta a solicitação.
2. Avalia-a de acordo com as regras de gerenciamento de tráfego no mapa de URL.
3. Seleciona um serviço de back-end com base no nome do host na solicitação.
4. Escolhe um back-end ou endpoint associado ao serviço de back-end selecionado.
5. Envia o tráfego para esse back-end ou endpoint.

Console

No console, o proxy de destino é combinado à regra de encaminhamento. Quando você cria a regra de encaminhamento, o Google Cloud cria automaticamente um proxy HTTP de destino e o anexa ao mapa de URL.

A regra de rota consiste na regra de encaminhamento e nas regras de host e caminho (também conhecida como mapa de URL).

1. Acesse a página do Cloud Service Mesh no console do Google Cloud.

   Acessar a página do Cloud Service Mesh

2. Clique em Mapas de regra de roteamento.

3. Clique em Criar regra de roteamento.

4. Insira td-gke-url-map como o Nome do mapa de URL.

5. Clique em Adicionar regra de encaminhamento.

6. Como nome da regra de encaminhamento, insira td-gke-forwarding-rule.

7. Selecione a rede.

8. Selecione seu IP interno.

9. Clique em Salvar.

10. Opcionalmente, adicione regras de host e de caminho personalizadas ou use as regras padrão.

11. Defina o host como service-test.

12. Clique em Salvar.

gcloud

1. Crie um mapa de URL que use td-gke-service como o serviço de back-end padrão.

   gcloud compute url-maps create td-gke-url-map \
      --default-service td-gke-service
   

2. Crie uma correspondência de caminho do mapa de URL e uma regra de host para rotear o tráfego para o serviço com base no nome do host e em um caminho. Este exemplo usa service-test como o nome do serviço e uma correspondência de caminho padrão que corresponde a todas as solicitações de caminho para esse host (/*).

   gcloud compute url-maps add-path-matcher td-gke-url-map \
      --default-service td-gke-service \
      --path-matcher-name td-gke-path-matcher
   
   gcloud compute url-maps add-host-rule td-gke-url-map \
      --hosts service-test \
      --path-matcher-name td-gke-path-matcher
   

3. Crie o proxy HTTP de destino.

   gcloud compute target-http-proxies create td-gke-proxy \
      --url-map td-gke-url-map
   

4. Crie a regra de encaminhamento.

   gcloud compute forwarding-rules create td-gke-forwarding-rule \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --address=0.0.0.0 \
     --target-http-proxy=td-gke-proxy \
     --ports 80 --network default
   

Neste ponto, o Cloud Service Mesh configura seus proxies sidecar para rotear solicitações que especificam o nome do host service-test para back-ends do td-gke-service. Nesse caso, esses back-ends são endpoints no grupo de endpoints da rede associado ao serviço de teste do Kubernetes implantado anteriormente.

Observação: como você configurou um serviço padrão (td-gke-service) para o mapa de URL, qualquer solicitação de saída processada por um proxy sidecar será encaminhada para os back-ends associados a esse serviço padrão.

Como verificar a configuração

Nesta seção, veja como verificar se o tráfego enviado do cliente de amostra do Busybox é roteado para seu serviço do Kubernetes service-test. Para enviar uma solicitação de teste, acesse um shell em um dos contêineres e execute o comando de verificação a seguir. Um pod service-test retorna o nome do host do pod de serviço.

# Get the name of the pod running Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test at
# the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this
# can be any VIP.
TEST_CMD="wget -q -O - 10.0.0.1; echo"

# Execute the test command on the pod.
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Veja como a configuração é verificada:

• O cliente de amostra enviou uma solicitação que especificou o nome do host service-test.
• O cliente de amostra tem um proxy sidecar do Envoy que foi injetado pelo injetor do sidecar do Envoy.
• O proxy secundário interceptou a solicitação.
• Usando o mapa de URL, o Envoy correspondeu o nome do host service-test ao td-gke-service serviço do Cloud Service Mesh.
• O Envoy escolheu um endpoint do grupo de endpoints de rede associado a td-gke-service.
• O Envoy enviou a solicitação para um pod associado ao serviço service-test do Kubernetes.

A seguir

• Saiba mais sobre o gerenciamento avançado de tráfego
• Saiba mais sobre a segurança de serviços do Cloud Service Mesh.
• Saiba como configurar a observabilidade com o Envoy.
• Saiba como resolver problemas de implantações do Cloud Service Mesh.
• Saiba mais sobre as opções de configuração de pod do Google Kubernetes Engine com injeção automática do Envoy.