Configuração do Traffic Director para pods do Google Kubernetes Engine com injeção manual de Envoy

Neste guia, mostramos como configurar os hosts de pod do Google Kubernetes Engine ou do Kubernetes e os componentes de balanceamento de carga exigidos pelo Traffic Director.

Antes de seguir as instruções deste guia, leia Como se preparar para a configuração do Traffic Director e verifique se você concluiu os pré-requisitos.

É possível configurar o Traffic Director usando o SDK de balanceamento de carga do Compute Engine ou as APIs REST. Consulte as referências da API de balanceamento de carga e do gcloud.

Como configurar clusters do GKE/Kubernetes para o Traffic Director

Nesta seção, você vê as etapas necessárias para permitir que os clusters do GKE/Kubernetes funcionem com o Traffic Director.

Como criar o cluster do GKE

Os clusters do GKE precisam atender aos seguintes requisitos:

No exemplo a seguir, veja como criar um cluster do GKE chamado traffic-director-cluster na zona us-central1-a.

Console

Para criar um cluster usando o Console do Cloud, siga estas etapas:

  1. Acesse o menu do Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Clique em Criar cluster.

  3. Preencha os seguintes campos:

    • Nome: insira traffic-director-cluster.
    • Tipo de local: Zonal.
    • Zona: us-central1-a.
  4. No painel de navegação, em Pools de nós, clique em default-pool.

  5. O campo Tamanho indica o número de nós a serem criados no cluster. É preciso ter uma cota de recursos disponível para os nós e os respectivos recursos, como rotas de firewall.

  6. No painel de navegação, em default-pool, clique em Nós.

  7. O campo Tipo de máquina indica o tipo de máquina do Compute Engine a ser usado nas instâncias. O faturamento varia de acordo com cada tipo de máquina. Para informações sobre preços de tipos de máquina, consulte a página de preços do Compute Engine.

  8. No painel de navegação, em default-pool, clique em Segurança.

  9. Em Escopos de acesso, clique em Permitir acesso total a todas as APIs do Cloud.

  10. Personalize seu cluster conforme necessário.

  11. Clique em Criar.

Depois de criar um cluster no Console do Cloud, você precisa configurar kubectl para interagir com o cluster. Para saber mais, consulte Como gerar uma entrada kubeconfig.

gcloud

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

Como conseguir os privilégios de cluster necessários do GKE

Para o GKE, mude para o cluster(2) recém-criado emitindo o comando a seguir. Isso aponta o kubectl para o cluster correto.

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

Como configurar os serviços do GKE/Kubernetes

Nesta seção, você vê como preparar as especificações de implantação do Kubernetes para que funcionem com o Traffic Director. Isso consiste em configurar serviços com NEGs, bem como injetar proxies sidecar em pods que exigem acesso aos serviços gerenciados pelo Traffic Director.

Configurar regras de firewall

Para verificar se os pods de back-end estão em execução, configure uma regra de firewall que permita os intervalos de endereços IP do verificador de integridade.

Console

  1. Acesse a página "Firewall" no Console do Google Cloud.
    Acessar a página "Firewall"
  2. Clique em Criar regra de firewall.
  3. Na página Criar uma 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 Intervalos de IP.
    • Intervalos de IP de origem: 35.191.0.0/16,130.211.0.0/22.
    • Portas e protocolos permitidos: use tcp. O TCP é o protocolo subjacente a todos os protocolos de verificação de integridade.
    • Clique em Criar.

gcloud

  1. Use o comando gcloud a seguir para criar uma regra de firewall chamada fw-allow-health-checks que permita conexões de entrada com instâncias na sua rede com a tag allow-health-checks. Substitua NETWORK_NAME pelo nome da sua rede.

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

Para mais informações, consulte Configurar a regra firewal para verificações de integridade.

Como configurar os serviços do GKE/Kubernetes com NEGs

A primeira etapa na configuração dos serviços do GKE/Kubernetes com NEGs é a exposição dos serviços que precisam ser gerenciados pelo Traffic Director. Para ser exposta por meio de NEGs, cada especificação precisa ter a seguinte anotação, correspondente à porta que você quer expor.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"80":{}}}'

Para cada serviço, um NEG autônomo é criado. Ele contém endpoints que são as portas e os endereços IP do pod. Para mais informações e exemplos, consulte Grupos de endpoints de rede autônomos.

Para fins de demonstração, é possível implantar um serviço de amostra que veicule o nome de host dele por HTTP na porta 80:

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

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

kubectl get svc

Isso retorna:

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

kubectl get pods

Isso retorna:

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       1/1       Running   0          6m
[..skip..]

Como registar o nome do NEG

Encontre o NEG criado no exemplo acima e registre o nome dele.

Console

Veja uma lista de grupos de endpoints de rede na página "Grupos de endpoints de rede" no Console do Google Cloud.
Acessar a página "Grupos de endpoints de rede"

gcloud

gcloud beta compute network-endpoint-groups list

Isso retorna:

NAME                                           LOCATION       ENDPOINT_TYPE   SIZE
k8s1-7e91271e-default-service-test-80-a652810c  us-central1-a  GCE_VM_IP_PORT  1

Salve o nome do NEG na variável NEG_NAME. Por exemplo:

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

Como configurar componentes de balanceamento de carga do Google Cloud para o Traffic Director

As instruções nesta seção garantem que os serviços do GKE sejam acessíveis no VIP do serviço com balanceamento de carga feito pelo Traffic Director, usando uma configuração de balanceamento de carga semelhante a outros produtos do Google Cloud Load Balancing.

