Configure pods do Google Kubernetes Engine através da injeção automática do Envoy

Vista geral

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.

Numa malha de serviços, o código da sua aplicação não precisa de saber acerca da sua configuração de rede. Em alternativa, as suas aplicações comunicam através de um plano de dados, que é configurado por um plano de controlo que processa a rede de serviços. Neste guia, a Cloud Service Mesh é o seu plano de controlo e os proxies sidecar do Envoy são o seu plano de dados.

O injetor de sidecar do Envoy gerido pela Google adiciona proxies de sidecar do Envoy aos seus pods do Google Kubernetes Engine. Quando o injetor do sidecar do Envoy adiciona um proxy, também configura esse proxy para processar o tráfego da aplicação e estabelecer ligação ao Cloud Service Mesh para configuração.

O guia explica uma configuração simples da Cloud Service Mesh com o Google Kubernetes Engine. Estes passos fornecem a base que pode expandir para casos de utilização avançados, como uma malha de serviços que se estende por vários clusters do Google Kubernetes Engine e, potencialmente, VMs do Compute Engine. Também pode usar estas instruções se estiver a configurar a Cloud Service Mesh com a VPC partilhada.

O processo de configuração envolve:

1. Criar um cluster do GKE para as suas cargas de trabalho.
2. Instalar o injetor de sidecar do Envoy e ativar a injeção.
3. Implementar um cliente de exemplo e validar a injeção.
4. Implementar um serviço Kubernetes para testes.
5. Configurar a Cloud Service Mesh com componentes do Cloud Load Balancing para encaminhar o tráfego para o serviço de teste.
6. Validar a configuração enviando um pedido do cliente de exemplo para o serviço de teste.

Vista geral dos componentes implementados como parte deste guia de configuração (clique para aumentar)

Pré-requisitos

Antes de seguir as instruções neste guia, conclua as tarefas de pré-requisitos descritas no artigo Prepare-se para configurar APIs de encaminhamento de serviços com o Envoy e cargas de trabalho sem proxy.

Para obter informações sobre a versão do Envoy suportada, consulte as notas de lançamento do Cloud Service Mesh.

Nota: o injetor de sidecar e o proxy injetado baseiam-se no injetor de sidecar do Istio. Não instale o injetor sidecar do Envoy se já tiver implementado o Istio no cluster do GKE, uma vez que isto pode causar conflitos no comportamento de injeção.

Pré-requisitos adicionais com a VPC partilhada

Se estiver a configurar o Cloud Service Mesh num ambiente de VPC partilhada, certifique-se do seguinte.

• Tem as autorizações e as funções corretas para a VPC partilhada.
• Configurou os projetos e a faturação corretos.
• Ativou a faturação nos projetos.
• Ativou as APIs Cloud Service Mesh e GKE em cada projeto, incluindo o projeto anfitrião.
• Configurou as contas de serviço corretas para cada projeto.
• Criou uma rede de VPC e sub-redes.
• Ativou a VPC partilhada.

Para mais informações, consulte o artigo VPC partilhada.

Configure funções de IAM

Este exemplo de configuração de funções da IAM pressupõe que o projeto anfitrião da VPC partilhada tem duas sub-redes e que existem dois projetos de serviço na VPC partilhada.

1. No Cloud Shell, crie uma pasta de trabalho (WORKDIR)) onde cria os ficheiros associados a esta secção:

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

2. Configure as autorizações da IAM no projeto anfitrião para que os projetos de serviço possam usar os recursos na VPC partilhada.

   Neste passo, configura as autorizações de IAM para que o subnet-1 seja acessível pelo projeto de serviço 1 e o subnet-2 seja acessível pelo projeto de serviço 2. Atribui a função do IAM de utilizador da rede de computação (roles/compute.networkUser) à conta de serviço predefinida do Compute Engine e à conta de serviço da API em cada projeto de serviço para cada sub-rede. Google Cloud

   1. Para o projeto de serviço 1, configure as autorizações IAM para o 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 autorizações 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, tem de conceder a função de IAM de utilizador do agente de serviço anfitrião do Kubernetes Engine (roles/container.hostServiceAgentUser) à conta de serviço do GKE no projeto anfitrião:

   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
   

   Esta função permite que a conta de serviço do GKE do projeto de serviço use a conta de serviço do GKE do projeto anfitrião para configurar recursos de rede partilhados.

