Percurso de aprendizagem: aplicações escaláveis – Escalabilidade

Autopilot

---

Este conjunto de tutoriais destina-se a administradores de TI e operadores que querem implementar, executar e gerir ambientes de aplicações modernos que são executados no Google Kubernetes Engine (GKE). À medida que avança neste conjunto de tutoriais, vai aprender a configurar a monitorização e os alertas, dimensionar cargas de trabalho e simular falhas, tudo isto usando a aplicação de microsserviços de exemplo do Cymbal Bank:

1. Crie um cluster e implemente uma aplicação de exemplo
2. Monitorize com o serviço gerido do Google Cloud para Prometheus
3. Escalar cargas de trabalho (este tutorial)
4. Simule uma falha
5. Centralize a gestão da mudança

Vista geral e objetivos

Uma aplicação de consumidor, como o Cymbal Bank, tem frequentemente um número variável de utilizadores em diferentes momentos. Idealmente, o seu Website deve conseguir lidar com picos de tráfego sem ficar mais lento nem ter outros problemas, mas sem que a organização tenha de gastar dinheiro em recursos da nuvem de que não precisa realmente. Uma solução que Google Cloud permite isto é o dimensionamento automático.

Neste tutorial, vai aprender a configurar clusters e cargas de trabalho num cluster do GKE para dimensionar através de métricas do Kubernetes incorporadas e métricas personalizadas do Cloud Monitoring e Cloud Trace. Aprende a concluir as seguintes tarefas:

• Ative as métricas personalizadas no Cloud Monitoring para o Trace.
  • As métricas personalizadas permitem-lhe dimensionar através de dados de monitorização adicionais ou entradas externas para além da perceção do cluster do Kubernetes, como o tráfego de rede ou os códigos de resposta HTTP.
• Configure o Horizontal Pod Autoscaler, uma funcionalidade do GKE que pode aumentar ou diminuir automaticamente o número de pods para uma carga de trabalho, consoante as métricas especificadas.
• Simule a carga da aplicação e veja a resposta do redimensionador automático de cluster e da escala automática horizontal de pods.

Custos

A ativação do GKE e a implementação da aplicação de exemplo do Cymbal Bank para esta série de tutoriais significa que incorre em custos por cluster para o GKE on Google Cloud , conforme indicado na nossa página de preços, até desativar o GKE ou eliminar o projeto.

Também é responsável por outros Google Cloud custos incorridos durante a execução da aplicação de exemplo do Cymbal Bank, como encargos de VMs do Compute Engine e do Trace.

Antes de começar

Para saber como dimensionar as suas implementações, tem de concluir o primeiro tutorial para criar um cluster do GKE que use o Autopilot e implementar a aplicação baseada em microsserviços de exemplo do Cymbal Bank.

Recomendamos que conclua este conjunto de tutoriais para apps escaláveis por ordem. À medida que avança no conjunto de tutoriais, aprende novas competências e usa produtos e serviços Google Cloud adicionais.

Também tem de criar uma conta de serviço do IAM e conceder algumas autorizações para que o redimensionador automático horizontal de pods funcione corretamente:

1. Crie uma conta de serviço do IAM. Esta conta de serviço é usada no tutorial para conceder acesso a métricas personalizadas que permitem ao HorizontalPodAutoscaler determinar quando aumentar ou diminuir a escala:

   gcloud iam service-accounts create scalable-apps
   

2. Conceda acesso à conta de serviço do IAM para realizar as ações de escalabilidade necessárias:

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --role roles/cloudtrace.agent \
     --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
     --role roles/monitoring.metricWriter \
     --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com"
   
   gcloud iam service-accounts add-iam-policy-binding "scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \
     --role roles/iam.workloadIdentityUser \
     --member "serviceAccount:PROJECT_ID.svc.id.goog[default/default]"
   

   O seguinte acesso é concedido à conta de serviço do IAM:

   • roles/cloudtrace.agent: escreva dados de rastreio, como informações de latência, no rastreio.
   • roles/monitoring.metricWriter: escrever métricas no Cloud Monitoring.
   • roles/iam.workloadIdentityUser: Permitir que uma conta de serviço do Kubernetes use a federação de identidades da carga de trabalho para o GKE para atuar como a conta de serviço do IAM.

3. Configure a conta de serviço do Kubernetes no espaço de nomes default para atuar como a conta de serviço da IAM que criou:default

   kubectl annotate serviceaccount default \
       iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
   

   Esta configuração permite que os pods que usam a conta de serviço do Kubernetes no espaço de nomes default acedam aos mesmos recursos que a conta de serviço do IAM.default Google Cloud

