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

Visão geral

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 de sidecar do Envoy gerenciado pelo Google adiciona proxies sidecar do Envoy aos seus pods do Google Kubernetes Engine. Quando o injetor de sidecar do Envoy adiciona um proxy, ele também o configura para processar o tráfego de aplicativos e se conectar à Cloud Service Mesh para configuração.

No guia, mostramos uma configuração simples do Cloud Service Mesh com o 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. configuração da Cloud Service Mesh com componentes do Cloud Load Balancing para rotear o tráfego para o 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)
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 as tarefas de pré-requisito descritas em Preparar para configurar APIs de roteamento de serviço com o Envoy e cargas de trabalho sem proxy.

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

Pré-requisitos adicionais com a VPC compartilhada

Se você estiver configurando a 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 à conta de serviço padrão do Compute Engine o papel do IAM de Visualizador da 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.

Configurar as informações do projeto

Se você ainda não criou um projeto do Google Cloud ou instalou a Google Cloud CLI, siga estas instruções. Se você ainda não instalou o kubectl, siga estas instruções.

# The project that contains your GKE cluster.
export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_NUMBER_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 match the channel of your GKE cluster.
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_PROJECT_NUMBER_HERE

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

gcloud config set project ${CLUSTER_PROJECT_ID}

Se você estiver usando as novas APIs de roteamento de serviço, siga as instruções abaixo 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_PROJECT_NUMBER_HERE

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

Na maioria dos casos, CLUSTER_PROJECT_ID e MESH_PROJECT_NUMBER se referem ao mesmo projeto. No entanto, se você configurar o projeto diferente, como ao usar uma VPC compartilhada, o CLUSTER_PROJECT_ID se refere ao ID do projeto que contém o cluster do GKE, e o MESH_PROJECT_NUMBER se refere ao número do projeto que contém os recursos. Verifique se você configurou as permissões adequadas para permitir que o Envoy injetado extraia configurações do

Ativar a API Mesh Config

Ative a API a seguir para começar a usar o injetor de sidecar gerenciado pelo Google.

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

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:

Como criar o cluster do GKE

Crie um cluster do GKE na zona de sua preferência, 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

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

Aplicar as configurações para o webhook mutável

As seções a seguir fornecem instruções para aplicar o MutatingWebhookConfiguration ao cluster. Quando um pod é criado, o controlador de admissão no cluster é invocado. O controlador de admissão se comunica com o injetor de sidecar gerenciado para adicionar o contêiner do Envoy ao pod.

Aplique as seguintes configurações de webhook mutável ao 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

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 td-injection=enabled

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

kubectl get namespace -L td-injection

Isso retornará:

NAME              STATUS   AGE     TD-INJECTION
default           Active   7d16h   enabled

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.

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

Proxy do Cloud Service Mesh

O injetor sidecar gerenciado vai usar a imagem do proxy do Cloud Service Mesh como o proxy. O proxy do Cloud Service Mesh é um contêiner sidecar responsável por iniciar um proxy Envoy para instâncias ativadas pela malha. A imagem do proxy usa a imagem do Envoy do OSS com um agente de proxy responsável por iniciar o Envoy, fornecendo a configuração de inicialização e a verificação de integridade do Envoy. As versões da imagem do proxy do Cloud Service Mesh são alinhadas à versão do Envoy do OSS. É possível acompanhar as imagens de proxy disponíveis aqui: https://gcr.io/gke-release/asm/csm-mesh-proxy

O proxy do Cloud Service Mesh que é injetado varia de acordo com o canal escolhido pelo usuário para o cluster do GKE. A versão do Envoy é atualizada regularmente com base nas versões atuais do Envoy do OSS e é testada com a versão específica do GKE para garantir compatibilidade.

Versão do Cloud Service Mesh Proxy

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

Channel Versão do proxy do Cloud Service Mesh
Rápido 1.29.9-gke.3
Normal 1.28.7-gke.3
Estável 1.27.7-gke.3

Upgrade do proxy do Cloud Service Mesh

É altamente recomendável fazer upgrade para a versão mais recente. Mesmo que a malha de serviço esteja correta com o plano de controle e os proxies em versões diferentes, recomendamos que você atualize os proxies para que eles sejam configurados com a nova versão do Cloud Service Mesh.

O injetor de arquivo secundário gerenciado cuida da versão do Envoy, que sempre injeta a versão mais recente qualificada pelo Google. Se a versão do proxy do Cloud Service Mesh for mais recente que a versão do proxy, reinicie os proxies dos seus serviços.

kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE

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 usando grupos de endpoints de rede (NEGs, na sigla em inglês) para que seja possível configurá-los como back-ends de um serviço de back-end do Cloud Service Mesh. 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.

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

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}')

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:

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 do 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 encaminha o tráfego na malha. 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 de host service-test para back-ends de 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.

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 serviço td-gke-service 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.

Como migrar para o injetor de sidecar gerenciado

Neste tutorial, mostramos como migrar um aplicativo do injetor de arquivo secundário legado do Cloud Service Mesh no GKE (com um injetor de arquivo secundário no cluster) para um que usa um injetor de arquivo secundário gerenciado.

Como desativar a injeção de sidecar no cluster

Os comandos a seguir desativam o injetor de sidecar legado no cluster para o namespace padrão.

kubectl label namespace default istio-injection-

Limpar o injetor do sidecar no cluster

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

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

Excluir recursos do injetor de sidecar no cluster

kubectl delete -f specs/

A seguir