4. Para cada projeto de serviço, conceda à conta de serviço predefinida do Compute Engine a função de IAM de visualizador de rede de computação (roles/compute.networkViewer) no projeto anfitrião.

   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 liga ao serviço xDS (API Traffic Director), o proxy usa a conta de serviço da máquina virtual (VM) do Compute Engine ou da instância do nó do GKE. A conta de serviço tem de ter a autorização de IAM ao nível do projeto.compute.globalForwardingRules.get A função de leitor da rede de computação é suficiente para este passo.

Configure as informações do projeto

Se ainda não criou o Google Cloud projeto nem instalou a CLI Google Cloud, siga estas instruções. Se ainda não instalou o kubectl, siga estas instruções.

# The project that contains your GKE cluster.
export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_ID_HERE
# The name of your GKE cluster.
export CLUSTER=YOUR_CLUSTER_NAME
# The channel of your GKE cluster. Eg: rapid, regular, stable. This channel
# should correspond to the channel for your GKE cluster. If your GKE cluster
# does not have a specified channel, please use unspecified in this field.
export CHANNEL=YOUR_CLUSTER_CHANNEL
# The location of your GKE cluster, Eg: us-central1 for regional GKE cluster,
# us-central1-a for zonal GKE cluster
export LOCATION=ZONE

# The network name of the traffic director load balancing API.
export MESH_NAME=default
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_MESH_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/global/networks/${MESH_NAME}

gcloud config set project ${CLUSTER_PROJECT_ID}

Se estiver a usar as novas APIs de encaminhamento de serviços, para o recurso de malha, use as seguintes instruções para definir MESH_NAME, MESH_PROJECT_NUMBER e TARGET:

# The mesh name of the traffic director load balancing API.
export MESH_NAME=YOUR_MESH_NAME
# The project that holds the mesh resources.
export MESH_PROJECT_NUMBER=YOUR_MESH_PROJECT_NUMBER_HERE

export TARGET=projects/${MESH_PROJECT_NUMBER}/locations/global/meshes/${MESH_NAME}

Para o recurso de gateway, use as seguintes instruções para definir SCOPE_NAME, SCOPE_PROJECT_NUMBER e TARGET:

# The gateway scope name of the traffic director load balancing API.
export SCOPE_NAME=YOUR_SCOPE_NAME
# The project that holds the gateway resources.
export SCOPE_PROJECT_NUMBER=YOUR_GATEWAY_PROJECT_NUMBER_HERE

export TARGET=projects/${SCOPE_PROJECT_NUMBER}/locations/global/gatewayScopes/${SCOPE_NAME}

Na maioria dos cenários, CLUSTER_PROJECT_ID e MESH_PROJECT_NUMBER referem-se ao mesmo projeto. No entanto, se configurar o projeto diferente, como quando usa uma VPC partilhada, o CLUSTER_PROJECT_ID refere-se ao ID do projeto que contém o cluster do GKE e o MESH_PROJECT_NUMBER refere-se ao número do projeto que contém os recursos do Google Cloud. Certifique-se de que configurou as autorizações adequadas para permitir que o Envoy injetado obtenha configurações do

Ative a API Mesh Config

Ative a seguinte API para começar a usar o injetor de sidecar gerido pela Google.

gcloud services enable --project=${CLUSTER_PROJECT_ID} meshconfig.googleapis.com

Criar um cluster do GKE para as suas cargas de trabalho

Os clusters do GKE têm de cumprir os seguintes requisitos para suportar o Cloud Service Mesh:

