Configure pods do Google Kubernetes Engine através da injeção manual do Envoy

Este guia mostra como configurar os anfitriões do Google Kubernetes Engine ou do Kubernetes Pod e os componentes de balanceamento de carga que a malha de serviços na nuvem requer.

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.

Pode configurar a malha de serviços na nuvem através do SDK de balanceamento de carga do Compute Engine ou das APIs REST. Consulte a API de equilíbrio de carga e as referências do gcloud.

Configurar clusters do GKE/Kubernetes para o Cloud Service Mesh

Esta secção descreve os passos necessários para permitir que os clusters do GKE/Kubernetes funcionem com a Cloud Service Mesh.

Criar o cluster do GKE

Os clusters do GKE têm de cumprir os seguintes requisitos:

  • 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 funcionalidade NEGs autónoma está disponível para disponibilidade geral para a Cloud Service Mesh.
  • A conta de serviço das instâncias dos nós do cluster tem de ter autorização para aceder à API Cloud Service Mesh.
  • Os contentores têm de ter acesso à API Cloud Service Mesh, protegida pela autenticação OAuth. Para mais informações, consulte a configuração do anfitrião.

O exemplo seguinte mostra como criar um cluster do GKE denominado traffic-director-cluster na zona us-central1-a.

Consola

Para criar um cluster através da Google Cloud consola, siga os passos seguintes:

  1. Aceda ao menu Kubernetes Engine na Google Cloud consola.

    Aceda ao menu do Google Kubernetes Engine

  2. Clique em Criar cluster.

  3. Preencha os seguintes campos:

    • Nome: introduza traffic-director-cluster.
    • Tipo de localização: Zonal.
    • Zona: us-central1-a.

  4. No painel de navegação, em Node Pools, clique em default-pool.

  5. O campo Tamanho indica o número de nós a criar no cluster. Tem de ter quota de recursos disponível para os nós e os respetivos recursos (como trajetos de firewall).

  6. No painel de navegação, em default-pool, clique em Nodes.

  7. O campo Tipo de máquina indica o tipo de máquina do Compute Engine a usar para as instâncias. Cada tipo de máquina é faturado de forma diferente. Para informações sobre os preços dos tipos de máquinas, 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 Âmbitos de acesso, clique em Permitir acesso total a todas as APIs Cloud.

  10. Personalize o cluster conforme necessário.

  11. Clique em Criar.

Depois de criar um cluster na Google Cloud consola, tem de o configurar kubectl para interagir com o cluster. Para saber mais, consulte o artigo 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

Obter os privilégios do cluster do GKE necessários

Para o GKE, mude para o cluster(2) que acabou de criar emitindo o seguinte comando. Isto direciona o kubectl para o cluster correto.

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

Configurar serviços do GKE/Kubernetes

Esta secção mostra como preparar as especificações de implementação do Kubernetes para trabalhar com a Cloud Service Mesh. Isto consiste em configurar serviços com NEGs, bem como injetar proxies sidecar em pods que requerem acesso aos serviços geridos pela Cloud Service Mesh.

Configure a regra de firewall

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

Consola

  1. Aceda à página Políticas de firewall na Google Cloud consola.
    Aceda à página Políticas de firewall
  2. Clique em Criar regras de firewall.
  3. Na página Criar 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 na 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 estado.
    • Clique em Criar.

gcloud

  1. Use o seguinte comando gcloud para criar uma regra de firewall denominada fw-allow-health-checks que permita ligações recebidas a instâncias na sua rede com a etiqueta 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 o artigo configure a regra da firewall para verificações de funcionamento.

Configurar serviços do GKE / Kubernetes 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.

...
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, é criado um NEG autónomo que contém pontos finais que são os endereços IP e as portas do pod. Para mais informações e exemplos, consulte o artigo Grupos de pontos finais de rede autónomos.

Para fins de demonstração, pode implementar um serviço de exemplo que publique o respetivo nome do anfitrião através de HTTP na porta 80:

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

Verifique se o novo nome de anfitrião do serviço foi criado e se o pod da aplicação está em execução:

kubectl get svc

Isto devolve: 

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


kubectl get pods

Isto devolve: 

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

Guardar o nome do NEG

Encontre o NEG criado a partir do exemplo acima e registe o nome do NEG.

Consola

Para ver uma lista de grupos de pontos finais de rede, aceda à página Grupos de pontos finais de rede na Google Cloud consola.
Aceda à página Grupos de pontos finais da rede

gcloud

gcloud compute network-endpoint-groups list

Esta função devolve o seguinte:

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

Guarde o nome do GNE na variável NEG_NAME, por exemplo:

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

Configurar Google Cloud componentes de equilíbrio de carga para a Cloud Service Mesh

As instruções nesta secção garantem que os serviços do GKE estão acessíveis no VIP de serviço com balanceamento de carga do Cloud Service Mesh, usando uma configuração de balanceamento de carga semelhante a outros produtos do Google Cloud Load Balancing.