Configure a recolha de métricas personalizadas

Pode configurar o Horizontal Pod Autoscaler para usar métricas básicas incorporadas do Kubernetes de CPU e memória, ou pode usar métricas personalizadas do Cloud Monitoring, como pedidos HTTP por segundo ou a quantidade de declarações SELECT. As métricas personalizadas podem funcionar sem alterações à aplicação e dão ao seu cluster mais informações sobre o desempenho geral e as necessidades da aplicação. Neste tutorial, vai aprender a usar as métricas incorporadas e personalizadas.

1. Para permitir que o Horizontal Pod Autoscaler leia métricas personalizadas do Monitoring, tem de instalar o adaptador Custom Metrics - Stackdriver Adapter no seu cluster.

   Implemente o adaptador de métricas personalizadas do Stackdriver no seu cluster:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml
   

2. Para permitir que o adaptador do Stackdriver obtenha métricas personalizadas do seu cluster, usa a Workload Identity Federation para o GKE. Esta abordagem usa uma conta de serviço do IAM que tem autorizações para ler métricas de monitorização.

   Conceda à conta de serviço IAM a função roles/monitoring.viewer

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \
       --role roles/monitoring.viewer
   

3. Configure o adaptador do Stackdriver para usar a Workload Identity Federation para o GKE e a conta de serviço do IAM que tem autorizações para ler as métricas de monitorização:

   gcloud iam service-accounts add-iam-policy-binding scalable-apps@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/iam.workloadIdentityUser \
       --member "serviceAccount:PROJECT_ID.svc.id.goog[custom-metrics/custom-metrics-stackdriver-adapter]"
   

4. O Kubernetes inclui o seu próprio sistema de contas de serviço para acesso num cluster. Para permitir que as suas aplicações se autentiquem em serviços e recursos fora dos seus clusters do Google Kubernetes Engine, como o Monitoring, usa a Workload Identity Federation para o GKE. Esta abordagem configura a conta de serviço do Kubernetes para usar a conta de serviço do IAM para o GKE.

   Anotar a conta de serviço do Kubernetes que o adaptador usa:

   kubectl annotate serviceaccount custom-metrics-stackdriver-adapter \
       --namespace=custom-metrics \
       iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
   

5. Reinicie a implementação do adaptador do Stackdriver para aplicar as alterações:

   kubectl rollout restart deployment custom-metrics-stackdriver-adapter \
       --namespace=custom-metrics
   

Objetivo: parabéns! Agora, tem um adaptador do Stackdriver no cluster do GKE configurado para ler métricas personalizadas do Monitoring.

Configure o redimensionador automático horizontal de pods

O GKE Autopilot pode ser dimensionado de várias formas diferentes. Neste tutorial, vai ver como o cluster pode ser dimensionado através dos seguintes métodos:

• Redimensionador automático horizontal de pods: dimensiona o número de pods para uma carga de trabalho.
• Redimensionador automático de clusters: dimensiona os recursos de nós disponíveis no cluster.

Estes dois métodos podem funcionar em conjunto para que, à medida que o número de pods das suas aplicações muda, os recursos dos nós para suportar esses pods também mudem.

Estão disponíveis outras implementações para dimensionar pods que se baseiam no redimensionador automático horizontal de pods, e também pode usar o redimensionador automático vertical de pods para ajustar os pedidos de CPU e memória de um pod em vez do número de pods.

Neste tutorial, vai configurar o Horizontal Pod Autoscaler para a implementação userservice usando métricas incorporadas e para a implementação frontend usando métricas personalizadas.

Para as suas próprias aplicações, trabalhe com os programadores de aplicações e os engenheiros de plataforma para compreender as respetivas necessidades e configurar as regras do Horizontal Pod Autoscaler.

Dimensione a userservice implementação

Quando o número de utilizadores da aplicação de exemplo do Cymbal Bank aumenta, o serviço userservice consome mais recursos da CPU. Usa um objeto HorizontalPodAutoscaler para controlar a forma como quer que a sua aplicação responda ao carregamento. No manifesto YAML para o HorizontalPodAutoscaler, define a implementação para a qual o redimensionador automático horizontal de pods deve ser dimensionado, as métricas a monitorizar e o número mínimo e máximo de réplicas que quer executar.