• O suporte de grupos de pontos finais de rede tem de estar ativado. Para mais informações e exemplos, consulte o artigo Grupos de pontos finais de rede autónomos.
• A conta de serviço dos seus nós/pods do GKE tem de ter autorização para aceder à API Traffic Director. Para mais informações acerca das autorizações necessárias, consulte o artigo Ative a conta de serviço para aceder à API Traffic Director.

Criar o cluster do GKE

Crie um cluster do GKE na sua zona preferida, por exemplo, us-central1-a.

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

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

Aplique as configurações para o webhook de mutação

As secções seguintes fornecem instruções para aplicar a MutatingWebhookConfiguration ao cluster. Quando um pod é criado, o controlador de admissão no cluster é invocado. O controlador de admissão comunica com o injetor de sidecar gerido para adicionar o contentor Envoy ao pod.

Aplique as seguintes configurações de webhook de mutação ao seu cluster.

cat <<EOF | kubectl apply -f -
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app: sidecar-injector
  name: td-mutating-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  - v1
  clientConfig:
    url: https://meshconfig.googleapis.com/v1internal/projects/${CLUSTER_PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER}/channels/${CHANNEL}/targets/${TARGET}:tdInject
  failurePolicy: Fail
  matchPolicy: Exact
  name: namespace.sidecar-injector.csm.io
  namespaceSelector:
    matchExpressions:
    - key: td-injection
      operator: Exists
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 30
EOF

Ativar a injeção de sidecar

O seguinte comando ativa a injeção para o espaço de nomes default. O injetor de sidecar injeta contentores sidecar em pods criados neste espaço de nomes:

kubectl label namespace default td-injection=enabled

Pode verificar se o espaço de nomes default está corretamente ativado executando o seguinte comando:

kubectl get namespace -L td-injection

Isto deve devolver:

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

Se estiver a configurar a segurança do serviço para a malha de serviços na nuvem com o Envoy, regresse à secção Configurar um serviço de teste nesse guia de configuração.

Implementar um cliente de exemplo e validar a injeção

Esta secção mostra como implementar um pod de exemplo que executa o Busybox, que fornece uma interface simples para alcançar um serviço de teste. Numa implementação real, implementaria a sua própria aplicação cliente.

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: client
  name: busybox
spec:
  replicas: 1
  selector:
    matchLabels:
      run: client
  template:
    metadata:
      labels:
        run: client
    spec:
      containers:
      - name: busybox
        image: busybox
        command:
        - sh
        - -c
        - while true; do sleep 1; done
EOF

O pod Busybox é composto por dois contentores. O primeiro contentor é o cliente com base na imagem do Busybox e o segundo contentor é o proxy do Envoy injetado pelo injetor de sidecar. Pode obter mais informações sobre o pod executando o seguinte comando:

kubectl describe pods -l run=client

Isto deve devolver:

…
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:
…

Proxy do Cloud Service Mesh

O injetor de sidecar gerido usa a imagem do proxy do Cloud Service Mesh como proxy. O proxy do Cloud Service Mesh é um contentor sidecar responsável por iniciar um proxy do Envoy para instâncias ativadas para a malha. A imagem do proxy usa a imagem do OSS Envoy juntamente com um agente de proxy responsável por iniciar o Envoy, fornecer a configuração de arranque e verificar o estado do Envoy. As versões da imagem do proxy do Cloud Service Mesh estão alinhadas com a versão do OSS Envoy. Pode acompanhar as imagens de proxy disponíveis aqui: https://gcr.io/gke-release/asm/csm-mesh-proxy

O proxy de malha do Cloud Service Mesh que é injetado varia consoante o canal que o utilizador escolheu para o cluster do GKE. A versão do Envoy é atualizada regularmente com base nas versões atuais do OSS Envoy e é testada com a versão específica do GKE para garantir a compatibilidade.

Versão do proxy do Cloud Service Mesh

A tabela seguinte mostra o mapeamento atual do canal do cluster do GKE para a versão do proxy do Cloud Service Mesh:

