Em casa mantenho um cluster k3s — a distribuição leve do Kubernetes, pensada para hardware modesto e ARM — a correr em Raspberry Pi. É o mesmo homelab que já mencionei no Sobre: a cobaia para tudo o que quero experimentar antes de chegar perto de produção.
Topologia simplificada e ilustrativa — o número real de nós varia; o que interessa aqui é a relação entre o cluster e a produção, não um inventário.
O que corre lá
Não há uma lista fixa — é essa a natureza de um terreno de testes: passam por lá as ferramentas deste site antes de irem para o browser de outra pessoa, configurações que quero validar antes de as levar para o trabalho, e montagens de infraestrutura ofensiva para lab e CTFs (o heatmap ATT&CK mapeia essa prática à técnica Acquire Infrastructure do MITRE ATT&CK, ao nível “experiência pontual / lab”). O denominador comum é sempre o mesmo: nada toca produção sem primeiro passar por aqui.
Porquê k3s
Um Raspberry Pi não tem o footprint para um Kubernetes “a sério” — o k3s existe exatamente para isto: a mesma API do Kubernetes, com o etcd, os controllers legacy e as dependências desnecessárias cortadas para caber em hardware ARM de baixo consumo. Ganho a prática dos padrões que interessam em produção — multi-nó, scheduling, resiliência a perder um nó — num ambiente barato o suficiente para partir sem custar nada.
Decisões técnicas
- Cluster, não um Pi isolado. Um único nó testa “corre o container”; vários nós testam o que falha de verdade em produção — perder um nó, agendar em falta de recursos, tolerar reinícios.
- Isolamento deliberado da produção. O homelab não tem acesso a nada que importe fora dele; é um ambiente descartável por construção, para poder ser destruído e reconstruído sem cerimónia.
- Sem exposição pública fixa. Ainda não há um subdomínio a apontar para
o homelab (ver
docs/dns-tls.mdneste repo) — decide-se se e quando fizer sentido, sem comprometer entretanto a política de HSTS preload do domínio principal.