1. Reveja o HorizontalPodAutoscalermanifesto de exemplo para a userservice implementação:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #      http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: userservice
   spec:
     behavior:
       scaleUp:
         stabilizationWindowSeconds: 0
         policies:
           - type: Percent
             value: 100
             periodSeconds: 5
         selectPolicy: Max
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: userservice
     minReplicas: 5
     maxReplicas: 50
     metrics:
       - type: Resource
         resource:
           name: cpu
           target:
             type: Utilization
             averageUtilization: 60
   

   Este manifesto faz o seguinte:

   • Define o número máximo de réplicas durante um aumento para 50.
   • Define o número mínimo de durante uma redução para 5.
   • Usa uma métrica do Kubernetes integrada para tomar decisões de escalabilidade. Neste exemplo, a métrica é a utilização da CPU e a utilização alvo é de 60%, o que evita a utilização excessiva e insuficiente.

2. Aplique o manifesto ao cluster:

   kubectl apply -f extras/postgres-hpa/hpa/userservice.yaml
   

Dimensione a frontend implementação

Na secção anterior, configurou a escala automática horizontal de pods na implementação com base nas métricas incorporadas do Kubernetes para a utilização da CPU.userservice Para a implementação frontend, é recomendável dimensionar com base no número de pedidos HTTP recebidos. Esta abordagem usa o adaptador do Stackdriver para ler métricas personalizadas do Monitoring para o objeto de entrada do balanceador de carga HTTP(S).

1. Reveja o HorizontalPodAutoscalermanifesto para a frontendimplementação:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #      http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: frontend
   spec:
     behavior:
       scaleUp:
         stabilizationWindowSeconds: 0
         policies:
           - type: Percent
             value: 100
             periodSeconds: 5
         selectPolicy: Max
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: frontend
     minReplicas: 5
     maxReplicas: 25
     metrics:
       - type: External
         external:
           metric:
             name: loadbalancing.googleapis.com|https|request_count
             selector:
               matchLabels:
                 resource.labels.forwarding_rule_name: FORWARDING_RULE_NAME
           target:
             type: AverageValue
             averageValue: "5"
   

   Este manifesto usa os seguintes campos:

   • spec.scaleTargetRef: o recurso do Kubernetes a dimensionar.
   • spec.minReplicas: o número mínimo de réplicas, que é 5 neste exemplo.
   • spec.maxReplicas: o número máximo de réplicas, que é 25 neste exemplo.
   • spec.metrics.*: a métrica a usar. Neste exemplo, este é o número de pedidos HTTP por segundo, que é uma métrica personalizada da monitorização fornecida pelo adaptador que implementou.
   • spec.metrics.external.metric.selector.matchLabels: a etiqueta de recurso específica a filtrar ao ajustar a escala.

2. Encontre o nome da regra de encaminhamento no balanceador de carga do Ingress:frontend

   export FW_RULE=$(kubectl get ingress frontend -o=jsonpath='{.metadata.annotations.ingress\.kubernetes\.io/forwarding-rule}')
   echo $FW_RULE
   

   O resultado é semelhante ao seguinte:

   k8s2-fr-j76hrtv4-default-frontend-wvvf7381
   

3. Adicione a regra de encaminhamento ao manifesto:

   sed -i "s/FORWARDING_RULE_NAME/$FW_RULE/g" "extras/postgres-hpa/hpa/frontend.yaml"
   

   Este comando substitui FORWARDING_RULE_NAME pela regra de encaminhamento guardada.

4. Aplique o manifesto ao cluster:

   kubectl apply -f extras/postgres-hpa/hpa/frontend.yaml
   

Objetivo: parabéns! Agora, tem regras do Horizontal Pod Autoscaler configuradas para implementações no seu cluster do GKE através de métricas incorporadas do Kubernetes e métricas personalizadas do Monitoring.

Simule o carregamento

Nesta secção, usa um gerador de carga para simular picos no tráfego e observar o aumento do número de réplicas e do número de nós para acomodar o aumento da carga ao longo do tempo. Em seguida, pode parar de gerar tráfego e observar a redução da escala da réplica e da contagem de nós em resposta.

1. Antes de começar, verifique o estado do redimensionador automático horizontal de pods e consulte o número de réplicas em utilização.

   Obtenha o estado dos seus recursos HorizontalPodAutoscaler:

   kubectl get hpa
   

   O resultado é semelhante ao seguinte, que mostra que existem 1 réplica frontend e 5 réplicas userservice:

   NAME                     REFERENCE                            TARGETS             MINPODS   MAXPODS   REPLICAS   AGE
   frontend                 Deployment/frontend                  <unknown>/5 (avg)   5         25        1          34s
   userservice              Deployment/userservice               0%/60%              5         50        5          4m56s
   

