O que muda (mesmo) na nossa aplicação?

É manhã de segunda-feira e a euforia do dérbi ganho ainda pulsa nas veias.
O café sabe melhor e as conversas de futebol fluem animadas.

Mal me sento ao computador, surge a notificação fatídica:

“Reunião de Líderes — Assunto: Kubernetes — 10h”

Reunião com o Administrador à segunda-feira de manhã nunca é bom sinal.

Chega a hora H. O Administrador fala, visivelmente entusiasmado:

“Este fim de semana visitei uma empresa parceira e tive contacto direto com uma plataforma de e-commerce a operar sobre Kubernetes.
É um Ferrari da infraestrutura!
Não se preocupem, com a ajuda do ChatGPT já criei na nossa cloud, um cluster kuberntes pronto para usar.
Quero agora a nossa solução a funcionar no cluster até ao final do dia.”

A missão parecia impossível.

Como líder da equipa de desenvolvimento, a minha mente dispara.
“Kubernetes”… já ouvi falar. Lembro-me de um vídeo no YouTube do canal @LINUXTips, mas quase tudo o que vejo na internet fala apenas de infraestrutura, serviços, dns, volumes, etc...

E a pergunta surge naturalmente:

Afinal… o que é que muda na nossa aplicação?

Vamos desmistificar isto.
K8s (o acrónimo de Kubernetes) não pode ser um bicho de sete cabeças para developers.

Primeiro: o que o Kubernetes não é (para ti, developer)

Antes de mais nada, respira fundo.
Não é preciso ser SysAdmin nem DevOps Guru para fazer código correr em Kubernetes.

Não é um novo ambiente de desenvolvimento

Continuas a programar na tua máquina local.
O workflow diário não muda drasticamente.

Para validações locais podes usar no teu computador:

• Docker ou Podman
• Para uma experiência mais próxima de produção, podes usar Kubernetes “light” como Kind ou Minikube

Não é um novo framework de código

Não é preciso reescrever a tua API Java, .NET ou Node.js para “usar Kubernetes”.
A aplicação continua a ser… uma aplicação normal.

👉 Kubernetes muda mais o “como corre” do que o “como é escrita” a aplicação.

O que muda de verdade?

A era dos containers 🐳

A maior mudança é a forma como a aplicação é empacotada e gerida.
A palavra mágica é containerização.

Se ainda não usas Docker, este é o momento certo para aprender.

Recomendo vivamente o curso gratuito “Descomplicando Docker” do canal @LINUXTips no YouTube, complementado pelo livro com o mesmo nome.

• Livro: https://livro.descomplicandodocker.com.br/, por @LINUXTips

O Kubernetes é um orquestrador de containers — gere onde e como os teus containers correm.

Os 6 pontos que todo developer precisa de saber para correr aplicações em Kubernetes

1. O Dockerfile é o teu novo melhor amigo

A aplicação precisa viver dentro de uma imagem Docker.
Passa a ser responsabilidade do developer criar e manter um Dockerfile que garante que a aplicação arranca sempre da mesma forma, em qualquer ambiente.

Exemplo de Dockerfile multi-stage

# Etapa de build
FROM maven:3.9.12-eclipse-temurin-25 AS build
WORKDIR /app
COPY . .
RUN mvn clean package -DskipTests

