Conceitos de escalabilidade

  • 5 minutos

Antes de encontrar uma solução de dimensionamento, você precisa entender o que é escalabilidade e como ela se aplica aos aplicativos Kubernetes.

Nesta unidade, analisamos alguns conceitos de escalabilidade.

Escalabilidade

Escalabilidade descreve a capacidade de um aplicativo ou sistema de gerir uma quantidade crescente de trabalho através da adição de mais recursos.

Em nosso cenário de exemplo, a quantidade de trabalho que experimenta um aumento é o número de solicitações de clientes. A quantidade de recursos adicionados pode ser representada de duas maneiras: escalabilidade vertical e escalabilidade horizontal.

Escalabilidade vertical

Escalabilidade vertical, ou escalonamento de , refere-se ao dimensionamento de um sistema adicionando mais recursos físicos, como memória ou energia da CPU. Por exemplo, se o site da sua empresa consome muita memória, você pode atualizar sua instância de VM para incluir mais memória, mantendo o mesmo aplicativo subjacente.

Diagrama de escala vertical.

Em resumo, o dimensionamento vertical envolve o aumento do tamanho da VM, mantendo o mesmo número de aplicativos. Essa abordagem é valiosa se você tiver aplicativos monolíticos que exigem muito poder de computação, mas são muito caros para serem divididos em partes menores. Esses aplicativos são hospedados principalmente em VMs, em oposição a sistemas distribuídos.

Apesar de um custo mais gerenciável, VMs muito grandes podem se tornar muito caras. O custo de adicionar mais poder de computação é maior do que o custo da duplicação de pequenas VMs. Há um limite superior para o número de recursos que você pode adicionar a uma única VM, o que significa que você deve eventualmente duplicar a VM quando atingir o limite superior.

Escalabilidade horizontal

Escalabilidade horizontal, ou scaling out, refere-se ao dimensionamento de um sistema duplicando a aplicação e balanceando a carga entre as instâncias da aplicação.

Diagrama de escala horizontal.

O dimensionamento horizontal é valioso para aplicações distribuídas, como as implantadas no AKS, e sistemas sem estado, já que é possível iniciar vários contentores com a mesma aplicação numa única VM. A expansão permite extrair a maioria dos recursos enquanto paga por uma única VM.

No nosso cenário de exemplo, o site da sua empresa é sem estado. Isso significa que a expansão é o melhor curso de ação. Kubernetes fornece de forma nativa um recurso chamado HorizontalPodAutoscaler (HPA) que lhe permite escalonar as suas implantações.

Escalabilidade manual no Kubernetes

Antes de abordarmos o HPA, vamos analisar como dimensionar um aplicativo Kubernetes manualmente.

Cada implantação está vinculada a outro recurso chamado ReplicaSet. Um ReplicaSet é responsável por manter um "estado de réplica desejado" e dimensionar o aplicativo real para dentro ou para fora para manter o estado desejado igual ao estado real. Você pode controlar o número de réplicas em uma implantação por meio da chave spec.replicas na especificação de implantação. Essa chave define o número de réplicas desejadas no ReplicaSet subjacente e força o controlador de replicação a manter esse número de réplicas a qualquer momento.

Você também pode controlar o número de réplicas em uma implantação com o comando kubectl scale deploy/contoso-website --replicas <number>. Este comando altera dinamicamente o número de réplicas desejadas em uma implementação e dimensiona a aplicação para dentro ou para fora.

HorizontalPodAutoscaler (HPA)

O HPA é o recurso nativo do Kubernetes 1.8+ que fornece escalabilidade horizontal para pods no cluster. Ele monitora a API de métricas a cada 30 segundos para quaisquer alterações na contagem de réplicas desejada. Se a contagem de réplicas desejada for diferente da contagem de réplicas atual, o gestor do controlador, que gere objetos HPA, escalará a implementação, aumentando ou diminuindo o número de réplicas.

diagrama de design HorizontalPodAutoscaling.

Os HPAs trabalham com o grupo de API autoscaling no Kubernetes. Há duas versões para esse grupo de APIs: v1 e v2. A versão v1 permite que a implantação seja dimensionada com base apenas em métricas de CPU. A versão v2 permite o monitoramento nativo da CPU e da memória. Neste módulo, usamos a versão v2.

Cada HPA está associado a uma referência de escala , que é definida na chave spec.scaleTargetRef do manifesto HPA. Essa referência de escala deve ter pods subjacentes para serem dimensionados, caso contrário, o HPA não funciona, já que não é possível aplicar dimensionamento a objetos que não podem ser dimensionados, como DaemonSets.

É importante que cada pod tenha uma solicitação de recurso definida em suas especificações. O algoritmo HPA não pode calcular corretamente as métricas e determinar a utilização de recursos sem essa configuração. Você pode definir esse limite por meio da chave spec.template.spec.containers[].resources no manifesto de implantação, conforme mostrado no exemplo a seguir:

spec:
  template:
    spec:
      containers:
        - resources:
            requests:
              cpu: 250m
              memory: 256M
            limits:
              cpu: 500m
              memory: 512M

Exemplo de manifesto HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Verifique os seus conhecimentos

1.

O que é o dimensionamento horizontal?

2.

Por que é importante ter uma solicitação de recurso definida em pods vinculados a um HPA?

3.

Por que o dimensionamento vertical é menos recomendado para aplicações sem estado?