Programa de aprendizado: aplicativos escalonáveis - escalonamento

Este conjunto de tutoriais é destinado a administradores e operadores de TI que querem implantar, executar e gerenciar ambientes de aplicativos modernos executados no Google Kubernetes Engine (GKE). À medida que avança neste conjunto de tutoriais, você aprende a configurar o monitoramento e alertas, escalonar cargas de trabalho e simular falhas. Tudo isso usando o aplicativo de microsserviços de exemplo Cymbal Bank:

  1. Criar um cluster e implantar um aplicativo de exemplo
  2. Monitorar com o Google Cloud Managed Service para Prometheus
  3. Escalonar cargas de trabalho (este tutorial)
  4. Simular uma falha
  5. Centralizar a gestão da mudança

Visão geral e objetivos

Um aplicativo de consumo, como o Cymbal Bank, geralmente tem números variáveis de usuários em momentos diferentes. O ideal é que seu site seja capaz de lidar com aumentos de tráfego sem desacelerar nem ter outros problemas, mas sem que a organização precise gastar em recursos do Cloud que não são necessários. Uma solução que oGoogle Cloud oferece para isso é o escalonamento automático.

Neste tutorial, você vai aprender a configurar clusters e cargas de trabalho em um cluster do GKE para escalonamento usando métricas integradas do Kubernetes e métricas personalizadas do Cloud Monitoring e do Cloud Trace. Você aprenderá a concluir as seguintes tarefas:

  • Ativar métricas personalizadas no Cloud Monitoring para Trace.
    • Com as métricas personalizadas, é possível escalonar usando dados de monitoramento adicionais ou entradas além do conhecimento do cluster do Kubernetes, como tráfego de entrada ou códigos de resposta HTTP.
  • Configure o escalonador automático de pod horizontal, um recurso do GKE que pode aumentar ou diminuir automaticamente o número de pods de uma carga de trabalho, dependendo das métricas especificadas.
  • Simule a carga do aplicativo e confira a resposta do escalonador automático de cluster e do escalonador automático horizontal de pods.

Configurar a coleta de métricas personalizadas

É possível configurar o escalonador automático de pod horizontal para usar métricas básicas de CPU e memória integradas do Kubernetes ou métricas personalizadas do Cloud Monitoring, como solicitações HTTP por segundo ou a quantidade de instruções SELECT. As métricas personalizadas funcionam sem alterações no aplicativo e dão ao cluster mais insights sobre o desempenho geral e as necessidades do aplicativo. Neste tutorial, você vai aprender a usar as métricas integradas e personalizadas.

  1. Para permitir que o escalonador automático horizontal de pods leia métricas personalizadas do Monitoring, instale o adaptador Adaptador de métricas personalizadas do Stackdriver no cluster.

    Implante o adaptador de métricas personalizadas do Stackdriver no 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 receba métricas personalizadas do cluster, use a federação de identidade da carga de trabalho para GKE. Essa abordagem usa uma conta de serviço do IAM com permissões para ler métricas de monitoramento.

    Conceda à conta de serviço do IAM o papel 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 federação de identidade da carga de trabalho para o GKE e a conta de serviço do IAM que tem permissões para ler métricas de monitoramento:

    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 próprio sistema de contas de serviço para acesso em um cluster. Para permitir que seus aplicativos se autentiquem em serviços e recursos fora dos clusters do Google Kubernetes Engine, como o Monitoring, use a federação de identidade da carga de trabalho para GKE. Essa abordagem configura a conta de serviço do Kubernetes para usar a conta de serviço do IAM para o GKE.

    Anote 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 implantação do adaptador do Stackdriver para aplicar as alterações:

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

Configurar o escalonador automático horizontal de pods

O Autopilot do GKE pode ser escalonado de algumas maneiras diferentes. Neste tutorial, você vai aprender a escalonar o cluster usando estes métodos:

  • Escalonador automático horizontal de pods: dimensiona o número de pods para uma carga de trabalho.
  • Escalonador automático de cluster: escalona os recursos do nó que estão disponíveis no cluster.

Esses dois métodos podem trabalhar juntos para que, à medida que o número de pods dos seus aplicativos muda, os recursos de nó para oferecer suporte a esses pods também mudem.

Outras implementações estão disponíveis para escalonar pods que são criados com base no escalonamento automático de pods horizontal. Você também pode usar o escalonamento automático de pods vertical para ajustar as solicitações de CPU e memória de um pod em vez do número de pods.

Neste tutorial, vamos configurar o Escalonador automático horizontal de pods para a implantação de userservice usando métricas integradas e para a implantação de frontend usando métricas personalizadas.

Para seus próprios aplicativos, trabalhe com seus desenvolvedores de aplicativos e engenheiros de plataforma para entender as necessidades e configurar as regras do escalonar automático horizontal de pods.

Escalonar a implantação userservice