# Etapa de execução
FROM eclipse-temurin:25-jre-noble
WORKDIR /opt/app
COPY --from=build /app/target/*.jar accountapi.jar
EXPOSE 8080
CMD ["java", "-jar", "/opt/app/accountapi.jar"]

👉 Garante que a aplicação arranca com um simples docker run.

Leitura recomendada:

• Livro “Descomplicando Docker”, por @LINUXTips
• Docker: Dockerfile, por Hugo Habbema

2. Configuração via ConfigMaps e Secrets

Em muitas aplicações tradicionais, a configuração vem misturada com o código:

• URLs de bases de dados
• utilizadores e passwords
• chaves de API
• portas

Funciona… até deixar de funcionar.

É daqui que nasceu a famosa frase de developer:

“Na minha máquina funciona.”

No Kubernetes, a aplicação pode:

• arrancar em qualquer nó
• ser reiniciada a qualquer momento
• escalar automaticamente

A regra de ouro é clara:

Código deve ser imutável. Configuração deve ser externa.

Aqui entram os ConfigMaps e Secrets.

Exemplo de ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: accounts-api-configmap
data:
  application.properties: |
    spring.application.name=AccountsAPI
    server.port=8200
    spring.data.redis.host=redis-dev
    spring.data.redis.port=6379

Leitura recomendada:

• Os 12 Fatores
• O que é ConfigMap no Kubernetes?, por Rafael Fernandes

3. Saúde da aplicação: startup, liveness e readiness probes

Como é que o Kubernetes sabe se a aplicação está saudável?

A resposta é simples: endpoints HTTP que retornem HTTP 200 quando a aplicação estiver OK.

Liveness Probe
👉 “A aplicação travou e não consegue recuperar sozinha?”
Se este endpoint falhar, o k8s reinicia o container.

• /healthz

Readiness Probe
👉 “A aplicação está pronta para receber tráfego agora?”
Se este endpoint falhar, o k8s para de enviar tráfego temporariamente.

• /ready

Startup Probe
👉 “A aplicação já terminou de arrancar?”
Como o nome diz, este endpoint verifica se a aplicação já arrancou.

• /startup

Leitura recomendada:

Kubernetes Probes: por que um Pod “Running” não significa que sua aplicação está saudável, por Ernesto Toshiyuki Akaike

4. Logging para stdout

Em Kubernetes, os logs devem ir para:

• stdout
• stderr

Evita escrever logs em ficheiros locais dentro do container.

O cluster trata da recolha (kubectl logs) e podes também integrar com soluções como:

• Graylog
• Grafana Loki

Leitura recomendada:

Live Descomplicando o GRAYLOG, por Jeferson Fernando &Maiki

5. Ficheiros e armazenamento: repensar o “disco local”

Containers são efémeros.

Tudo o que escreves no sistema de ficheiros local desaparece quando o container morre.

Se precisas de persistência deves usar:

• bases de dados externas
• volumes (NFS, CSI)
• object storage (S3, Azure Storage, etc.)

Nunca guardes uploads de utilizadores no disco local do container.

Leitura recomendada:

Volumes e sua importância no K8s, por Allan Zanella

6. Defina as regras de mapeamento dos endpoints da sua API

A aplicação não expõe endpoints diretamente para o exterior.

Ela corre em pods com IPs internos e efémeros.

A pergunta é inevitável:

Quando chega um pedido a https://api.exemplo.com/users, para onde ele vai?

Como o Kubernetes sabe a que serviço e aplicação pertence a requisição ?

É aqui que entram o Ingress e o Gateway API

Ingress é o mecanismo clássico para expor HTTP/HTTPS da sua aplicação.
Gateway API é a evolução natural. Mais flexível, mais segura e preparada para equipas maiores.

Mesmo que não sejas tu a escrever os manifestos:

• precisas de saber que endpoints expões
• quais os paths públicos
• como isso impacta o routing e a segurança

Leitura recomendada:

Do Ingress ao Gateway API: Automatizando TLS com cert-manager e Let’s Encrypt, por Eduardo Zenardi
Ingress Nginx + NIP.IO: Teste de Hostnames no Kubernetes, por Bruno Santos

Homelab e CGNAT

Se tens interesse em praticar em casa, mas estás com limitações de CGNAT, vale conferir o artigo “Expondo meu Homelab atrás de CGNAT sem gastar nada!” do Felipe Soares.
Ele mostra como usar Cloudflare Tunnel, MetalLB, NGINX Ingress Controller e Pi-hole para expor serviços de forma segura, prática e próxima de um cenário de produção real.

Resumo da ópera 🎭

O Kubernetes é um orquestrador poderoso.
Escala, recupera falhas e mantém a aplicação a correr.

Para nós, developers, a mensagem é clara:

Construir aplicações modernas, portáteis e resilientes.

O Administrador quer a solução até ao final do dia?
Talvez não hoje.

Mas seguindo estes 6 pontos, em breve estaremos mesmo a correr num Ferrari da infraestrutura.

Agora, se me dão licença, vou ali criar o Dockerfile e os Health-Check da aplicação .
A fofoca do futebol fica para outro dia.⚽️

#LINUXTips #DescomplicandoKubernetes #Kubernetes #Developer

Na era da internet 3.0, medium chegou como solução de postagem web.