HPA e VPA - Autoscaler

Autoscaling deploy (Horizontal e Vertical)

• Criar uma aplicação básica
• Escalar a aplicação usando Horizontal Pod Autoscaler (HPA)
• Escalar a aplicação usando Vertical Pod Autoscaler (HPA)
• Teste de desempenho usando o Locust

Topologia do Laboratório:

Estrutura inicial

1) Criando o diretório dos arquivos .yaml de deployment dos Pods.

mkdir ~/scaler && cd ~/scaler

2) Instalando o serviço de coleta de métricas:

Antes de começarmos a explorar o Horizontal Pod Autoscaler (HPA), é essencial termos o Metrics Server instalado em nosso cluster Kubernetes. O Metrics Server é um agregador de métricas de recursos de sistema, que coleta métricas como uso de CPU e memória dos nós e pods no cluster. Essas métricas são vitais para o funcionamento do HPA, pois são usadas para determinar quando e como escalar os recursos.   O HPA utiliza métricas de uso de recursos para tomar decisões inteligentes sobre o escalonamento dos pods. Por exemplo, se a utilização da CPU de um pod exceder um determinado limite, o HPA pode decidir aumentar o número de réplicas desse pod. Da mesma forma, se a utilização da CPU for muito baixa, o HPA pode decidir reduzir o número de réplicas. Para fazer isso de forma eficaz, o HPA precisa ter acesso a métricas precisas e atualizadas, que são fornecidas pelo Metrics Server.

Nota: Para aprendermos uma nova forma de instalarmos pacotes pré-definidos no kubernetes, vamos usar o gerenciador de pacotes HELM ( https://helm.sh/ ).  

Instalar o Helm

curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Adicionar o Repositório

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/

Instalar o serviço de métricas

helm upgrade --install \
    --set args={--kubelet-insecure-tls} metrics-server metrics-server/metrics-server \
    --namespace kube-system

Nota: Aguarde uns minutos até a criação dos Pods do serviço de métrica.

3) Verificar se tudo OK:

kubectl get pods -n kube-system | grep metrics-server

Nota: Com o serviço de métricas funcionando, será possível usar o comando top para verificar o consumo de recurso pelos objetos:

kubectl top nodes

kubectl top pods

Servidor de Aplicação

1) Antes de nosusar aprofundarmos noo HPA, vamos criar um deployment simples usando qualquer imagem apenas para teste.

vi phpmyadmin.app-tfd1.yaml

# Deployment
apiVersion: apps/v1                    # Versão da API que define um Deployment
kind: Deployment                       # Tipo de recurso que estamos definindo
metadata:
  name: phpmyadminapp-tfd1                       # Nome do nosso Deployment
spec:
  replicas: 13                          # Número inicial de réplicas
  selector:
    matchLabels:
      app: phpmyadminapp-tfd1                    # Label que identifica os pods deste Deployment
  template:
    metadata:
      labels:
        app: phpmyadminapp-tfd1                  # Label aplicada aos pods
    spec:
      containers:
      - name: phpmyadminapp-tfd1                 # Nome do contêiner
        image: bitnami/phpmyadminbrunofischer/app-tfd1   # Imagem do contêiner
        ports:
        - containerPort: 80            # Porta exposta pelo contêiner
        resources:
          limits:
            cpu: 400m                  # Limite de CPU
          requests:
            cpu: 100m                  # Requisição de CPU

#Service
---
# Service
apiVersion: v1
kind: Service
metadata:
  name: phpmyadmin-app-tfd1-service

spec:
  ports:
  - nodePort: 30001
    port: 8080
    protocol: TCP80
    targetPort: 808080
  selector:
    app: phpmyadminapp-tfd1
  type: NodePortLoadBalancer
  loadBalancerIP: 10.9.66.150

2) Subir o deployment e o service doda nginx:aplicação:

kubectl apply -f phpmyadmin.app-tfd1.yaml

3) Verifique se o deploy foi finalizado e o POD está rodando (Running). 

kubectl get pods

Horizontal Pod Autoscaler (HPA)

