🚀 Kubernetes: ConfigMap, Secrets e HPA

Fala Dev! 👋

Neste Borapraticar, vamos matar não dois e sim três coelhos com uma cajadada só:

• Aprender a usar ConfigMap e Secrets com o PostgreSQL que já criamos
• E ainda configurar o HPA (Horizontal Pod Autoscaler) pra escalar sua app Spring Boot automaticamente

Se você chegou até aqui, provavelmente já está com o ambiente K3d rodando liso e até com um PostgreSQL no ar com StatefulSet do Kubernetes, como a gente mostrou no Borapraticar 🚀 Kubernetes: StatefulSet de PostgreSQL no K3d. Agora chegou a hora de subir mais um degrau nessa jornada com Kubernetes.

Preparado(a)? Bora praticar! 👷‍♂️💻

---

🔐 Usando ConfigMap e Secret no StatefulSet do PostgreSQL

No nosso último Borapraticar, os dados sensíveis como usuário e senha estavam hardcoded no YAML. Convenhamos: isso não é nada legal. Então vamos dar uma melhorada usando ConfigMap e Secret.

🧾 ConfigMap para variáveis não sensíveis

postgres-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-config
data:
  POSTGRES_DB: myappdb
  POSTGRES_USER: myuser

🔐 Secret para informações sensíveis

Versão tradicional com Base64:

postgres-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: postgres-secret
type: Opaque
data:
  POSTGRES_PASSWORD: ZGV2MTIz # Base64 de "dev123"

💡 Dica Borapraticar: se quiser facilitar sua vida, use stringData no lugar de data. Ele aceita texto puro e o Kubernetes se vira pra converter pra Base64 por baixo dos panos.

postgres-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: postgres-secret
type: Opaque
stringData:
  POSTGRES_PASSWORD: dev123

🔁 Ambas as versões funcionam na prática da mesma forma, então escolha a que te poupar dor de cabeça, principalmente durante o desenvolvimento local.

🛠 Atualizando o StatefulSet para usar ConfigMap e Secret

envFrom:
  - configMapRef:
      name: postgres-config
  - secretRef:
      name: postgres-secret

💡 E a versão com a alteração fica assim👇

statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: "postgres"
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        ports:
        - containerPort: 5432
        envFrom:
        - configMapRef:
            name: postgres-config
        - secretRef:
            name: postgres-secret
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: postgres-storage
    spec:
      storageClassName: local-path
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Agora a gente separou as variáveis sensíveis e não sensíveis em um ConfigMap e um Secret, e deixamos o StatefulSet bem mais limpo usando envFrom. Isso deixa o YAML mais organizado, facilita a manutenção e já prepara o terreno pra um ambiente mais seguro e escalável.

🧪 Aplicando os arquivos YAML:

kubectl apply -f postgres-config.yaml
kubectl apply -f postgres-secret.yaml
kubectl apply -f statefulset.yaml
kubectl apply -f service.yaml

🔍 Conferindo se tá tudo certo

Você pode verificar se tudo foi criado direitinho com os comandos abaixo:

kubectl get configmap
kubectl get secret
kubectl get statefulset
kubectl get pods
kubectl get all

🧾 Visualizando o conteúdo do ConfigMap:

kubectl get configmap postgres-config -o yaml

💡 Isso vai mostrar todas as chaves e valores em texto plano.

🔐 Visualizando o conteúdo do Secret (decodificado):

Como os Secrets são codificados em Base64, você pode fazer assim pra ver o valor real:

kubectl get secret postgres-secret -o jsonpath="{.data.POSTGRES_PASSWORD}" | base64 -d

🧙‍♂️ Se quiser ver tudo de uma vez (codificado), roda

kubectl get secret postgres-secret -o yaml

E aí é só decodificar os valores manualmente se quiser espiar 🔍

---

⚙️ Escalabilidade Automática com HPA

