GSP769

Visão geral

Um dos muitos benefícios de usar o Google Cloud é o modelo de faturamento que cobra somente os recursos que você usa. Com isso em mente, é essencial alocar uma quantidade razoável de recursos para seus apps e infraestrutura, além de fazer o uso mais eficiente deles. Com o GKE, há várias ferramentas e estratégias disponíveis que podem reduzir o uso de recursos e serviços ao mesmo tempo que melhoram a disponibilidade do seu aplicativo.

Neste laboratório, abordaremos alguns conceitos que ajudarão a aumentar a eficiência e a disponibilidade de recursos das suas cargas de trabalho. Ao entender e ajustar a carga de trabalho, você garante que apenas os recursos necessários sejam usados, otimizando os custos do cluster.

Objetivos

Neste laboratório, você vai aprender a:

• Usar uma entrada para criar um balanceador de carga nativo do contêiner
• Testar a carga de um aplicativo
• Configurar sondagens de prontidão e atividade
• Criar um orçamento de interrupção de pods

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ê vai encontrar o seguinte:

   • O botão Abrir console do Google Cloud
   • O tempo restante
   • As credenciais temporárias que você vai usar neste laboratório
   • Outras informações, se forem necessárias

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

   Observação: se aparecer a caixa de diálogo Escolher uma conta, clique em Usar outra conta.

3. Se necessário, copie o Nome de usuário abaixo e cole na caixa de diálogo Fazer login.

   {{{user_0.username | "Nome de usuário"}}}

   Você também encontra o Nome de usuário no painel Detalhes do laboratório.

4. Clique em Seguinte.

5. Copie a Senha abaixo e cole na caixa de diálogo de boas-vindas.

   {{{user_0.password | "Senha"}}}

   Você também encontra a Senha no painel Detalhes do laboratório.

6. Clique em Seguinte.

   Importante: você precisa usar as credenciais fornecidas no laboratório, e não as da sua conta do Google Cloud. Observação: se você usar sua própria conta do Google Cloud neste laboratório, é possível que receba cobranças adicionais.

7. 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 Google Cloud será aberto nesta guia.

Observação: clique em Menu de navegação no canto superior esquerdo para acessar uma lista de produtos e serviços do Google Cloud.

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

2. (Opcional) É possível listar o nome da conta ativa usando este comando:

gcloud auth list

3. Clique em Autorizar.

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

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

Provisione o ambiente do laboratório

1. Defina a zona padrão como "":

gcloud config set compute/zone {{{project_0.default_zone|ZONE}}}

2. Clique em Autorizar.

3. Crie um cluster de três nós:

gcloud container clusters create test-cluster --num-nodes=3 --enable-ip-alias

A flag --enable-ip-alias está incluída para permitir o uso de IPs de alias para pods que vão ser necessários para o balanceamento de carga nativo de contêiner por uma entrada.

Neste laboratório, você vai usar um app da Web HTTP simples para implantar inicialmente como um único pod.

4. Crie um manifesto para o pod gb-frontend:

cat << EOF > gb_frontend_pod.yaml apiVersion: v1 kind: Pod metadata: labels: app: gb-frontend name: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 256Mi ports: - containerPort: 80 EOF

5. Aplique o manifesto criado ao cluster:

kubectl apply -f gb_frontend_pod.yaml Observação: espere de 1 a 2 minutos para receber a pontuação da tarefa.

Clique em Verificar meu progresso para conferir o objetivo. Provisione o ambiente do laboratório

Tarefa 1: balanceamento de carga nativo de contêiner com uma entrada

O balanceamento de carga nativo de contêiner permite que os balanceadores de carga visem pods do Kubernetes diretamente e distribuam o tráfego por igual entre eles.

Sem o balanceamento de carga nativo de contêiner, o tráfego do balanceador de carga passaria para grupos de instâncias de nós e seria roteado por meio de regras iptables para pods, que podem ou não estar no mesmo nó:

Com o balanceamento de carga nativo de contêiner, os pods se tornam os objetos principais do balanceamento, reduzindo o número de saltos de rede:

Além do roteamento mais eficiente, o balanceamento de carga nativo de contêiner resulta em uma redução considerável da utilização de rede, melhoria do desempenho, distribuição uniforme do tráfego entre os pods e verificações de integridade no nível do aplicativo.

