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

A escalabilidade descreve a capacidade de um aplicativo ou sistema de lidar com uma quantidade crescente de trabalho adicionando mais recursos a ele.

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

Vertical scaling diagram.

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 dimensionamento, refere-se ao dimensionamento de um sistema duplicando o aplicativo e equilibrando a carga entre as instâncias do aplicativo.

Horizontal scaling diagram.

O dimensionamento horizontal é valioso para aplicativos distribuídos, como aqueles implantados no AKS, e sistemas sem monitoração de estado, já que você pode girar vários contêineres com o mesmo aplicativo em uma única VM. A expansão permite extrair a maioria dos recursos enquanto paga por uma única VM.

Em nosso cenário de exemplo, o site da sua empresa é sem monitoração de estado. Isso significa que a expansão é o melhor curso de ação. O Kubernetes fornece pronto para uso um recurso chamado HorizontalPodAutoscaler (HPA) que permite dimensionar 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 spec.replicas chave 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 kubectl scale deploy/contoso-website --replicas <number> comando. Esse comando altera dinamicamente o número de réplicas desejadas em uma implantação e dimensiona o aplicativo 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 gerenciador do controlador, que gerencia objetos HPA, dimensionará ou reduzirá a implantação.

HorizontalPodAutoscaling design diagram.

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

Cada HPA é anexado a uma referência de escala, que é definida na chave do manifesto spec.scaleTargetRef 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 spec.template.spec.containers[].resources chave 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 o seu conhecimento

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 aplicativos sem monitoração de estado?