Tem de configurar os seguintes componentes:

O exemplo de configuração da malha de serviços na nuvem que se segue baseia-se nas seguintes pressuposições:

  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 para o cluster é armazenado na variável ${NEG_NAME}.

Criar a verificação de funcionamento

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

gcloud 

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

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

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

  7. Defina o RPS máximo como 5.

  8. Clique em Concluído.

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

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

Criar o mapa de regras de encaminhamento

Use estas instruções para criar a regra de encaminhamento, a regra de encaminhamento e o endereço IP interno para a configuração da Cloud Service Mesh.

O tráfego enviado para o endereço IP interno é intercetado pelo proxy Envoy e enviado para o serviço adequado de acordo com as regras de anfitrião e caminho.

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

Pode definir o endereço da sua regra de encaminhamento como 0.0.0.0. Se o fizer, o tráfego é encaminhado com base no nome do anfitrião HTTP e nas informações do caminho configuradas no mapa de URLs, independentemente do endereço IP real para o qual o nome do anfitrião é resolvido. Neste caso, os URLs (nome do anfitrião mais caminho do URL) dos seus serviços, conforme configurados nas regras de anfitrião, têm de ser únicos na configuração da malha de serviços. Ou seja, não pode ter dois serviços diferentes, com um conjunto diferente de back-ends, que usem a mesma combinação de nome de anfitrião e caminho.

Em alternativa, pode ativar o encaminhamento com base no VIP de destino real do serviço. Se configurar o VIP do seu serviço como um parâmetro address da regra de encaminhamento, apenas os pedidos destinados a este endereço IP são encaminhados com base nos parâmetros HTTP especificados no mapa de URLs.

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

    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 (/*). service-test também é o nome configurado do serviço Kubernetes que é usado na configuração de exemplo 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 Cloud Service Mesh está configurado para equilibrar a carga do tráfego para os serviços especificados no mapa de URLs em back-ends no grupo de pontos finais de rede.

Consoante a forma como os seus microsserviços são distribuídos na sua rede, pode ter de adicionar mais regras de encaminhamento ou mais regras de anfitrião e caminho ao mapa de URLs.

Validar a configuração implementando um cliente de exemplo para testes

Esta secção mostra como aceder aos back-ends da Cloud Service Mesh a partir de uma aplicação cliente.

Para demonstrar a funcionalidade, pode implementar um exemplo de Pod que execute o Busybox. O pod tem acesso a service-test, que foi criado na secção anterior, e recebe tráfego com balanceamento de carga do Cloud Service Mesh.

Injetar um proxy complementar em pods do GKE / Kubernetes

Para aceder a um serviço gerido pela Cloud Service Mesh, um Pod tem de ter um proxy sidecar compatível com a API xDS instalado.

Neste exemplo, implementa um cliente Busybox com um sidecar do Istio-proxy e contentores init adicionados à implementação através da especificação de referência.

Se estiver a usar as APIs mais antigas, substitua as variáveis PROJECT_NUMBER e NETWORK_NAME pelo número do projeto e pelo 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 estiver a usar as novas APIs de encaminhamento de serviços, que estão atualmente em pré-visualização, substitua as variáveis PROJECT_NUMBER e MESH_NAME pelo número do projeto e pelo 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 Busybox tem dois contentores em execução. O primeiro contentor é o cliente baseado na imagem do Busybox e o segundo contentor é o proxy do Envoy injetado como um sidecar. Pode obter mais informações sobre o pod executando o seguinte comando:

kubectl describe pods -l run=client

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

Depois de configuradas, as aplicações em pods com um proxy sidecar injetado podem aceder a serviços geridos pelos serviços do Cloud Service Mesh. Para validar a configuração, pode aceder a uma shell num dos contentores.

Se usou a configuração de demonstração fornecida neste guia, pode executar o seguinte comando de validação para se certificar de que o nome do anfitrião do pod de publicação é devolvido.

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

Compreender a interceção de tráfego pelo proxy sidecar

Tenha em atenção que, neste exemplo, quando o cliente Busybox faz pedidos ao serviço de back-end, cada pedido é encaminhado através do proxy sidecar.

Esta aplicação de demonstração usa o proxy Envoy. Por esse motivo, o cliente vê "server: envoy" no cabeçalho das respostas do servidor.

Para confirmar, use os seguintes comandos:

# 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, criou uma regra de encaminhamento com o endereço IP virtual 0.0.0.0. Isto significa que a Cloud Service Mesh encaminha pedidos para o back-end com base apenas no cabeçalho Host. Neste caso, o endereço IP de destino pode ser qualquer endereço, desde que o cabeçalho do anfitrião do pedido corresponda ao anfitrião definido no mapa de URLs service-test.

Para confirmar, execute os seguintes comandos de teste:

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

O que se segue?