Quando o número de usuários do aplicativo de exemplo do Cymbal Bank aumenta, o serviço userservice consome mais recursos de CPU. Você usa um objeto HorizontalPodAutoscaler para controlar como quer que seu aplicativo responda ao carregamento. No manifesto YAML do HorizontalPodAutoscaler, você define qual implantação para o escalonador automático horizontal de pods escalonar, quais métricas serão monitoradas e os números mínimo e máximo de réplicas que você quer executar.

  1. Analise o exemplo de manifesto HorizontalPodAutoscaler da implantação userservice:

    # 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

    Esse manifesto faz o seguinte:

    • Define o número máximo de réplicas durante um escalonamento vertical como 50.
    • Define o número mínimo de durante uma redução de escala como 5.
    • Usa uma métrica integrada do Kubernetes para tomar decisões de escalonamento. Nesta amostra, a métrica é a utilização da CPU e a utilização de destino é 60%, o que evita o uso excessivo e insuficiente.

  2. Aplique o manifesto ao cluster:

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

Escalonar a implantação frontend

Na seção anterior, você configurou o escalonador automático de pods horizontal na implantação userservice com base nas métricas integradas do Kubernetes para a utilização da CPU. Para a implantação frontend, talvez seja melhor escalonar com base no número de solicitações HTTP recebidas. Essa 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. Revise o manifesto HorizontalPodAutoscaler da implantação frontend:

    # 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"

    Esse manifesto usa os seguintes campos:

    • spec.scaleTargetRef: o recurso do Kubernetes a ser escalonado.
    • spec.minReplicas: o número mínimo de réplicas, que é 5 nessa amostra.
    • spec.maxReplicas: o número máximo de réplicas, que é 25 nessa amostra.
    • spec.metrics.*: a métrica a ser usada. Nesta amostra, esse é o número de solicitações HTTP por segundo, que é uma métrica personalizada do Monitoring fornecida pelo adaptador implantado.
    • spec.metrics.external.metric.selector.matchLabels: o rótulo de recursos específico a ser filtrado ao fazer o escalonamento.

  2. Encontre o nome da regra de encaminhamento na carga de entrada frontend do balanceador de carga:

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

    O resultado será assim:

    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"

    Esse comando substitui FORWARDING_RULE_NAME pela regra de encaminhamento salva.

  4. Aplique o manifesto ao cluster:

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

Simular carga

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

  1. Antes de começar, verifique o status do escalonador automático horizontal de pods e confira o número de réplicas em uso.

    Verifique o estado dos recursos HorizontalPodAutoscaler:

    kubectl get hpa

    A saída é semelhante à seguinte, que mostra que há 1 réplica frontend e 5 réplicas de 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. O aplicativo de exemplo do Cymbal Bank inclui um serviço loadgenerator. Esse serviço envia continuamente solicitações que imitam usuários para o front-end, cria novas contas periodicamente e simula transações entre elas.

    Exponha a interface da Web loadgenerator localmente. Você usa essa interface para simular a carga no aplicativo de amostra do Cymbal Bank:

    kubectl port-forward svc/loadgenerator 8080

    Se uma mensagem de erro for exibida, tente novamente quando o pod estiver em execução.

  3. Em um navegador no computador, abra a interface da Web do gerador de carga:

    • Se você estiver usando um shell local, abra um navegador e acesse http://127.0.0.1:8080.
    • Se você estiver usando o Cloud Shell, clique em Visualização na Web e, em seguida, clique em Visualizar na porta 8080.

  4. Na interface da Web do gerador de carga, se o valor Falhas mostrar 100%, siga estas etapas para atualizar as configurações do teste:

    1. Clique no botão Parar ao lado do contador de taxa de falha.
    2. Em Status, clique na opção Novo teste.
    3. Atualize o valor Host para o endereço IP da entrada do Cymbal Bank.
    4. Clique em Start swarming.

  5. Na interface da Web do gerador de carga, clique na guia Gráficos para observar o desempenho ao longo do tempo. Analise o número de solicitações e utilização de recursos.

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

    kubectl get hpa -w

    O número de réplicas aumenta conforme a carga aumenta. As ações de scaleUp podem levar aproximadamente dez minutos até que o cluster reconhece que as métricas configuradas alcançam o limite definido e use o escalonador automático para escalonar verticalmente o número de pods.

    O exemplo de saída a seguir mostra que o número de réplicas aumentou durante a execução do gerador de carga:

    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 do 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 pelo local do Compute Engine do plano de controle do cluster. Forneça 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. Esse aumento no número de nós é feito com a tecnologia do Autopilot do GKE. Não há nada que você precise configurar para essa escala de nós.

  8. Abra a interface do gerador de carga e clique em Parada para finalizar o teste.

  9. Verifique a contagem de réplicas e a contagem de nós novamente e observe como os números são reduzidos com a carga reduzida. A redução da escala pode levar algum tempo, porque a janela de estabilização padrão para réplicas no recurso HorizontalPodAutoscaler do Kubernetes é de cinco minutos.

Em um ambiente real, o número de nós e pods no seu ambiente escalona verticalmente, da mesma forma que ocorre com a carga dessa simulação. O aplicativo de exemplo do Cymbal Bank foi projetado para acomodar esse tipo de escalonamento. Verifique com os operadores de apps e a engenharia de confiabilidade do site (SRE) ou os desenvolvedores de aplicativos se as cargas de trabalho podem se beneficiar desse escalonamento de atributos.