Canal	Versão do proxy do Cloud Service Mesh
Inovação	1.31.5-gke.1
Normal	1.30.9-gke.1
Estável	1.29.12-gke.1

Atualização do proxy do Cloud Service Mesh

Recomendamos vivamente que faça a atualização para a versão mais recente. Embora a malha de serviço funcione bem quando o plano de controlo e os proxies estão em versões diferentes, recomendamos que atualize os proxies para que sejam configurados com a nova versão do Cloud Service Mesh.

O injetor de sidecar gerido cuida da versão do Envoy, que injeta sempre a versão mais recente do Envoy qualificada pela Google. Se a versão do proxy do Cloud Service Mesh for mais recente do que a versão do proxy, reinicie os proxies dos seus serviços.

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

Implementar um serviço Kubernetes para testes

As secções seguintes fornecem instruções para configurar um serviço de teste que vai usar mais tarde neste guia para fornecer a validação integral da sua configuração.

Configurar serviços do GKE com NEGs

Os serviços do GKE têm de ser expostos através de grupos de pontos finais de rede (NEGs) para que os possa configurar como back-ends de um serviço de back-end do Cloud Service Mesh. Adicione a anotação NEG à especificação do serviço Kubernetes e escolha um nome (substituindo NEG-NAME no exemplo abaixo) para que o possa encontrar facilmente mais tarde. Precisa do nome quando associa o NEG ao serviço de back-end do Cloud Service Mesh. Para mais informações sobre a anotação de NEGs, consulte o artigo Atribuir nomes a NEGs.

Nota: o pacote trafficdirector_service_sample.yaml fornecido com este guia de configuração usa o nome do 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

Esta anotação cria um NEG autónomo que contém pontos finais correspondentes aos endereços IP e às portas dos pods do serviço. Para mais informações e exemplos, consulte o artigo Grupos de pontos finais de rede autónomos.

O serviço de exemplo seguinte inclui a anotação NEG. O serviço publica o nome do anfitrião através de HTTP na porta 80. Use o seguinte comando para obter o serviço e implementá-lo no seu 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 da aplicação está em execução:

kubectl get svc

O resultado deve ser semelhante ao seguinte:

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 aplicação associado a este serviço está em execução:

kubectl get pods

Esta função devolve:

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

Nota: uma vez que o injetor de sidecar está ativado no espaço de nomes predefinido, os proxies sidecar também são injetados no pod de serviço de teste quando é criado. O injetor de sidecar só configura a interceção para o tráfego de saída, pelo que o proxy sidecar do serviço de teste não está envolvido no processamento do tráfego de entrada do cliente de exemplo.

Guardar o nome do NEG

Encontre o NEG criado a partir do exemplo acima e registe o respetivo nome para a configuração da Cloud Service Mesh na secção seguinte.

gcloud compute network-endpoint-groups list

Esta função devolve o seguinte:

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

Guardar o nome do GNE na variável NEG_NAME:

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

Nota: se tiver dado um nome ao NEG, conforme abordado no artigo Configurar serviços do GKE com NEGs deve ver que o nome do NEG corresponde ao que indicou na especificação do serviço do Kubernetes. Se não atribuiu um nome ao seu NEG, é gerado automaticamente um nome para si.

Configurar o Cloud Service Mesh com componentes do Cloud Load Balancing

Esta secção configura a Cloud Service Mesh através de recursos de balanceamento de carga do Compute Engine. Isto permite que o proxy sidecar do cliente de exemplo receba a configuração da malha de serviços na nuvem. Os pedidos de saída do cliente de exemplo são processados pelo proxy sidecar e encaminhados para o serviço de teste.

Tem de configurar os seguintes componentes:

• Uma verificação de funcionamento. Para mais informações sobre as verificações de funcionamento, leia os artigos Conceitos de verificação de funcionamento e Criar verificações de funcionamento.
• Um serviço de back-end. Para mais informações sobre os serviços de back-end, leia o artigo Serviços de back-end.
• Um mapa de regras de encaminhamento. Isto inclui a criação de uma regra de encaminhamento, um proxy HTTP de destino e um mapa de URLs. Para mais informações, leia os artigos Usar regras de encaminhamento para o Cloud Service Mesh, Usar proxies de destino para o Cloud Service Mesh e Usar mapas de URLs.