Para aproveitar o balanceamento de carga nativo de contêiner, a configuração nativa de VPC precisa estar ativada no cluster. Isso foi indicado quando você criou o cluster e incluiu a flag --enable-ip-alias.

1. O manifesto a seguir vai configurar um serviço ClusterIP que será usado no roteamento do tráfego para o pod de aplicativo, permitindo que o GKE crie um grupo de endpoints de rede:

cat << EOF > gb_frontend_cluster_ip.yaml apiVersion: v1 kind: Service metadata: name: gb-frontend-svc annotations: cloud.google.com/neg: '{"ingress": true}' spec: type: ClusterIP selector: app: gb-frontend ports: - port: 80 protocol: TCP targetPort: 80 EOF

O manifesto inclui um campo annotations em que a anotação de cloud.google.com/neg vai ativar o balanceamento de carga nativo de contêiner no aplicativo quando uma entrada for criada.

2. Aplique a mudança no cluster:

kubectl apply -f gb_frontend_cluster_ip.yaml

3. Em seguida, crie uma entrada para o aplicativo:

cat << EOF > gb_frontend_ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: gb-frontend-ingress spec: defaultBackend: service: name: gb-frontend-svc port: number: 80 EOF

4. Aplique a mudança no cluster:

kubectl apply -f gb_frontend_ingress.yaml

Quando a entrada é criada, um balanceador de carga HTTP(S) é criado com um grupo de endpoints de rede (NEG, na sigla em inglês) em cada zona em que o cluster é executado. Após alguns minutos, um IP externo será atribuído à entrada.

O balanceador de carga criado tem um serviço de back-end em execução no projeto que define como o Cloud Load Balancing distribui o tráfego. Esse serviço de back-end está associado a um status de integridade.

5. Para verificar o status da integridade do serviço de back-end, primeiro recupere o nome:

BACKEND_SERVICE=$(gcloud compute backend-services list | grep NAME | cut -d ' ' -f2)

6. Confira o status de integridade do serviço:

gcloud compute backend-services get-health $BACKEND_SERVICE --global

Vai levar uns minutos até que sua verificação de integridade retorne um resultado positivo.

A saída vai ser algo semelhante a esta:

--- backend: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/networkEndpointGroups/k8s1-95c051f0-default-gb-frontend-svc-80-9b127192 status: healthStatus: - healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-00-27ced9534cde/zones/us-central1-a/instances/gke-test-cluster-default-pool-7e74f027-47qp ipAddress: 10.8.0.6 port: 80 kind: compute#backendServiceGroupHealth Observação: as verificações de integridade fazem parte do balanceador de carga do Google Cloud e são diferentes das sondagens de ativação e prontidão oferecidas pela API Kubernetes, que podem ser usadas para determinar a integridade de pods individuais. As verificações de integridade do balanceador de carga do Google Cloud usam rotas especiais fora da VPC do projeto ao serem realizadas para determinar o sucesso ou a falha de um back-end.

Depois que o estado de integridade de cada instância for relatado como ÍNTEGRA, será possível acessar o aplicativo por meio do IP externo.

7. Recupere com:

kubectl get ingress gb-frontend-ingress

8. Digitar o IP externo em uma janela do navegador vai carregar o aplicativo.

Clique em Verificar meu progresso para conferir o objetivo. Balanceamento de carga nativo de contêiner com uma entrada

Tarefa 2: teste de carga de um aplicativo

Entender a capacidade do seu aplicativo é importante para escolher solicitações e limites de recursos para os pods do aplicativo e decidir a melhor estratégia de escalonamento automático.

No início do laboratório, você implantou seu aplicativo como um pod único. Ao testar o aplicativo em execução em um pod único sem o escalonamento automático configurado, você vai saber quantas solicitações simultâneas ele pode processar, a quantidade de CPU e memória necessárias e como ele responde sob carga pesada.

Para fazer o teste de carga no pod, você vai usar o Locust, um framework de teste de carga de código aberto.

1. Faça o download dos arquivos de imagem do Docker para o Locust no Cloud Shell:

gsutil -m cp -r gs://spls/gsp769/locust-image .