Você precisa configurar os componentes a seguir:

O exemplo de configuração do Traffic Director a seguir presume que:

  1. Os NEGs e todos os outros recursos são criados na rede default, com o modo automático, na zona us-central1-a.
  2. O nome do NEG no cluster precisa ser armazenado na variável ${NEG_NAME}.

Como criar a verificação de integridade

Crie a verificação 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.

gcloud

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

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 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 Traffic Director no Console do Cloud.

    Acessar a página do Traffic Director

  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. Em Tipo de back-end, selecione Grupos de endpoints de rede.

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

  7. Defina o RPS máximo como 5.

  8. Clique em Concluído.

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

  10. 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 os NEGs de back-end ao serviço de back-end.

    gcloud compute backend-services add-backend td-gke-service \
     --global \
     --network-endpoint-group ${NEG_NAME} \
     --network-endpoint-group-zone us-central1-a \
     --balancing-mode RATE \
     --max-rate-per-endpoint 5
    

Como criar o mapa de regras de roteamento

Use estas instruções para criar a regra de rota, a regra de encaminhamento e o endereço IP interno da configuração do Traffic Director.

O tráfego enviado para o endereço IP interno é interceptado pelo proxy do Envoy e encaminhado ao serviço apropriado de acordo com as regras de caminho e host.

A regra de encaminhamento é criada como uma regra de encaminhamento global com load-balancing-scheme definido como INTERNAL_SELF_MANAGED.

É possível definir o endereço da regra de encaminhamento como 0.0.0.0. Se você fizer isso, o tráfego será roteado com base nas informações de caminho e nome do host HTTP configuradas no mapa de URL, independentemente do endereço IP real ao qual o nome do host é resolvido. Nesse caso, os URLs (nome do host mais o caminho do URL) dos serviços, conforme configurados nas regras de host, precisam ser exclusivos na configuração da malha de serviço. Ou seja, não é possível ter dois serviços diferentes, com diferentes conjuntos de back-ends, que usam a mesma combinação de nome de host e caminho.

Como alternativa, é possível ativar o roteamento com base no VIP real do serviço. Se você configurar o VIP do serviço como um parâmetro address da regra de encaminhamento, somente as solicitações destinadas a esse endereço IP serão roteadas com base nos parâmetros HTTP especificados no mapa de URL.

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 Traffic Director no Console do Cloud.

    Acessar a página do Traffic Director

  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 o serviço de back-end.

    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 (/*). service-test também é o nome configurado do serviço do Kubernetes usado na configuração de amostra acima.

    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 Traffic Director está configurado para balancear a carga do tráfego dos serviços especificados no mapa de URL nos back-ends no grupo de endpoints da rede.

Dependendo de como os microsserviços são distribuídos na sua rede, talvez seja necessário adicionar mais regras de encaminhamento ou mais regras de host e caminho ao mapa de URL.

Como verificar a configuração implantando um cliente de amostra para testes

Nesta seção, mostramos como alcançar back-ends do Traffic Director a partir de um aplicativo cliente.

Para testar a funcionalidade, implante um pod de amostra executando o Busybox. O pod tem acesso a service-test, que foi criado na seção anterior e recebe tráfego com balanceamento de carga do Traffic Director.

Como inserir um proxy sidecar nos pods do GKE/Kubernetes

Para acessar um serviço gerenciado pelo Traffic Director, um pod precisa ter um proxy sidecar compatível com a API xDS.

Neste exemplo, você implanta um cliente Busybox com um proxy sidecar do Istio e contêineres init adicionados à implantação usando a especificação de referência:

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

O pod do Busybox tem dois contêineres em execução. O primeiro contêiner é o cliente com base na imagem do Busybox, e o segundo é o proxy do Envoy injetado como um sidecar. Para mais informações sobre o pod, execute o comando a seguir:

kubectl describe pods -l run=client

Como alcançar o serviço de back-end

Depois de serem configurados, os aplicativos nos pods com um proxy secundário inserido podem acessar os serviços gerenciados pelos serviços do Traffic Director. Para verificar a configuração, acesse um shell em um dos contêineres.

Se você usou a configuração de demonstração fornecida neste guia, execute o seguinte comando de verificação para garantir que o nome do host do pod de serviço seja retornado.

# Get name of the pod with 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.
TEST_CMD="wget -q -O - service-test; echo"

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

Como entender a interceptação de tráfego pelo proxy sidecar

Neste exemplo, quando o cliente do Busybox faz solicitações ao serviço de back-end, cada solicitação é enviada pelo proxy sidecar.

Este aplicativo de demonstração usa o proxy do Envoy. Por isso, o cliente vê "server: envoy" no cabeçalho das respostas do servidor.

Para confirmar isso, use os comandos a seguir:

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

# Command to send a request to service-test and output server response headers.
TEST_CMD="wget -S --spider service-test; echo"

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

Neste exemplo, você criou uma regra de encaminhamento usando o endereço VIP 0.0.0.0. Isso significa que o Traffic Director encaminha solicitações para o back-end com base apenas no cabeçalho Host. Nesse caso, o endereço IP de destino pode ser qualquer endereço, desde que o cabeçalho do host da solicitação corresponda ao host definido no mapa de URL service-test.

Para confirmar isso, execute os comandos de teste a seguir:

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

# Command to send a request to service-test setting the Host header and using a random IP address.
TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo"

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