
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
- On the top left of your screen, click Start lab to begin
Get the sample code and build a Docker image for the application
/ 20
Deploy Web Application
/ 20
Deploy Kubernetes Cluster
/ 20
Load testing master
/ 20
Load testing workers
/ 20
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.
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.
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:
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.
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
.
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:
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:
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ê vai encontrar o seguinte:
Se você estiver usando o navegador Chrome, clique em Abrir console do Google Cloud ou clique com o botão direito do mouse e selecione Abrir link em uma janela anônima.
O laboratório ativa os recursos e depois abre a página Fazer login em outra guia.
Dica: coloque as guias em janelas separadas lado a lado.
Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Fazer login.
Você também encontra o Nome de usuário no painel Detalhes do laboratório.
Clique em Seguinte.
Copie a Senha abaixo e cole na caixa de diálogo de boas-vindas.
Você também encontra a Senha no painel Detalhes do laboratório.
Clique em Seguinte.
Acesse as próximas páginas:
Depois de alguns instantes, o console do Google Cloud será aberto nesta guia.
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.
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:
gcloud
é a ferramenta de linha de comando do Google Cloud. Ela vem pré-instalada no Cloud Shell e aceita preenchimento com tabulação.
Clique em Autorizar.
A saída será parecida com esta:
Saída:
Saída:
Exemplo de saída:
gcloud
, acesse o guia com informações gerais sobre a gcloud CLI no Google Cloud.
project id
, region
e zone
que você quer usar neste laboratório.Exemplo de saída:
Clique em Verificar meu progresso para conferir o objetivo.
A pasta sample-webapp
contém um aplicativo Python simples do Google App Engine como "sistema em teste".
gcloud app deploy
para implantar o aplicativo no projeto:Depois de executar o comando, você vai precisar fazer o seguinte:
Na lista de regiões, você pode escolher us-central
, insira "10" como a entrada para o comando.
locust-master
e locust-worker
, que já está armazenado na variável TARGET
.
Clique em Verificar meu progresso para conferir o objetivo.
gcloud
abaixo:Exemplo de saída:
Clique em Verificar meu progresso para conferir o objetivo.
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:
[TARGET_HOST]
e [PROJECT_ID]
em locust-master-controller.yaml
e locust-worker-controller.yaml
pelo endpoint e o ID do projeto implantados, respectivamente.locust-master
foi criado, execute o seguinte comando:locust-master-service
: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
.
Exemplo de saída:
Clique em Verificar meu progresso para conferir o objetivo.
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:
locust-worker-controller
:locust-worker-controller
está configurado para implantar cinco pods de locust-worker
. Para confirmar se eles foram implantados, execute o seguinte: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.
20
:locust-worker
:No diagrama a seguir, veja a relação entre o mestre e os workers do Locust:
Clique em Verificar meu progresso para conferir o objetivo.
Com a interface da Web do mestre do Locust, você pode executar as tarefas de teste de carga no sistema em teste.
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.
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.
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.
Você usou o Kubernetes Engine para implantar um framework de teste de carga distribuída.
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.
Continue a Quest com o próximo laboratório ou confira esses laboratórios do Google Cloud Ensina:
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 2025 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.
Este conteúdo não está disponível no momento
Você vai receber uma notificação por e-mail quando ele estiver disponível
Ótimo!
Vamos entrar em contato por e-mail se ele ficar disponível
One lab at a time
Confirm to end all existing labs and start this one