Os arquivos no diretório locust-image informado incluem arquivos de configuração do Locust.

2. Crie a imagem do Docker para o Locust e armazene-a no Container Registry do seu projeto:

gcloud builds submit \ --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/locust-tasks:latest locust-image

3. Verifique se a imagem do Docker está no Container Registry do seu projeto:

gcloud container images list

Saída esperada:

O Locust consiste em uma máquina principal e diversas máquinas de trabalho para gerar carga.

4. Copiar e aplicar o manifesto vai criar uma implantação de pod único para a máquina principal e uma implantação de cinco réplicas para os workers:

gsutil cp gs://spls/gsp769/locust_deploy_v2.yaml . sed 's/${GOOGLE_CLOUD_PROJECT}/'$GOOGLE_CLOUD_PROJECT'/g' locust_deploy_v2.yaml | kubectl apply -f -

5. Para acessar a interface do Locust, recupere o endereço IP externo do serviço LoadBalancer correspondente:

kubectl get service locust-main

Se o valor do IP externo for <pending>, aguarde um minuto e execute o comando anterior de novo até que um valor válido seja exibido.

6. Em uma outra janela do navegador, acesse [ENDEREÇO_IP_EXTERNO]:8089 para abrir a página do Locust na Web:

Clique em Verificar meu progresso para conferir o objetivo. Teste de carga de um aplicativo

O Locust permite que você infeste seu aplicativo com muitos usuários simultâneos. É possível simular um tráfego ao inserir vários usuários gerados a uma determinada taxa.

7. Neste exemplo, para representar uma carga típica, digite 200 como o número de usuários a serem simulados e 20 como a taxa de geração.

8. Clique em Start swarming.

Após alguns segundos, o status será Running, com 200 usuários e cerca de 150 solicitações por segundo (RPS).

9. Passe para o console do Cloud e clique em Menu de navegação () > Kubernetes Engine.

10. Selecione Cargas de trabalho no painel à esquerda.

11. Depois clique no pod gb-frontend implantado.

A página de detalhes do pod vai aparecer. Nela, é possível conferir um gráfico da utilização da CPU e da memória do seu pod. Observe os valores usados e solicitados.

Observação: para conferir os valores das métricas listados abaixo do gráfico, clique nos três pontos na parte superior direita dele e selecione Expandir legenda do gráfico no menu suspenso.

Com o teste de carga atual, que é de cerca de 150 solicitações por segundo, o uso da CPU pode variar de 0,04 a 0,06. Isso representa 40 a 60% da solicitação de CPU de um pod. Por outro lado, a utilização da memória permanece em cerca de 80 Mi, bem abaixo dos 256 Mi solicitados. Essa é sua capacidade por pod. Essas informações serão úteis ao configurar o escalonador automático de clusters, as solicitações e os limites de recursos e escolher se e como implementar um escalonador automático de pods horizontal ou vertical.

Além de um valor de referência, considere o desempenho do aplicativo após bursts ou picos repentinos.

12. Retorne à janela do navegador do Locust e clique em Edit sob o status no topo da página.

13. Desta vez, digite 900 para o número de usuários a simular e 300 para a taxa de geração.

14. Clique em Start swarming.

Seu pod vai receber 700 solicitações adicionais repentinamente dentro de 2 a 3 segundos. Quando o valor do RPS atingir cerca de 150 e o status indicar 900 usuários, mude de volta para a página de detalhes do pod e observe a mudança nos gráficos.

Embora a memória permaneça igual, você vai notar que a CPU atingiu o pico em quase 0,07, ou seja, 70% da solicitação de CPU para o pod. Se o app fosse uma implantação, você poderia reduzir com segurança a solicitação de memória total e configurar o acionamento do escalonador automático horizontal de acordo com a utilização da CPU.

Tarefa 3: sondagens de prontidão e atividade

Como configurar uma sondagem de atividade

Se for configurada na especificação de pod ou na implantação do Kubernetes, uma sondagem de atividade será executada continuamente para detectar se um contêiner precisa de reinicialização e, se for o caso, acioná-la. Elas são úteis para reiniciar automaticamente aplicativos em impasse que ainda podem estar em execução. Por exemplo, um balanceador de carga gerenciado pelo Kubernetes (como um serviço) só enviaria tráfego para um back-end de pods se todos os contêineres passassem por uma sondagem de prontidão.

