arrow_back

Teste de carga distribuída usando o Kubernetes

Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

Teste de carga distribuída usando o Kubernetes

Lab 1 hora universal_currency_alt 1 crédito show_chart Introdutório
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

GSP182

Laboratórios autoguiados do Google Cloud

Visão geral

Neste laboratório, você aprenderá a usar o Kubernetes Engine para implantar um framework de teste de carga distribuída. Neste framework, vários contêineres são usados na criação do tráfego desse teste para uma API simples baseada em REST. Ainda que o aplicativo da Web usado aqui seja simples, o mesmo padrão pode ser aplicado para criar cenários de teste de carga mais complexos, como aplicativos da Internet das Coisas (IoT na sigla em inglês) ou de jogos. Neste documento, será discutida a arquitetura geral de um framework de teste de carga baseado em contêineres.

Sistema em teste

Para este laboratório, o sistema em teste é um pequeno aplicativo da Web implantado no Google App Engine. No aplicativo, os endpoints básicos do tipo REST são expostos para capturar as solicitações POST HTTP recebidas. Os dados de entrada não são permanentes.

Cargas de trabalho de exemplo

O aplicativo a ser implantado tem como modelo o componente de serviço de back-end encontrado em várias implantações de Internet das Coisas (IoT na sigla em inglês). Primeiro, os dispositivos são registrados no serviço, e depois as métricas ou leituras do sensor começam a ser registradas. Ao mesmo tempo, o registro no serviço é refeito periodicamente.

Confira um exemplo comum de interação de componente de serviço de back-end: Um diagrama retratando a interação entre o cliente e o aplicativo

Para modelar essa interação, será usado o Locust, uma ferramenta de teste de carga distribuída e baseada em Python capaz de dividir solicitações em vários caminhos de destino. Por exemplo, com o Locust, essa distribuição é feita para os caminhos /login e /metrics.

A carga de trabalho tem como base a interação descrita anteriormente e é modelada como um conjunto de tarefas no Locust. Para simular situações reais dos clientes, cada tarefa do Locust tem um peso. Por exemplo, o registro ocorre uma vez a cada mil solicitações de cliente.

Computação baseada em contêineres

  • A imagem do contêiner do Locust é uma imagem do Docker que contém o software do Locust.

  • Um container cluster consiste em pelo menos um mestre de cluster e vários workers chamados de nós. As máquinas mestre e nós executam o sistema de orquestração de cluster do Kubernetes. Para mais informações sobre clusters, consulte a documentação do Kubernetes Engine.

  • Um pod é um ou mais contêineres implantados juntos em um host e corresponde à menor unidade de computação que pode ser definida, implantada e gerenciada. Alguns pods contêm somente um contêiner. Por exemplo, neste laboratório, cada contêiner do Locust é executado no próprio pod.

  • Um Deployment controller gera atualizações declarativas para Pods e ReplicaSets. Este laboratório tem duas implantações: uma para locust-master e outra para locust-worker.

Serviços

Um pod específico pode desaparecer por vários motivos, incluindo uma falha no nó ou a interrupção intencional dele para atualizações ou manutenção. Isso significa que o endereço IP desse pod não proporciona uma interface confiável para ele. Uma abordagem mais estável seria usar uma representação abstrata da interface que nunca é alterada, mesmo quando o pod subjacente desaparece e é substituído por outro com endereço IP diferente. Um service do Kubernetes Engine inclui esse tipo de interface abstrata ao definir um conjunto lógico de pods e uma política para acessá-los.

Neste laboratório, há vários serviços que representam pods ou conjunto de pods. Por exemplo, há um serviço para o pod do servidor DNS, outro para o pod mestre do Locust e um terceiro que representa os 10 pods de worker do Locust.

No diagrama a seguir, confira o conteúdo dos nós mestres e de trabalho:

Conteúdo dos nós mestres e de trabalho

O que você vai aprender

  • Criar um sistema em teste, ou seja, um pequeno aplicativo da Web implantado no Google App Engine
  • Usar o Kubernetes Engine para implantar um framework de teste de carga distribuída
  • Criar tráfego de teste de carga para uma API simples baseada em REST

Pré-requisitos

  • Conhecer os serviços App Engine e Kubernetes Engine do Google Cloud.
  • Conhecer os editores de texto padrão do Linux, como Vim, Emacs ou Nano.

Configuração e requisitos

Antes de clicar no botão Start Lab

Leia estas instruções. Os laboratórios são cronometrados e não podem ser pausados. O timer é iniciado quando você clica em Começar o laboratório e mostra por quanto tempo os recursos do Google Cloud vão ficar disponíveis.

