Escalando sua aplicação utilizando K8S e Prometheus
Tags: kubernetes, devops, braziliandevs
Published: 2021-07-16 00:34:32

Hoje em dia é comum termos a necessidade de trabalhar com várias instâncias de um serviço para atender cargas de trabalho que em determinados momentos uma única pode não ser o suficiente.

O Kubernetes possui o componente HorizontalPodAutoscaler(HPA) que nos permite de forma automática controlar a quantidade de replicas do serviço baseado em métricas, ou seja permite definir o momento em que deve ser adicionado replicas ao seu "pool" de instâncias do seu serviço, evitando assim desperdício de recurso que seria o caso de um gerência estática.

#### E como podemos escalar baseado em métricas de aplicação?

Por padrão só conseguimos utilizar o HPA com métricas de CPU ou memoria, porém com o Prometheus podemos obter métricas da aplicação que por sua vez serão enviadas para a API Kubernetes.

## O que iremos utilizar?

* [Helm](https://helm.sh/docs/intro/install/)
* [Prometheus Stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack)
* [Prometheus Operator](https://github.com/kubernetes-sigs/prometheus-adapter)

_Para seguir artigo será necessário ter instalado o [Helm](https://helm.sh/docs/intro/install/) e o nosso cluster que sugiro utilizar opções como [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/), [Minikube](https://minikube.sigs.k8s.io/docs/start/) e afin._


## Instalação Prometheus Stack e Adapter

### Prometheus Stack

Este é uma coleção de documentos para configuração do seu Prometheus para o Kubernetes, além de já instalar o Grafana que também sera utilizado aqui.

#### Primeiramente vamos criar uma namespace para nossos serviços de monitoramento

```
kubectl create namespace monitoring
```

#### E em seguida já podemos instalar o Prometheus Stack através do Helm

```
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring  --set grafana.service.type=NodePort --set prometheus.service.type=NodePort
```

_Pode ser observado que foi adicionado argumentos definindo os tipos de serviço como NodePort tendo em vista facilitar nosso acesso as interfaces fora do cluster, porém em um ambiente de produção o recomendado é utilizar [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)._

Apos a execução dos comandos é esperado esse resultado ao listar nossos deployments
```
~$ kubectl get deployments -n monitoring
NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
prometheus-grafana                    1/1     1            1           19h
prometheus-kube-prometheus-operator   1/1     1            1           19h
prometheus-kube-state-metrics         1/1     1            1           19h
```

### Prometheus Adapter

Esse é o resposável por ser conectar ao nosso Prometheus e obter as metricas coletadas pelo mesmo e envia-las para a API Metricas do Kubernetes disponibilizando o uso das mesmas no nosso [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).

Crie o arquivo `customValues.yaml`, pois nele iremos configurar a url para nosso prometheus e configuração adicional para obter métricas requisições por segundo que iremos utilizar logo mais a frente.
```
prometheus:
  url: "http://prometheus-kube-prometheus-prometheus"
rules:
  custom:
  - seriesQuery: '{container!="POD",namespace!="",pod!=""}'
    resources:
      template: <<.Resource>>
    name:
      matches: "^(.*)_seconds_count"
      as: "${1}_per_second"
    metricsQuery: (sum(rate(<<.Series>>{<<.LabelMatchers>>}[1m])) by (<<.GroupBy>>))

```
_A url do prometheus definida é baseada no [DNS interno do serviço](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) visto que o mesmo foi também na namespace monitoring _

```
helm install prometheus-adapter prometheus-community/prometheus-adapter -n monitoring -f customValues.yaml
```

### Instalando nossa aplicação no cluster

Para este exemplo utilizei de uma aplicação SpringBoot+Kotlin que está disponível em [GitHub](https://github.com/rafaelcarvalhedo/spring-auto-scaling-k8/tree/master).

Toda a especificação do chart dessa aplicação se encontra em /chart, que segue a seguinte estrutura:

```
chart/  
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── serviceaccount.yaml
│   ├── servicemonitor.yaml
│   └── service.yaml
└── values.yaml

```

Dentre os yaml's acima o `servicemonitor.yaml` é responsável por definir a captura de metricas do serviço, que no nosso caso é no path `/actuator/prometheus`.

#### Gerando imagem aplicação

Para gerar a imagem da aplicação iremos usar o seguinte comando gradle: 

```
gradle bootBuildImage
```

Após isso já teremos disponível em docker local a imagem `spring-auto-scaling:0.0.1`, feito isso poderemos agora intalar nosso chart no cluster.

#### Instalando via Helm

```
helm install article chart/
```

### Verificando estado atual do HPA

Podemos fazer isso com kubectl: 
```
~$ kubectl get hpa 
NAME                          REFERENCE                                TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
article-spring-auto-scaling   Deployment/article-spring-auto-scaling   418m/1    1         5         1          65m

```
A Coluna TARGETS representa a métrica alvo, onde temos 418m(O K8's utiliza 'm' para unidades fracionarias da métrica que nesse caso seria 0,4/1) de 1 como media entre as quantidade de replicas que também se encontra em 1. A carga atual se deve ao fato de termos o Prometheus obtendo as métricas do nosso serviço através do ServiceMonitor.

### Incrementando carga

Iremos executar um pod com busybox para fazer chamadas á nossa aplicação em loop, irá tentar gerando uma carga de 10 requisições por segundo.

```
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.1; do wget -q -O- http://article-spring-auto-scaling/users/latest; done"
``` 
_Devemos levar em conta o tempo de resposta da aplicação, pois as chamadas são sequencias e não paralelas, porém já é o suficiente para vermos funcionar._

#### Eventos HPA

```
kubectl describe hpa  article-spring-auto-scaling
```

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hxb7tcm015s0mace4m9q.png)

Como podemos para que para tentar atingir a media máxima de 1 req/s enviou eventos para aumentar o numero replicas para nosso deployment e chegou ao número de 4 replicas sendo 5 o número máximo de replicas permitidas.

_Uma excelente boa prática é definição de valores limites, pois não queremos que um serviço escale infinitamente dentro nosso cluster._

## Conclusão

Podemos ver que o escalonamento de automático de aplicações é grande aliado, juntamente com a possibilidade de usar métricas customizadas que podem estar bem alinhadas a necessidade do negócio.As configurações e definições de escalonamento também devem ser constantemente monitoradas e refinidas, pois os requisitos sempre mudam e afinal não existe bala de prata.