Criar a verificação de funcionamento e a regra de firewall

Use as instruções seguintes para criar uma verificação de funcionamento e a regra da firewall necessária para as sondas de verificação de funcionamento. Para mais informações, consulte o artigo Regras da firewall para verificações de funcionamento.

Consola

1. Aceda à página Verificações de saúde na Google Cloud consola.
   Aceda à página Verificações de saúde
2. Clique em Criar verificação de estado.
3. Para o nome, introduza td-gke-health-check.
4. Para o protocolo, selecione HTTP.

5. Clique em Criar.

6. Aceda à página Políticas de firewall na Google Cloud consola.
   Aceda à página Políticas de firewall

7. Clique em Criar regras de firewall.

8. Na página Crie uma regra de firewall, faculte as seguintes informações:

   • Nome: indique um nome para a regra. Para este exemplo, use fw-allow-health-checks.
   • Rede: escolha uma rede de VPC.
   • Prioridade: introduza um número para a prioridade. Os números mais baixos têm prioridades mais elevadas. Certifique-se de que a regra de firewall tem uma prioridade superior à de outras regras que possam negar o tráfego de entrada.
   • Direção do tráfego: escolha Entrada.
   • Ação em caso de correspondência: escolha Permitir.
   • Alvos: 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, de seguida, selecione tcp. O TCP é o protocolo subjacente para todos os protocolos de verificação de funcionamento.
   • Clique em Criar.

gcloud

1. Crie a verificação de funcionamento.

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

   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
   

Criar o serviço de back-end

Crie um serviço de back-end global com um esquema de balanceamento de carga de INTERNAL_SELF_MANAGED. Na Google Cloud consola, o esquema de balanceamento de carga é definido implicitamente. Adicione a verificação de funcionamento ao serviço de back-end.

Consola

1. Aceda à página Cloud Service Mesh na Google Cloud consola.

   Aceda à página Cloud Service Mesh

2. No separador Serviços, clique em Criar serviço.

3. Clique em Continuar.

4. Para o nome do serviço, introduza td-gke-service.

5. Selecione Rede, que configurou no ConfigMap da malha de serviços na nuvem.

6. Em Tipo de back-end, selecione Grupos de pontos finais da rede.

7. Selecione o grupo de pontos finais de rede que criou.

8. Defina o RPS máximo como 5.

9. Defina o Modo de equilíbrio como Taxa.

10. Clique em Concluído.

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

12. Clique em Continuar.

gcloud

1. Crie o serviço de back-end e associe a verificação de funcionamento ao serviço de back-end.

   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 back-end ao serviço de back-end. Se estiver a configurar a Cloud Service Mesh com um proxy TCP de destino, tem de usar o modo de equilíbrio de carga UTILIZATION. Se estiver a usar um proxy de destino HTTP ou HTTPS, pode 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
   

Criar o mapa de regras de encaminhamento

O mapa de regras de encaminhamento define como o Cloud Service Mesh encaminha o tráfego na sua malha. Como parte do mapa de regras de encaminhamento, configura um endereço IP virtual (VIP) e um conjunto de regras de gestão de tráfego associadas, como o encaminhamento baseado no anfitrião. Quando uma aplicação envia um pedido para o VIP, o proxy sidecar do Envoy anexado faz o seguinte:

1. Interceta o pedido.
2. Avalia-o de acordo com as regras de gestão de tráfego no mapa de URLs.
3. Seleciona um serviço de back-end com base no nome do anfitrião no pedido.
4. Escolhe um back-end ou um ponto final associado ao serviço de back-end selecionado.
5. Envia tráfego para esse back-end ou ponto final.

Consola

