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

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

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

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 baseados na escala automática horizontal de pods, e também pode usar a escala automática 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 frontend implementação, é 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

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.