Dimensionamento (para baixo) do Kubernetes: Combinação de dimensionadores automáticos

TL;DR: neste artigo, você aprenderá a dimensionar proativamente suas cargas de trabalho antes de um pico de tráfego usando o KEDA e o dimensionador cron.

Ao projetar um cluster do Kubernetes, talvez você precise responder a perguntas como:

• Quanto tempo leva para o cluster ser dimensionado?
• Quanto tempo devo esperar para que um novo pod seja criado?

Há quatro fatores significativos que afetam o dimensionamento:

• Tempo de reação do Pod Autoscaler horizontal;
• Tempo de reação do Cluster Autoscaler;
• tempo de provisionamento do nó; e
• Tempo de criação do pod.

Vamos explorá-las uma a uma.

Por padrão, o uso da CPU dos pods é coletado pelo kubelet a cada 10 segundos e obtido do kubelet pelo Metrics Server a cada 1 minuto.

O Horizontal Pod Autoscaler verifica as métricas de CPU e memória a cada 30 segundos.

Se as métricas excederem o limite, o autoescalonador aumentará a contagem de réplicas e recuará por 3 minutos antes de tomar outras medidas. Na pior das hipóteses, pode levar até 3 minutos para que os pods sejam adicionados ou excluídos, mas, em média, você deve esperar 1 minuto para que o Horizontal Pod Autoscaler acione o dimensionamento.

O Cluster Autoscaler verifica se há pods pendentes e aumenta o tamanho do cluster. A detecção de que o cluster precisa ser ampliado pode demorar:

• Até 30 segundos em clusters com menos de 100 nós e 3.000 pods, com uma latência média de cerca de cinco segundos; ou
• Latência de até 60 segundos em clusters com mais de 100 nós, com uma latência média de cerca de 15 segundos.

O provisionamento de nó no Linode geralmente leva de 3 a 4 minutos desde quando o Cluster Autoscaler aciona a API até quando os pods podem ser agendados em nós recém-criados.

Em resumo, com um cluster pequeno, você tem:

```
HPA delay:          1m    +
CA delay:           0m30s +
Cloud provider:     4m    +
Container runtime:  0m30s +
=========================
Total               6m
```

Em um cluster com mais de 100 nós, o atraso total pode ser de 6 minutos e 30 segundos... isso é muito tempo, então como você pode corrigir isso?

Você pode escalonar proativamente suas cargas de trabalho ou, se conhecer bem seus padrões de tráfego, pode escalonar com antecedência.

Dimensionamento preventivo com o KEDA

Se você atende ao tráfego com padrões previsíveis, faz sentido aumentar as cargas de trabalho (e os nós) antes de qualquer pico e diminuir quando o tráfego diminuir.

O Kubernetes não oferece nenhum mecanismo para dimensionar cargas de trabalho com base em datas ou horários, portanto, nesta parte, você usará o KEDA,o Kubernetes Event Driven Autoscaler.

O KEDA é um autoscaler composto por três componentes:

• um scaler;
• um adaptador de métricas; e
• um controlador.

Você pode instalar a KEDA com o Helm:

```bash
$ helm repo add kedacore https://kedacore.github.io/charts
$ helm install keda kedacore/keda
```

Agora que Prometheus e KEDA estão instalados, vamos criar uma implantação.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: podinfo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: podinfo
  template:
    metadata:
      labels:
        app: podinfo
    spec:
      containers:
        - name: podinfo
          image: stefanprodan/podinfo

Você pode enviar o recurso para o agrupamento com:

```bash
$ kubectl apply -f deployment.yaml
```

O KEDA trabalha em cima do Horizontal Pod Autoscaler existente e o envolve com uma definição de recurso personalizado chamada ScaleObject.

O ScaledObject a seguir usa o Cron Scaler para definir uma janela de tempo em que o número de réplicas deve ser alterado:

```yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  maxReplicaCount: 10
  minReplicaCount: 1
  scaleTargetRef:
    name: podinfo
  triggers:
    - type: cron
      metadata:
        timezone: Europe/London
        start: 23 * * * *
        end: 28 * * * *
        desiredReplicas: "5"
```

Você pode apresentar o objeto com:

```bash
$ kubectl apply -f scaled-object.yaml
```

O que acontecerá em seguida? Nada. A escala automática só será acionada entre 23 * * * * e 28 * * * *. Com a ajuda de Cron GuruVocê pode traduzir as duas expressões do cron para:

• Comece no minuto 23 (por exemplo, 2:23, 3:23, etc.).
• Pare no minuto 28 (por exemplo, 2:28, 3:28, etc.).

Se você esperar até a data de início, perceberá que o número de réplicas aumenta para 5.

O número volta a ser 1 após o 28º minuto? Sim, o autoscaler retorna à contagem de réplicas especificada em minReplicaCount.

O que acontecerá se você aumentar o número de réplicas entre um dos intervalos? Se, entre os minutos 23 e 28, você dimensionar sua implementação para 10 réplicas, o KEDA substituirá sua alteração e definirá a contagem. Se você repetir o mesmo experimento após o 28º minuto, a contagem de réplicas será definida como 10. Agora que você conhece a teoria, vamos examinar alguns casos de uso práticos.

Reduzir a escala durante o horário de trabalho

Você tem uma implantação em um ambiente de desenvolvimento que deve estar ativo durante o horário de trabalho e deve ser desligado durante a noite.

Você poderia usar o seguinte ScaledObject:

```yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  maxReplicaCount: 10
  minReplicaCount: 0
  scaleTargetRef:
    name: podinfo
  triggers:
    - type: cron
      metadata:
        timezone: Europe/London
        start: 0 9 * * *
        end: 0 17 * * *
        desiredReplicas: "10"
```

A contagem padrão de réplicas é zero, mas durante o horário de trabalho (das 9h às 17h), as réplicas são dimensionadas para 10.

Você também pode expandir o Scaled Object para excluir o fim de semana:

```yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  maxReplicaCount: 10
  minReplicaCount: 0
  scaleTargetRef:
    name: podinfo
  triggers:
    - type: cron
      metadata:
        timezone: Europe/London
        start: 0 9 * * 1-5
        end: 0 17 * * 1-5
        desiredReplicas: "10"
```

Agora, sua carga de trabalho está ativa somente das 9 às 17 horas, de segunda a sexta-feira. Como é possível combinar vários acionadores, você também pode incluir exceções.

Diminuição de escala nos finais de semana

Por exemplo, se você planeja manter suas cargas de trabalho ativas por mais tempo na quarta-feira, pode usar a seguinte definição:

```yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cron-scaledobject
  namespace: default
spec:
  maxReplicaCount: 10
  minReplicaCount: 0
  scaleTargetRef:
    name: podinfo
  triggers:
    - type: cron
      metadata:
        timezone: Europe/London
        start: 0 9 * * 1-5
        end: 0 17 * * 1-5
        desiredReplicas: "10"
    - type: cron
      metadata:
        timezone: Europe/London
        start: 0 17 * * 3
        end: 0 21 * * 3
        desiredReplicas: "10"
```

Nessa definição, a carga de trabalho está ativa entre 9 e 5 horas, de segunda a sexta-feira, exceto na quarta-feira, que vai das 9 às 21 horas.

Sumário

O escalonador automático do KEDA cron permite definir um intervalo de tempo no qual você deseja escalonar suas cargas de trabalho.

Isso ajuda você a dimensionar os pods antes do pico de tráfego, o que acionará o Cluster Autoscaler com antecedência.

Neste artigo, você aprendeu:

• Como funciona o Cluster Autoscaler.
• Quanto tempo leva para escalar horizontalmente e adicionar nós ao seu cluster.
• Como dimensionar aplicativos com base em expressões cron com o KEDA.

Quer saber mais? Registre-se para ver isso em ação durante nosso webinar em parceria com os serviços de computação em nuvem da Akamai.