Na consola, o proxy de destino é combinado com a regra de encaminhamento. Quando cria a regra de encaminhamento, Google Cloud cria automaticamente um proxy HTTP de destino e anexa-o ao mapa de URLs.

A regra de encaminhamento consiste na regra de encaminhamento e nas regras de anfitrião e caminho (também conhecidas como o mapa de URLs).

1. Aceda à página Cloud Service Mesh na Google Cloud consola.

   Aceda à página Cloud Service Mesh

2. Clique em Mapas de regras de encaminhamento

3. Clique em Criar regra de encaminhamento.

4. Introduza td-gke-url-map como o Nome do mapa de URLs.

5. Clique em Adicionar regra de encaminhamento.

6. Para o nome da regra de encaminhamento, introduza td-gke-forwarding-rule.

7. Selecione a rede.

8. Selecione o seu IP interno.

9. Clique em Guardar.

10. Opcionalmente, adicione regras de caminhos e anfitriões personalizadas ou deixe as regras de caminhos como as predefinições.

11. Definir o anfitrião como service-test.

12. Clique em Guardar.

gcloud

1. Crie um mapa de URLs que use td-gke-service como o serviço de back-end predefinido.

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

2. Crie um correspondente de caminho do mapa de URL e uma regra de anfitrião para encaminhar o tráfego para o seu serviço com base no nome do anfitrião e num caminho. Este exemplo usa service-test como o nome do serviço e um matcher de caminho predefinido que corresponde a todos os pedidos de caminho para este anfitrião (/*).

   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 os proxies sidecar para encaminhar pedidos que especifiquem o nome do anfitrião service-test para back-ends de td-gke-service. Neste caso, esses back-ends são pontos finais no grupo de pontos finais da rede associado ao serviço de teste do Kubernetes que implementou anteriormente.

Nota: uma vez que configurou um serviço predefinido (td-gke-service) para o mapa de URLs, qualquer pedido de saída processado por um proxy sidecar é encaminhado para os back-ends associados a este serviço predefinido.

Validar a configuração

Esta secção mostra como verificar se o tráfego enviado do cliente Busybox de exemplo é encaminhado para o seu serviço service-test Kubernetes. Para enviar um pedido de teste, pode aceder a uma shell num dos contentores e executar o seguinte comando de validação. Um service-testagrupamento deve devolver o nome do anfitrião do agrupamento de publicaçã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 é validada:

• O cliente de exemplo enviou um pedido que especificou o nome do anfitrião service-test.
• O cliente de exemplo tem um proxy sidecar do Envoy que foi injetado pelo injetor sidecar do Envoy.
• O proxy sidecar intercetou o pedido.
• Através do mapa de URL, o Envoy fez a correspondência do nome de anfitrião service-test com o serviço do Cloud Service Mesh td-gke-service.
• O Envoy escolheu um ponto final do grupo de pontos finais da rede associado a td-gke-service.
• O Envoy enviou o pedido para um pod associado ao serviço do Kubernetes.service-test

Como migrar para o Managed Sidecar Injector

Este tutorial explica como migrar uma aplicação do injetor de sidecar do Cloud Service Mesh antigo no GKE (com um injetor de sidecar no cluster) para um que use um injetor de sidecar gerido.

Desativar a injeção de sidecar no cluster

Os seguintes comandos desativam o injetor de sidecar no cluster antigo para o espaço de nomes predefinido

kubectl label namespace default istio-injection-

Injetor de sidecar no cluster de limpeza

Transfira e extraia o injetor de sidecar do Envoy antigo.

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

Elimine recursos do injetor de sidecar no cluster

kubectl delete -f specs/

O que se segue?

• Saiba mais sobre a gestão avançada de tráfego
• Saiba mais sobre a segurança do serviço Cloud Service Mesh.
• Saiba como configurar a observabilidade com o Envoy.
• Saiba como resolver problemas de implementações da malha de serviços na nuvem.
• Saiba mais sobre as opções de configuração de pods do Google Kubernetes Engine com injeção automática do Envoy.