O Horizontal Pod Autoscaler (HPA) ajusta automaticamente a quantidade de réplicas da sua aplicação com base no consumo de CPU (ou outras métricas). Ou seja, quando a demanda aumenta, ele escala pra cima; quando acalma, ele mata as replicas desnecessárias, tudo no automático. Ideal pra manter performance e evitar desperdício de recurso.

A gente já tinha um Deployment com uma app Spring Boot rodando, lembra do Borapraticar Kubernetes: Mão na massa com K3d e Spring Boot?. Agora chegou a hora de colocar o HPA pra trabalhar.

📦 Atualizando o Deployment

⚙️ Pra que o HPA saiba quando escalar sua aplicação, a gente precisa informar quanto de recurso cada container precisa pra rodar. Isso é feito com o bloco resources.

🔸 requests → o mínimo que o container precisa pra funcionar sem sufoco
🔸 limits → o máximo que ele pode usar (tipo um teto)

✨ Aqui vai o exemplo:

resources:
  requests:
    memory: "512Mi"
    cpu: "100m"
  limits:
    memory: "1024Mi"
    cpu: "1024m"

🚀 E a versão atualizada do Deployment fica assim:

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: minha-app
  template:
    metadata:
      labels:
        app: minha-app
    spec:
      containers:
        - name: minha-app
          image: minha-app:latest
          imagePullPolicy: Never
          ports:
            - containerPort: 8080
          resources:
            requests:
              memory: "512Mi"
              cpu: "100m"
            limits:
              memory: "1024Mi"
              cpu: "1024m"
---
apiVersion: v1
kind: Service
metadata:
  name: minha-app
spec:
  selector:
    app: minha-app
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 30001
  type: NodePort

💡 Com isso configurado, o HPA consegue monitorar o uso e escalar horizontalmente os pods quando o bicho começar a pegar 🔥📈

📈 Criando o HPA

hpa.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: minha-app
  minReplicas: 1
  maxReplicas: 2
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 60
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 90

Se o pod estiver usando mais de 50% da CPU ou 90% de memória em no nosso caso, o Kubernetes vai começar a escalar.

🧪 Aplicando os arquivos YAML:

kubectl apply -f deployment.yaml
kubectl apply -f hpa.yaml

---

🔥 Testando o Auto Scaling na prática

Antes de tudo, a gente precisa instalar o metrics-server — ele é o carinha responsável por coletar e expor métricas de CPU e memória dos pods e nodes dentro do cluster. 📊

Sem ele, o HPA fica no escuro e não consegue tomar decisões de escalabilidade. 😵‍💫

🚀 Instale o metrics-server com:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

💡 Depois de instalar, dá um tempinho pra ele subir. Você pode verificar com:

kubectl get deployment metrics-server -n kube-system

Se aparecer como AVAILABLE, tá tudo certo! ✅

Agora precisamos dar acesso a nossa aplicação através do port forward:

kubectl port-forward svc/minha-app 8090:8080 &

Gere carga na app com hey ou curl:

# Usando hey
hey -z 60s -c 50 http://localhost:8090

# Usando curl
while true; do curl http://localhost:8090/test; done

Para acompanhar o consumo de CPU e memória:

kubectl top pods
kubectl get hpa

Veja os pods escalando:

kubectl get pods -w

E voilá! Se tudo estiver certo, novos pods vão surgir para dar conta da pancadaria. 💥

---

---

📦 Conclusão

Nesse Borapraticar a gente deu um passo importante:

• Separou configs sensíveis do código com ConfigMap e Secret
• Aprendeu a escalar nossa aplicação de forma automática com HPA

E o melhor: tudo isso no seu cluster local K3d. Agora é contigo: testa aí, quebra as coisas, observa o comportamento, e depois compartilha com a galera. Bora praticar! 💪🚢

💭 Ficou com alguma dúvida?
Deixa um comentário aqui, vai ser massa trocar ideia sobre isso!

👨‍💻👩‍💻 Conhece algum dev que tá de olho no Kubernetes?
Compartilha com ele(a), pode ser justamente o empurrãozinho que faltava pra começar! 🚀