Este laboratório prático permite que você realize as atividades em um ambiente real de nuvem, não em uma simulação ou demonstração. Você vai receber novas credenciais temporárias para fazer login e acessar o Google Cloud durante o laboratório.

Confira os requisitos para concluir o laboratório:

  • Acesso a um navegador de Internet padrão (recomendamos o Chrome).
Observação: para executar este laboratório, use o modo de navegação anônima ou uma janela anônima do navegador. Isso evita conflitos entre sua conta pessoal e a conta de estudante, o que poderia causar cobranças extras na sua conta pessoal.
  • Tempo para concluir o laboratório---não se esqueça: depois de começar, não será possível pausar o laboratório.
Observação: não use seu projeto ou conta do Google Cloud neste laboratório para evitar cobranças extras na sua conta.

Como iniciar seu laboratório e fazer login no console do Google Cloud

  1. Clique no botão Começar o laboratório. Se for preciso pagar, você verá um pop-up para selecionar a forma de pagamento. No painel Detalhes do laboratório à esquerda, você verá o seguinte:

    • O botão Abrir Console do Cloud
    • Tempo restante
    • As credenciais temporárias que você vai usar neste laboratório
    • Outras informações se forem necessárias
  2. Clique em Abrir Console do Google. O laboratório ativa recursos e depois abre outra guia com a página Fazer login.

    Dica: coloque as guias em janelas separadas lado a lado.

    Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.
  3. Caso seja preciso, copie o Nome de usuário no painel Detalhes do laboratório e cole esse nome na caixa de diálogo Fazer login. Clique em Avançar.

  4. Copie a Senha no painel Detalhes do laboratório e a cole na caixa de diálogo Olá. Clique em Avançar.

    Importante: você precisa usar as credenciais do painel à esquerda. Não use suas credenciais do Google Cloud Ensina. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.
  5. Acesse as próximas páginas:

    • Aceite os Termos e Condições.
    • Não adicione opções de recuperação nem autenticação de dois fatores (porque essa é uma conta temporária).
    • Não se inscreva em testes gratuitos.

Depois de alguns instantes, o console do GCP vai ser aberto nesta guia.

Observação: para ver uma lista dos produtos e serviços do Google Cloud, clique no Menu de navegação no canto superior esquerdo. Ícone do menu de navegação

Ativar o Cloud Shell

O Cloud Shell é uma máquina virtual com várias ferramentas de desenvolvimento. Ele tem um diretório principal permanente de 5 GB e é executado no Google Cloud. O Cloud Shell oferece acesso de linha de comando aos recursos do Google Cloud.

  1. Clique em Ativar o Cloud Shell Ícone "Ativar o Cloud Shell" na parte de cima do console do Google Cloud.

Depois de se conectar, vai notar que sua conta já está autenticada, e que o projeto está configurado com seu PROJECT_ID. A saída contém uma linha que declara o projeto PROJECT_ID para esta sessão:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.

  1. (Opcional) É possível listar o nome da conta ativa usando este comando:
gcloud auth list
  1. Clique em Autorizar.

  2. A saída será parecida com esta:

Saída:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (Opcional) É possível listar o ID do projeto usando este comando:
gcloud config list project

Saída:

[core] project = <project_ID>

Exemplo de saída:

[core] project = qwiklabs-gcp-44776a13dea667a6 Observação: para conferir a documentação completa da gcloud, acesse o guia com informações gerais sobre a gcloud CLI no Google Cloud.

Tarefa 1: Defina o projeto e a zona

  • Defina as variáveis de ambiente de project id, region e zone que você quer usar neste laboratório.
PROJECT=$(gcloud config get-value project) REGION={{{ project_0.default_region | "REGION" }}} ZONE={{{ project_0.default_zone | "ZONE" }}} CLUSTER=gke-load-test TARGET=${PROJECT}.appspot.com gcloud config set compute/region $REGION gcloud config set compute/zone $ZONE

Tarefa 2: Receba o exemplo de código e crie uma imagem do Docker para o aplicativo

  1. Receba o código-fonte do repositório executando:
gsutil -m cp -r gs://spls/gsp182/distributed-load-testing-using-kubernetes .
  1. Acesse o diretório:
cd distributed-load-testing-using-kubernetes/
  1. Crie a imagem do Docker e armazene-a no Container Registry:
gcloud builds submit --tag gcr.io/$PROJECT/locust-tasks:latest docker-image/.

Exemplo de saída:

ID CREATE_TIME DURATION SOURCE IMAGES STATUS 47f1b8f7-0b81-492c-aa3f-19b2b32e515d xxxxxxx 51S gs://project_id_cloudbuild/source/1554261539.12-a7945015d56748e796c55f17b448e368.tgz gcr.io/project_id/locust-tasks (+1 more) SUCCESS

Clique em Verificar meu progresso para conferir o objetivo. Receba o exemplo de código e crie uma imagem do Docker para o aplicativo

Tarefa 3: Implante o aplicativo da Web

A pasta sample-webapp contém um aplicativo Python simples do Google App Engine como "sistema em teste".

  • Use o comando gcloud app deploy para implantar o aplicativo no projeto:
gcloud app deploy sample-webapp/app.yaml

Depois de executar o comando, você vai precisar fazer o seguinte:

Escolha a região em que o aplicativo do App Engine está localizado:

Na lista de regiões, você pode escolher , desde que tenhamos selecionado como a região para este projeto. Por exemplo, para escolher us-central, insira "10" como a entrada para o comando.

Please enter your numeric choice: 10 Observação: você vai precisar do URL do aplicativo da Web de amostra implantado ao realizar as implantações locust-master e locust-worker, que já está armazenado na variável TARGET.

Clique em Verificar meu progresso para conferir o objetivo. Implante o aplicativo da Web

Tarefa 4: Implante o cluster do Kubernetes

gcloud container clusters create $CLUSTER \ --zone $ZONE \ --num-nodes=5

Exemplo de saída:

NAME: gke-load-test LOCATION: {{{ project_0.default_zone | "ZONE" }}} MASTER_VERSION: 1.11.7-gke.12 MASTER_IP: 34.66.156.246 MACHINE_TYPE: n1-standard-1 NODE_VERSION: 1.11.7-gke.12 NUM_NODES: 5 STATUS: RUNNING

Clique em Verificar meu progresso para conferir o objetivo. Implante o cluster do Kubernetes

Tarefa 5: Mestre do teste de carga

O primeiro componente da implantação é o mestre do Locust. Ele é o ponto de entrada para executar as tarefas de teste de carga descritas acima. Esse mestre é implantado com uma única réplica, porque somente uma é necessária.

Na configuração da implantação do mestre, vários elementos são especificados, incluindo as portas que precisam ser expostas pelo contêiner (8089 para a interface da Web, 5557 e 5558 para a comunicação com os workers). Essas informações serão usadas depois na configuração dos workers do Locust.

No seguinte snippet, confira as configurações das portas:

ports: - name: loc-master-web containerPort: 8089 protocol: TCP - name: loc-master-p1 containerPort: 5557 protocol: TCP - name: loc-master-p2 containerPort: 5558 protocol: TCP

Tarefa 6. Implante o locust-master

  1. Substitua [TARGET_HOST] e [PROJECT_ID] em locust-master-controller.yaml e locust-worker-controller.yaml pelo endpoint e o ID do projeto implantados, respectivamente.
sed -i -e "s/\[TARGET_HOST\]/$TARGET/g" kubernetes-config/locust-master-controller.yaml sed -i -e "s/\[TARGET_HOST\]/$TARGET/g" kubernetes-config/locust-worker-controller.yaml sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" kubernetes-config/locust-master-controller.yaml sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" kubernetes-config/locust-worker-controller.yaml
  1. Implante o mestre do Locust:
kubectl apply -f kubernetes-config/locust-master-controller.yaml
  1. Para confirmar se o pod locust-master foi criado, execute o seguinte comando:
kubectl get pods -l app=locust-master
  1. Depois, implante o locust-master-service:
kubectl apply -f kubernetes-config/locust-master-service.yaml

Essa etapa exibirá o pod com um nome de DNS interno (locust-master) e as portas 8089, 5557 e 5558. Como parte da etapa, a diretiva type: LoadBalancer em locust-master-service.yaml solicitará ao Google Kubernetes Engine que seja criada uma regra de encaminhamento do Compute Engine de um endereço IP publicamente disponível para o pod locust-master.

  1. Para visualizar a nova regra de encaminhamento, execute o seguinte:
kubectl get svc locust-master

Exemplo de saída:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE locust-master LoadBalancer 10.59.244.88 35.222.161.198 8089:30865/TCP,5557:30707/TCP,5558:31327/TCP 1m

Clique em Verificar meu progresso para conferir o objetivo. Mestre do teste de carga

Tarefa 7. Workers de teste de carga

