Tenho os meus serviços a correr num cluster Kubernetes de três Raspberry Pi. Explico a stack — k3s, Longhorn, Traefik, cert-manager — e porque é que, para certos casos de uso, vale a pena face a uma cloud pública.
Há quem associe Kubernetes a grandes equipas e datacenters. A realidade é que hoje se corre um cluster produtivo em hardware que cabe na palma da mão. Os meus serviços pessoais e profissionais vivem num cluster de três Raspberry Pi — e este artigo é, literalmente, servido por ele.
O hardware
Três Raspberry Pi (modelos 4 e 5), cada um com o seu SSD via USB 3. Estão ligados a um switch da rede de casa, por trás de um router que faz port-forward para o cluster. Não é um supercomputador, mas é mais do que suficiente para workloads pequenos e médios: sites, CMS, registries privados, automações.
A stack: k3s
Uso k3s, uma distribuição Kubernetes leve, empacotada num único binário e otimizada para edge e IoT. Tem tudo o que preciso do Kubernetes — pods, deployments, services, ingress, PVCs — sem o peso dos componentes opcionais. Em três comandos tenho um node pronto; em mais uns minutos, um cluster de três com alta disponibilidade no control-plane.
Armazenamento: Longhorn
Para discos persistentes uso Longhorn, um storage distribuído nativo de Kubernetes. Cada PVC é replicado entre os nodes, o que significa que se um Pi morre, os dados continuam acessíveis nos outros dois. Para um cluster caseiro, esta resiliência é exatamente o que falta a uma solução de "um servidor numa pen drive". Há snapshots integrados, que dão rollback e backup.
Ingress e TLS: Traefik + cert-manager
O tráfego externo entra pelo Traefik, que faz routing por hostname para os vários serviços. Os certificados HTTPS são emitidos automaticamente pelo cert-manager via Let's Encrypt e renovados sem intervenção. Acrescentar um subdomínio novo é aplicar um IngressRoute e um Certificate — pronto, em segundos tenho HTTPS válido.
O que lá corre
Neste momento o cluster serve: o meu site (Next.js), um Directus como headless CMS, um Forgejo (git e registry privados), um WordPress multisite para outros projectos, e várias ferramentas internas. Tudo isolado em namespaces, com resources limits para nenhum serviço estrangular os outros.
Quando faz sentido (e quando não)
Self-hostar em Pi não substitui uma cloud para tudo. Faz sentido para serviços pessoais, sites institucionais baixo-tráfego, automações e aprendizagem. Não faz sentido para workloads com picos imprevisíveis, latência crítica ou quando a tua banda de upload é o gargalo.
Há ainda o factor email: auto-hospedar correio fiável a partir de um IP residencial é complicado por causa da reputação e do reverse DNS. Para email, uma solução alojada (com o domínio próprio) costuma ser a escolha pragmática.
Conclusão
O que me prende neste setup não é o preço (embora seja baixo): é o controlo. Sei exatamente onde estão os meus dados, configuro cada peça ao meu gosto, e aprendo muito no processo. Num mundo em que cada vez mais coisas vivem em servidores de terceiros, ter um cantinho meu — redundante, seguro e meu — é uma forma de soberania digital.
K3s — Lightweight Kubernetes, from concept to production
What k3s is, how it works and when to choose it — certified Kubernetes in a 70 MB binary, from edge to production.
Ler artigo →Ollama: o guia completo para executar IA localmente com privacidade
Como correr LLMs como Llama 3, Gemma 2 ou Mistral na sua própria máquina — sem internet, sem custos de API e com total privacidade. Instalação, modelos, API REST e casos de uso.
Ler artigo →Alta disponibilidade: por que 99.9% de uptime não é suficiente
Quando 0,1%% de downtime significa horas perdidas — os "noves" explicados, o orçamento de erro do Google SRE, e como construir infraestruturas verdadeiramente resilientes.
Ler artigo →