Agora, com nosso deployment pronto, vamos dar o próximo passo na criação do nosso HPA. Neste exemplo, criamos um HPA que monitora a utilização da CPU do nosso deployment nginx-deploymentapp-tfd1. O HPA se esforçará para manter a utilização da CPU em torno de 50%, ajustando o número de réplicas entre 3 e 10 conforme necessário.

1) Subir as especificaçEspecificações do HPAHPA:

vi app-tfd1-hpa.yaml

# Definição do HPA para o nginx-deployment

apiVersion: autoscaling/v2       # Versão da API que define um HPA
kind: HorizontalPodAutoscaler    # Tipo de recurso que estamos definindo
metadata:
  name: phpmyadmin-app-tfd1-hpa             # Nome do nosso HPA
spec:
  scaleTargetRef:
    apiVersion: apps/v1          # A versão da API do recurso alvo
    kind: Deployment             # O tipo de recurso alvo
    name: phpmyadminapp-tfd1               # O nome do recurso alvo
  minReplicas: 1                 # Número mínimo de réplicas
  maxReplicas: 10                # Número máximo de réplicas
  metrics:
  - type: Resource               # Tipo de métrica (recurso do sistema)
    resource:
      name: cpu                  # Nome da métrica (CPU neste caso)
      target:
        type: Utilization        # Tipo de alvo (utilização)
        averageUtilization: 50   # Valor alvo (50% de utilização)
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0    # Período de estabilização para escalonamento para cima
    scaleDown:
      stabilizationWindowSeconds: 30   # Período de estabilização para escalonamento para baixo

2)Aplicar Subiras oconfigurações HPAdo HPA:

kubectl apply -f app-tfd1-hpa.yaml

3)Verificar Verificarse o serviço do HPA se está okativo:

kubectl get hpa

Locust (Stress Test)

Será instalado uma ferramenta para testes de stress chamada Locust ( https://locust.io/ ). Com ela vamos testar o stress do deployment do nginx para validarmos o HPA.

1) Arquivo locust.yaml

vi locust.yaml

# ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: locust-config
data:
  locustfile.py: |
    from locust import HttpUser, task, between
    class Fischer(HttpUser):
        wait_time = between(1, 2)
        @task(1)
        def testar(self):
            self.client.get("/")
            
self.client.get("/doc/html/index.html")
---
# Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: locust
spec:
  replicas: 1
  selector:
    matchLabels:
      app: locust
  template:
    metadata:
      labels:
        app: locust
    spec:
      containers:
      - name: locust
        image: locustio/locust
        command: ["locust", "-f", "/etc/locust/locustfile.py"]
        volumeMounts:
        - name: locust-config
          mountPath: /etc/locust
      volumes:
      - name: locust-config
        configMap:
          name: locust-config

---
# Service
apiVersion: v1
kind: Service
metadata:
  name: locust-app-tfd1-service

spec:
  ports:
  - nodePort: 30002
    port: 8089
    protocol: TCP
    targetPort: 8089
  selector:
    app: locust
  type: NodePortLoadBalancer
  loadBalancerIP: 10.9.66.151

2) Subir o deployment do serviço locust

kubectl apply -f locust.yaml

3) Verifique se o deploy foi finalizado e o POD está rodando (Running). 

kubectl get pods

4) Fazer o teste usando o Firefox do ORC-Server.

Nota: Antes de abrir o navegado para o teste, deixe o comando abaixo rodando para acompanhar a criação dos Pods.
A opção -w ficará observando as mudanças (watching)

kubectl get deploy/phpmyadmin -w

• Máximo de usuários simultâneos: 1000
• Incremento de 10 em 10. 
• Host: http://172.18.0.4:30001 (serviço do PHPmyadmin).

Atenção: Após a validação dos testes, pare a geração de tráfego de stress clicando em "STOP". Você também poderá excluir o deployment do locust. kubectl delete -f locust.yaml 

Responda a pergunta 01 do laboratório.

---

Perguntas do Laboratório:

1. (teórica) Qual a função do Horizontal Pod Autoscaler (HPA) no Kubernetes?