O próximo componente da implantação inclui os workers do Locust, que executam as tarefas de teste de carga descritas acima. Esses workers são implantados por uma única implantação que cria vários pods. Esses pods são distribuídos no cluster do Kubernetes. Cada um deles usa variáveis de ambiente para controlar informações essenciais, por exemplo, os nomes dos hosts do sistema em teste e do mestre do Locust.

Depois que os workers do Locust forem implantados, volte para a interface da Web do mestre e veja se o número de escravos corresponde ao número de workers implantados.

No seguinte snippet, veja a configuração de nome, marcadores e número de réplicas da implantação:

apiVersion: "apps/v1" kind: "Deployment" metadata: name: locust-worker labels: name: locust-worker spec: replicas: 5 selector: matchLabels: app: locust-worker template: metadata: labels: app: locust-worker spec: ...

Implante o locust-worker

  1. Agora, implante o locust-worker-controller:
kubectl apply -f kubernetes-config/locust-worker-controller.yaml
  1. O locust-worker-controller está configurado para implantar cinco pods de locust-worker. Para confirmar se eles foram implantados, execute o seguinte:
kubectl get pods -l app=locust-worker

Para escalonar o número de simulações de usuários, é necessário aumentar o número de pods de worker do Locust. Para isso, o Kubernetes oferece a capacidade de redimensionar as implantações sem reimplantá-las.

  1. No seguinte comando, o pool desses pods é escalonado para 20:
kubectl scale deployment/locust-worker --replicas=20
  1. Para verificar se os pods foram lançados e estão prontos, receba a lista de pods de locust-worker:
kubectl get pods -l app=locust-worker

No diagrama a seguir, veja a relação entre o mestre e os workers do Locust:

O fluxo do mestre para o worker do Locust para o aplicativo

Clique em Verificar meu progresso para conferir o objetivo. Workers de teste de carga

Tarefa 8: Execute testes

  1. Para executar os testes do Locust, receba o endereço IP externo com o comando:
EXTERNAL_IP=$(kubectl get svc locust-master -o yaml | grep ip: | awk -F": " '{print $NF}') echo http://$EXTERNAL_IP:8089
  1. Clique no link e acesse a interface da Web do mestre do Locust.

Com a interface da Web do mestre do Locust, você pode executar as tarefas de teste de carga no sistema em teste.

934dc685f86ood1f.png

  1. Para começar, especifique o número total de usuários que serão simulados e uma taxa pela qual cada usuário será gerado.

  2. Depois, clique em "Start swarming" para iniciar a simulação. Por exemplo, é possível especificar o número de usuários como 300 e a taxa como 10.

  3. Clique em Start swarming.

Conforme o tempo avança e os usuários são gerados, as estatísticas são agregadas para métricas de simulação, como o número de solicitações e solicitações por segundo.

  1. Para interromper a simulação, clique em Stop, e o teste será encerrado. Faça o download dos resultados completos em uma planilha.

Parabéns!

Você usou o Kubernetes Engine para implantar um framework de teste de carga distribuída.

Termine a Quest

Este laboratório autoguiado faz parte da Quest Google Cloud Solutions I: Scaling Your Infrastructure. Uma Quest é uma série de laboratórios relacionados que formam um programa de aprendizado. Ao concluir uma Quest, você ganha um selo como reconhecimento da sua conquista. É possível publicar os selos e incluir um link para eles no seu currículo on-line ou nas redes sociais. Inscreva-se em qualquer Quest que tenha este laboratório para receber os créditos de conclusão na mesma hora. Confira o catálogo do Google Cloud Ensina para ver todas as Quests disponíveis.

Comece o próximo laboratório

Continue a Quest com o próximo laboratório ou confira esses laboratórios do Google Cloud Ensina:

Treinamento e certificação do Google Cloud

Esses treinamentos ajudam você a aproveitar as tecnologias do Google Cloud ao máximo. Nossas aulas incluem habilidades técnicas e práticas recomendadas para ajudar você a alcançar rapidamente o nível esperado e continuar sua jornada de aprendizado. Oferecemos treinamentos que vão do nível básico ao avançado, com opções de aulas virtuais, sob demanda e por meio de transmissões ao vivo para que você possa encaixá-las na correria do seu dia a dia. As certificações validam sua experiência e comprovam suas habilidades com as tecnologias do Google Cloud.

Manual atualizado em 12 de outubro de 2023

Laboratório testado em 12 de outubro de 2023

Copyright 2024 Google LLC. Todos os direitos reservados. Google e o logotipo do Google são marcas registradas da Google LLC. Todos os outros nomes de produtos e empresas podem ser marcas registradas das respectivas empresas a que estão associados.