2. A aplicação de exemplo do Cymbal Bank inclui um serviço loadgenerator. Este serviço envia continuamente pedidos que imitam utilizadores para o front-end e cria periodicamente novas contas e simula transações entre elas.

   Exponha a interface Web loadgenerator localmente. Use esta interface para simular a carga na aplicação de exemplo do Cymbal Bank:

   kubectl port-forward svc/loadgenerator 8080
   

   Se vir uma mensagem de erro, tente novamente quando o Pod estiver em funcionamento.

3. Num navegador no computador, abra a interface Web do gerador de carga:

   • Se estiver a usar uma shell local, abra um navegador e aceda a http://127.0.0.1:8080.
   • Se estiver a usar o Cloud Shell, clique em Pré-visualização Web e, de seguida, clique em Pré-visualizar na porta 8080.

4. Na interface Web do gerador de carga, se o valor Falhas apresentar 100%, conclua os seguintes passos para atualizar as definições de teste:

   1. Clique no botão Parar junto ao contador da taxa de falhas.
   2. Em Estado, clique na opção Novo teste.
   3. Atualize o valor Host para o endereço IP da entrada do Cymbal Bank.
   4. Clique em Iniciar enxame.

5. Na interface Web do gerador de carga, clique no separador Gráficos para observar o desempenho ao longo do tempo. Analise o número de pedidos e a utilização de recursos.

6. Abra uma nova janela de terminal e monitorize a contagem de réplicas dos seus pods frontend e userservice:

   kubectl get hpa -w
   

   O número de réplicas aumenta à medida que a carga aumenta. As ações scaleUp podem demorar aproximadamente dez minutos, uma vez que o cluster reconhece que as métricas configuradas atingem o limite definido e usa o Horizontal Pod Autoscaler para aumentar o número de pods.

   O exemplo de saída seguinte mostra que o número de réplicas aumentou à medida que o gerador de carga é executado:

   NAME                     REFERENCE                            TARGETS          MINPODS   MAXPODS   REPLICAS
   frontend                 Deployment/frontend                  5200m/5 (avg)    5         25        13
   userservice              Deployment/userservice               71%/60%          5         50        17
   

7. Abra outra janela de terminal e verifique o número de nós no cluster:

   gcloud container clusters list \
       --filter='name=scalable-apps' \
       --format='table(name, currentMasterVersion, currentNodeVersion, currentNodeCount)' \
       --location="CONTROL_PLANE_LOCATION"
   

   Substitua CONTROL_PLANE_LOCATION pela localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.

   O número de nós também aumentou da quantidade inicial para acomodar as novas réplicas. Este aumento no número de nós é baseado no GKE Autopilot. Não tem de configurar nada para esta escala de nós.

8. Abra a interface do gerador de carga e clique em Parar para terminar o teste.

9. Verifique novamente a quantidade de réplicas e a quantidade de nós e observe à medida que os números diminuem com a carga reduzida. A redução pode demorar algum tempo, uma vez que o período de estabilização predefinido para réplicas no recurso HorizontalPodAutoscaler do Kubernetes é de cinco minutos.

Num ambiente real, o número de nós e pods no seu ambiente seria automaticamente aumentado e diminuído da mesma forma que com esta carga simulada. A aplicação de exemplo do Cymbal Bank foi concebida para se adaptar a este tipo de dimensionamento. Consulte os operadores da app e a equipa de engenharia de fiabilidade do site (SRE) ou os programadores de aplicações para ver se as respetivas cargas de trabalho podem beneficiar destas funcionalidades de escalabilidade.

Objetivo: parabéns! Agora, pode configurar o GKE para ser dimensionado com base na carga, incluindo a utilização de métricas personalizadas do Monitoring.

Limpar

O conjunto de tutoriais para o Cymbal Bank foi concebido para ser concluído um após o outro. À medida que avança no conjunto de tutoriais, aprende novas competências e usa Google Cloud produtos e serviços adicionais.

Se quiser fazer uma pausa antes de avançar para o tutorial seguinte e evitar incorrer em custos na sua Google Cloud conta pelos recursos usados neste tutorial Google Cloud , elimine o projeto que criou.

Atenção: a eliminação de um projeto tem os seguintes efeitos:

• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.

Se planeia explorar várias arquiteturas, tutoriais ou inícios rápidos, a reutilização de projetos pode ajudar a evitar exceder os limites de quota de projetos.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

O que se segue?

Saiba como simular uma falha no GKE no próximo tutorial.