1. Para demonstrar uma sondagem de atividade, o código abaixo vai gerar um manifesto para um pod que tenha uma sondagem com base na execução do comando cat em um arquivo criado durante a criação:

cat << EOF > liveness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: liveness-probe name: liveness-demo-pod spec: containers: - name: liveness-demo-pod image: centos args: - /bin/sh - -c - touch /tmp/alive; sleep infinity livenessProbe: exec: command: - cat - /tmp/alive initialDelaySeconds: 5 periodSeconds: 10 EOF

2. Aplique o manifesto ao cluster para criar o pod:

kubectl apply -f liveness-demo.yaml

O valor initialDelaySeconds representa o tempo de espera para realização da primeira sondagem depois que o contêiner é iniciado. O valor periodSeconds indica a frequência de realização da sondagem.

Observação: os pods também podem ser configurados para incluir um startupProbe, que indica se o aplicativo no contêiner foi iniciado. Se um startupProbe estiver presente, nenhuma outra sondagem vai ser executada até retornar um estado Success. Isso é recomendável para aplicativos que podem ter tempos de inicialização variáveis, a fim de evitar interrupções de uma sondagem de atividade.

Nesse exemplo, a sondagem de atividade está verificando se o arquivo /tmp/alive existe no sistema de arquivos do contêiner.

3. É possível verificar a integridade do contêiner do pod analisando os eventos dele:

kubectl describe pod liveness-demo-pod

Na parte inferior da saída, há uma seção "Eventos" com os últimos cinco eventos do pod. Neste momento, os eventos do pod só podem incluir eventos relacionados à criação e inicialização:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 19s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 18s kubelet Pulling image "centos" Normal Pulled 18s kubelet Successfully pulled image "centos" Normal Created 18s kubelet Created container liveness-demo-pod Normal Started 18s kubelet Started container liveness-demo-pod

Esse log de eventos vai incluir todas as falhas na sondagem de atividade, bem como as reinicializações acionadas como resultado.

4. Faça a exclusão manual do arquivo usado pela sondagem de atividade:

kubectl exec liveness-demo-pod -- rm /tmp/alive

5. Com o arquivo removido, o comando cat usado pela sondagem de atividade deve retornar um código de saída diferente de zero.

6. Verifique os eventos do pod mais uma vez:

kubectl describe pod liveness-demo-pod

Quando a sondagem de atividade falhar, eventos serão adicionados ao registro, mostrando a série de etapas iniciadas. Ele vai começar com a falha da sondagem de atividade (Liveness probe failed: cat: /tmp/alive: No such file or directory) e terminar com a reinicialização do contêiner (Started container):

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m21s default-scheduler Successfully assigned default/liveness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Warning Unhealthy 36s (x3 over 56s) kubelet Liveness probe failed: cat: /tmp/alive: No such file or directory Normal Killing 36s kubelet Container liveness-demo-pod failed liveness probe, will be restarted Normal Pulling 6s (x2 over 2m20s) kubelet Pulling image "centos" Normal Pulled 6s (x2 over 2m20s) kubelet Successfully pulled image "centos" Normal Created 6s (x2 over 2m20s) kubelet Created container liveness-demo-pod Normal Started 6s (x2 over 2m20s) kubelet Started container liveness-demo-pod Observação: o exemplo deste laboratório usa uma sondagem de comando para livenessProbe que depende do código de saída de um comando especificado. Além de uma sondagem de comando, um livenessProbe pode ser configurado como uma sondagem HTTP que vai depender da resposta HTTP ou uma sondagem TCP que vai depender de uma conexão TCP poder ser feita em uma porta específica.

Como configurar uma sondagem de prontidão

Um pod pode ser iniciado e considerado íntegro por uma sondagem de atividade, mas é provável que ele não esteja pronto para receber tráfego imediatamente. Isso é comum para implantações que servem como back-end para um serviço como um balanceador de carga. Uma sondagem de prontidão é usada para determinar quando um pod e os contêineres dele estão prontos para receber tráfego.

1. Para demonstrar isso, faça um manifesto para criar um pod único que vai operar como um servidor de teste da Web com um balanceador de carga:

cat << EOF > readiness-demo.yaml apiVersion: v1 kind: Pod metadata: labels: demo: readiness-probe name: readiness-demo-pod spec: containers: - name: readiness-demo-pod image: nginx ports: - containerPort: 80 readinessProbe: exec: command: - cat - /tmp/healthz initialDelaySeconds: 5 periodSeconds: 5 --- apiVersion: v1 kind: Service metadata: name: readiness-demo-svc labels: demo: readiness-probe spec: type: LoadBalancer ports: - port: 80 targetPort: 80 protocol: TCP selector: demo: readiness-probe EOF

2. Aplique o manifesto ao cluster e crie um balanceador de carga com ele:

kubectl apply -f readiness-demo.yaml

3. Recupere o endereço IP externo atribuído ao balanceador de carga. Pode levar um minuto após o comando anterior para um endereço ser atribuído:

kubectl get service readiness-demo-svc

4. Digite o endereço IP em uma janela do navegador. Você vai notar uma mensagem de erro indicando que o site não pode ser acessado.

5. Verifique os eventos do pod:

kubectl describe pod readiness-demo-pod

A saída vai mostrar que a sondagem de prontidão falhou:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m24s default-scheduler Successfully assigned default/readiness-demo-pod to gke-load-test-default-pool-abd43157-rgg0 Normal Pulling 2m23s kubelet Pulling image "nginx" Normal Pulled 2m23s kubelet Successfully pulled image "nginx" Normal Created 2m23s kubelet Created container readiness-demo-pod Normal Started 2m23s kubelet Started container readiness-demo-pod Warning Unhealthy 35s (x21 over 2m15s) kubelet Readiness probe failed: cat: /tmp/healthz: No such file or directory

Ao contrário da sondagem de atividade, uma sondagem de prontidão que não é íntegra não faz com que o pod seja reinicializado.

6. Use o comando a seguir para gerar o arquivo que a sondagem de prontidão está procurando:

kubectl exec readiness-demo-pod -- touch /tmp/healthz

Agora a seção Conditions da descrição do pod deve mostrar True como o valor de Ready.

kubectl describe pod readiness-demo-pod | grep ^Conditions -A 5

Saída:

Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True

7. Atualize a guia do navegador que tinha o IP externo de readiness-demo-svc. Você verá a mensagem Welcome to nginx! exibida corretamente.

Definir sondagens de prontidão significativas para seus contêineres de aplicativos garante que os pods só recebam o tráfego quando estiverem prontos. Um exemplo de uma sondagem de prontidão significativa é verificar se um cache do seu aplicativo é carregado na inicialização.

Clique em Verificar meu progresso para conferir o objetivo. Sondagens de prontidão e atividade

Tarefa 4: orçamentos de interrupção de pods

Para garantir a confiabilidade e a atividade do seu aplicativo do GKE, é necessário aproveitar os orçamentos de interrupção de pods (PDB, na sigla em inglês). O PodDisruptionBudget é um recurso do Kubernetes que limita o número de pods de um aplicativo replicado que podem ser desativados de maneira simultânea devido a interrupções voluntárias.

As interrupções voluntárias incluem ações administrativas, como excluir uma implantação, atualizar o modelo de pod de uma implantação e executar uma atualização gradual, drenar nós em que os pods de um aplicativo residem ou mover pods para nós diferentes.

Primeiro, implante o aplicativo como uma implantação.

1. Exclua o app de pod único:

kubectl delete pod gb-frontend

2. E gere um manifesto que vai criá-lo como uma implantação de cinco réplicas:

cat << EOF > gb_frontend_deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: gb-frontend labels: run: gb-frontend spec: replicas: 5 selector: matchLabels: run: gb-frontend template: metadata: labels: run: gb-frontend spec: containers: - name: gb-frontend image: gcr.io/google-samples/gb-frontend-amd64:v5 resources: requests: cpu: 100m memory: 128Mi ports: - containerPort: 80 protocol: TCP EOF

3. Aplique esta implantação ao cluster:

kubectl apply -f gb_frontend_deployment.yaml

Clique em Verificar meu progresso para conferir o objetivo. Crie orçamentos de interrupção de pods

