Configurar pods do Google Kubernetes Engine usando injeção manual do 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.

Observação: os exemplos de configuração são para fins de demonstração. Talvez seja necessário implantar mais componentes com base no ambiente e nos requisitos.

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:

• 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. O recurso independente de NEGs está disponível para o Traffic Director.
• A conta de serviço das instâncias de nós do cluster precisa ter permissão para acessar a API Traffic Director.
  • Saiba mais sobre as permissões necessárias em Como ativar a conta de serviço para acessar a API Traffic Director.
  • Para informações sobre como ativar a API Traffic Director, consulte Como ativar a API Traffic Director.
• Os contêineres precisam ter acesso à API Traffic Director, protegida pela autenticação OAuth. Para mais informações, consulte a configuração do host.

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 Google Cloud, siga estas etapas:

1. Acesse o menu do Kubernetes Engine no Console do Google 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 Google 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.

Configure a regra 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 de políticas de firewall no console do Google Cloud.
   Acessar a página "Políticas de firewall"
2. Clique em Criar regras de firewall.
3. 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. TCP é o protocolo de base para 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

Os serviços do GKE precisam ser identificados 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 Traffic Director. 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 Traffic Director. 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": "NEG-NAME"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

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 salvar 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.
Acesse a página Grupos de endpoints de rede

gcloud

gcloud compute network-endpoint-groups list

Isso retorna o resultado a seguir:

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

Salve o nome do NEG na variável NEG_NAME, por exemplo:

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

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

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:

• 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.
• uma regra de rota Isso inclui a criação de uma regra de encaminhamento e um mapa de URL. Para mais informações, leia Como usar regras de encaminhamento e Como usar mapas de URL.

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

Observação: independentemente do método selecionado, o tráfego para o endereço VIP que o nome de host do serviço resolve precisa ser interceptado pelo proxy sidecar no host do cliente que precisa acessar seu serviço. Consulte Como configurar uma única VM do Compute Engine no Traffic Director para ver detalhes completos de configuração do host.

Observação: cada regra de encaminhamento em uma rede VPC precisa ter uma combinação exclusiva de endereço IP e porta por rede VPC, incluindo: 0.0.0.0 endereço. Se você criar mais de uma regra de encaminhamento com o mesmo endereço IP e a mesma porta em uma determinada rede VPC, somente a primeira regra de encaminhamento será válida. Os outros são ignorados.

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

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

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 de arquivo secundário do Istio e contêineres init adicionados à implantação usando a especificação de referência:

Se você estiver usando as APIs mais antigas, substitua as variáveis PROJECT_NUMBER e NETWORK_NAME pelo número do projeto e o nome da rede:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml
sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_sample_xdsv3.yaml

Se você estiver usando as novas APIs de roteamento de serviço, que estão em visualização, substitua as variáveis PROJECT_NUMBER e MESH_NAME pelo número do projeto e nome Mesh:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml

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 sider 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"

A seguir

• Saiba mais sobre o gerenciamento de tráfego avançado.
• Saiba como resolver problemas de implantações do Traffic Director.
• Saiba como configurar a observabilidade com o Envoy.