Configurar pods do Google Kubernetes Engine usando injeção manual do Envoy
Neste guia, mostramos como configurar hosts de pod do Google Kubernetes Engine ou do Kubernetes e os componentes do balanceamento de carga exigidos pelo Cloud Service Mesh.
Antes de seguir as instruções deste guia, conclua o pré-requisito tarefas descritas em Prepare-se para configurar APIs de roteamento de serviço com cargas de trabalho Envoy e sem proxy.
É possível configurar o Cloud Service Mesh usando o balanceamento de carga do Compute Engine SDK ou APIs REST. Consulte as referências da API de balanceamento de carga e do gcloud.
Como configurar clusters do GKE/Kubernetes para o Cloud Service Mesh
Nesta seção, descrevemos as etapas necessárias para ativar Clusters do GKE/Kubernetes para funcionar com o Cloud Service Mesh.
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 de NEGs independentes está com disponibilidade geral para do Cloud Service Mesh.
- A conta de serviço das instâncias de nós do cluster precisa ter permissão para acessar
a API Cloud Service Mesh.
- Para mais informações sobre os requisitos de acesso, consulte Ative a conta de serviço para acessar a API Traffic Director.
- Para informações sobre como ativar a API Cloud Service Mesh, consulte Como ativar a API Cloud Service Mesh.
- Os contêineres precisam ter acesso à API Cloud Service Mesh, 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:
Acesse o menu do Kubernetes Engine no Console do Google Cloud.
Clique em Criar cluster.
Preencha os seguintes campos:
- Nome: insira
traffic-director-cluster
. - Tipo de local:
Zonal
. - Zona:
us-central1-a
.
- Nome: insira
No painel de navegação, em Pools de nós, clique em default-pool.
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.
No painel de navegação, em default-pool, clique em Nós.
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.
No painel de navegação, em default-pool, clique em Segurança.
Em Escopos de acesso, clique em Permitir acesso total a todas as APIs do Cloud.
Personalize seu cluster conforme necessário.
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, mostramos como preparar as especificações de implantação do Kubernetes para funcionar com o Cloud Service Mesh. Isso consiste em configurar serviços com NEGs, bem como injetar proxies sidecar em pods que exigem acesso aos serviços gerenciados pelo Cloud Service Mesh.
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
- Acesse a página de políticas de firewall no console do Google Cloud.
Acessar a página "Políticas de firewall" - Clique em Criar regras de firewall.
- 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 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.
- Nome: informe um nome para a regra. Neste exemplo, use
gcloud
Use o comando
gcloud
a seguir para criar uma regra de firewall chamadafw-allow-health-checks
que permita conexões de entrada com instâncias na sua rede com a tagallow-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 expostos por grupos de endpoints de rede
(NEGs) para que você possa configurá-los como back-ends de um back-end do Cloud Service Mesh
serviço. 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": "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}')
Como configurar componentes do balanceamento de carga do Google Cloud para o Cloud Service Mesh
As instruções nesta seção garantem que o GKE podem ser acessados no serviço VIP com carga balanceada pelo Cloud Service Mesh, usando uma configuração de balanceamento de carga semelhante 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 Cloud Service Mesh a seguir presume que:
- Os NEGs e todos os outros recursos são criados na rede
default
, com o modo automático, na zonaus-central1-a
. - 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
- Acesse a página "Verificações de integridade" no Console do Google Cloud.
Acessar a página "Verificações de integridade" - Clique em Criar verificação de integridade.
- Para o nome, insira
td-gke-health-check
. - Como protocolo, selecione HTTP.
- 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
Acesse a página "Cloud Service Mesh" no console do Google Cloud.
Na guia Serviços, clique em Criar serviço.
Clique em Continuar.
Como nome do serviço, insira
td-gke-service
.Em Tipo de back-end, selecione Grupos de endpoints de rede.
Selecione o grupo de endpoints de rede que você criou.
Defina o RPS máximo como
5
.Clique em Concluído.
Em Verificação de integridade, selecione
td-gke-health-check
, que é a verificação de integridade que você criou.Clique em Continuar.
gcloud
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
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 a Endereço IP para a configuração do Cloud Service Mesh.
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).
Acesse a página do Cloud Service Mesh no console do Google Cloud.
Clique em Mapas de regra de roteamento.
Clique em Criar regra de roteamento.
Insira
td-gke-url-map
como o Nome do mapa de URL.Clique em Adicionar regra de encaminhamento.
Como nome da regra de encaminhamento, insira
td-gke-forwarding-rule
.Selecione a rede.
Selecione seu IP interno.
Clique em Salvar.
Opcionalmente, adicione regras de host e de caminho personalizadas ou use as regras padrão.
Defina o host como
service-test
.Clique em Salvar.
gcloud
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
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
Crie o proxy HTTP de destino.
gcloud compute target-http-proxies create td-gke-proxy \ --url-map td-gke-url-map
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 balancear a carga do tráfego da 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 acessar back-ends do Cloud Service Mesh de um cliente para o aplicativo.
Para testar a funcionalidade, implante um pod de amostra que executa 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 Cloud Service Mesh.
Como inserir um proxy sidecar nos pods do GKE/Kubernetes
Para acessar um serviço gerenciado pelo Cloud Service Mesh, um pod precisa ter um Proxy de arquivo secundário compatível com a API xDS instalado.
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
Após a configuração, os aplicativos em pods com um proxy sidecar injetado podem acesso aos serviços gerenciados pelos serviços do Cloud Service Mesh. 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 Cloud Service Mesh 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 Cloud Service Mesh.
- Saiba como configurar a observabilidade com o Envoy.