Antes de criar um PDB, você deve drenar os nós do cluster e observar o comportamento do aplicativo sem um PDB.

4. Drene os nós percorrendo a saída dos nós do default-pool e executando o comando kubectl drain em cada um deles:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --force --ignore-daemonsets --grace-period=10 "$node"; done

O comando acima vai remover pods do nó especificado e delimitar o nó para que nenhum pod novo seja criado nele. Se os recursos disponíveis permitirem, os pods serão reimplantados em um nó diferente.

5. Depois que o nó for drenado, verifique a contagem de réplicas da implantação gb-frontend:

kubectl describe deployment gb-frontend | grep ^Replicas

A saída vai ser algo semelhante a:

Replicas: 5 desired | 5 updated | 5 total | 0 available | 5 unavailable

Depois de drenar um nó, sua implantação pode não ter nenhuma réplica disponível, como indicado pela saída acima. Sem os pods disponíveis, seu aplicativo está desativado. Tente drenar os nós novamente, mas dessa vez com um orçamento de interrupção de pod em vigor para seu aplicativo.

6. Primeiro desmarque os nós drenados para recolocá-los. Com o comando abaixo, é possível programar pods em um nó novamente:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl uncordon "$node"; done

7. Verifique mais uma vez o status da sua implantação:

kubectl describe deployment gb-frontend | grep ^Replicas

A resposta será como esta, com todas as cinco réplicas disponíveis:

Replicas: 5 desired | 5 updated | 5 total | 5 available | 0 unavailable

8. Crie um orçamento de interrupção de pods que vai declarar o número mínimo de pods disponíveis como quatro:

kubectl create poddisruptionbudget gb-pdb --selector run=gb-frontend --min-available 4

9. Drene um dos nós do cluster mais uma vez e observe a saída:

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=default-pool -o=name); do kubectl drain --timeout=30s --ignore-daemonsets --grace-period=10 "$node"; done

Depois de remover um dos pods do aplicativo, ele vai retornar o seguinte:

evicting pod default/gb-frontend-597d4d746c-fxsdg evicting pod default/gb-frontend-597d4d746c-tcrf2 evicting pod default/gb-frontend-597d4d746c-kwvmv evicting pod default/gb-frontend-597d4d746c-6jdx5 error when evicting pod "gb-frontend-597d4d746c-fxsdg" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-tcrf2" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-6jdx5" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget. error when evicting pod "gb-frontend-597d4d746c-kwvmv" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

10. Pressione CTRL+C para sair do comando.

11. Verifique o status das suas implantações outra vez:

kubectl describe deployment gb-frontend | grep ^Replicas

A resposta será:

Replicas: 5 desired | 5 updated | 5 total | 4 available | 1 unavailable

Até que o Kubernetes consiga implantar um quinto pod em um nó diferente para remover o próximo, os pods restantes vão continuar disponíveis para aderir ao PDB. Neste exemplo, o orçamento de interrupção do pod foi configurado para indicar min-available, mas um PDB também pode ser configurado para definir um max-unavailable. Qualquer um dos valores pode ser expresso como um inteiro que representa uma contagem de pods ou uma porcentagem do total.

Parabéns!

Você aprendeu a criar um balanceador de carga nativo de contêiner com uma entrada para aproveitar um balanceamento de carga e um roteamento mais eficientes. Você realizou um teste de carga simples em um aplicativo do GKE e pôde conferir o uso básico de CPU e memória, bem como a resposta do aplicativo a picos de tráfego. Além disso, configurou sondagens de atividade e de prontidão com um orçamento de interrupção de pods para garantir a disponibilidade dos seus aplicativos. Em conjunto, essas ferramentas e técnicas contribuem para a eficiência geral do funcionamento do seu aplicativo no GKE, minimizando o tráfego externo à rede, definindo indicadores significativos de um aplicativo com comportamento adequado e melhorando a disponibilidade do aplicativo.

Próximas etapas / Saiba mais

Confira estes recursos para saber mais sobre os tópicos deste laboratório:

• Práticas recomendadas para executar aplicativos econômicos do Kubernetes no GKE: Preparar aplicativos do Kubernetes baseados em nuvem

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 março de 2024

Laboratório testado em 12 de março de 2024

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.