O que é Kubernetes bare-metal

Kubernetes bare-metal significa rodar o orquestrador de containers diretamente em servidores físicos, sem a camada de virtualização de uma nuvem pública como AWS, GCP ou Azure. Você e responsável pelo hardware, pelo sistema operacional, pela rede e por toda a configuração que nas nuvens fica abstraída.

A maioria dos devs encontra Kubernetes em ambientes de nuvem gerenciados (EKS, GKE, AKS). Mas rodar bare-metal e uma experiência diferente: você entende na prática o que aqueles serviços abstraem, ganha um lab para experimentar sem gastar fortunas em cloud, e aprende os detalhes que normalmente ficam escondidos.

Um desenvolvedor publicou no Dev.to a experiência de montar um cluster com cerca de 200 dólares em hardware de segunda mao. O resultado foi um homelab funcional, três cartões SD queimados, muito aprendizado e uma lista de armadilhas que valem ouro para quem quer fazer o mesmo.

Como funciona um cluster bare-metal

Um cluster Kubernetes mínimo precisa de pelo menos um no de controle (control plane) e um ou mais nos de trabalho (worker nodes). No bare-metal você precisa provisionar o sistema operacional, instalar as dependências de rede (CNI), configurar o armazenamento persistente e manter tudo isso funcionando sem os automatismos da nuvem.

Distribuições especializadas facilitam esse trabalho. O Talos Linux e uma das mais populares para homelab: e um OS imutável projetado especificamente para rodar Kubernetes, sem SSH, sem shell de usuário, gerenciado inteiramente via API. O k3s e outra opcao popular, mais leve e fácil de instalar em hardware limitado como Raspberry Pi.

A parte mais trabalhosa do bare-metal e o que a nuvem resolve automaticamente: load balancer para o ingress, armazenamento persistente (volumes), certificados SSL e atualizações dos nos sem interrupção do cluster. Cada um desses requer uma solução específica no bare-metal.

⚠️
Atenção

Cartões SD e armazenamento eMMC barato não são adequados para nos de Kubernetes em uso continuo. A taxa de escrita do etcd (banco de dados do Kubernetes) desgasta rapidamente esse tipo de midia. Use SSD ou disco rígido para nos de produção.

Hardware para começar com pouco

O artigo original usou cerca de 200 dólares (R$ 1000 ao cambio atual) em equipamentos de segunda mao. O que foi possível montar com isso?

Três mini PCs ou single-board computers (SBCs) são suficientes para um cluster funcional: um control plane e dois worker nodes. Raspberry Pi 4 com 4GB de RAM são uma opcao popular, mas mini PCs x86 de segunda mao (como Intel NUC ou ThinkCentre tiny) oferecem melhor performance por um preço similar no mercado brasileiro.

O armazenamento externo (NAS ou disco USB) pode ser adicionado depois para armazenamento persistente dos pods. Switches de rede simples completam a configuração. Energia: três Raspberry Pi 4 consomem cerca de 5W cada em idle, um custo elétrico muito baixo comparado a manter uma VM em cloud continuamente.

💡
Dica

Antes de comprar hardware, verifique o Mercado Livre e grupos de hardware no Facebook. Mini PCs corporativos retirados de frotas empresariais aparecem com frequência por 200 a 400 reais cada e tem suporte muito melhor para Linux do que hardware consumer barato.

Como começar: instalação básica

O caminho mais direto para um cluster homelab funcional usa k3s, que tem instalação em um comando e roda bem em hardware limitado.

Passo 1: Instale uma distribuição Linux nos nos (Ubuntu Server 24.04 LTS e uma boa escolha por compatibilidade e suporte longo).

Passo 2: No no de controle, instale o k3s com o servidor:

curl -sfL https://get.k3s.io | sh -
# Aguardar o serviço iniciar
sudo systemctl status k3s
# Obter o token para adicionar workers
sudo cat /var/lib/rancher/k3s/server/node-token

Passo 3: Nos worker nodes, instale o agente apontando para o no de controle:

export K3S_URL="https://IP_DO_CONTROL_PLANE:6443"
export K3S_TOKEN="TOKEN_DO_PASSO_ANTERIOR"
curl -sfL https://get.k3s.io | K3S_URL=$K3S_URL K3S_TOKEN=$K3S_TOKEN sh -

Passo 4: Verifique se o cluster esta saudável:

kubectl get nodes
# Deve mostrar os nos com status Ready

Exemplo prático: deploying uma aplicação real

Com o cluster no ar, o próximo passo e fazer o deploy de algo real. Um servidor de arquivos (como Nextcloud) ou uma stack de monitoramento (Prometheus + Grafana) são bons projetos iniciais para aprender com contexto prático.

A licao mais importante do artigo original foi sobre armazenamento persistente. Pods que precisam de dados persistentes (banco de dados, uploads de arquivo) precisam de um Persistent Volume. No bare-metal, você precisa provisionar isso manualmente ou usar uma solução de armazenamento distribuído como Longhorn (funciona bem com k3s) ou um NFS simples apontando para um disco externo.

# Instalar Longhorn via Helm (armazenamento distribuído para k3s)
helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace

# Verificar pods do Longhorn
kubectl -n longhorn-system get pods

Comparação com alternativas

Kubernetes gerenciado em nuvem (EKS, GKE, AKS): muito mais fácil de operar, suporte automático para load balancer, armazenamento e atualizações. Custo mensal significativo para um cluster minimamente útil (tipicamente R$ 500 a R$ 1500/mes para um cluster dev). Para homelab e aprendizado, bare-metal vence em custo absoluto.

minikube / kind localmente: excelente para desenvolvimento local, mas roda em um único máquina e não simula adequadamente um cluster real com múltiplos nos, rede entre nos e armazenamento persistente real. O bare-metal com hardware separado e muito mais próximo de produção.

VMs locais com Vagrant/VirtualBox: alternativa viável sem gastar em hardware, mas compartilha os recursos de uma única máquina. Para aprender conceitos básicos funciona bem. Para performance real e simulação de falhas de hardware, o bare-metal e superior.

🚀
Pro tip

Use o Talos Linux se o objetivo e aprender Kubernetes de produção. Ele força você a usar práticas corretas (sem SSH, gerenciamento via GitOps) e e o que muitos clusters de produção real usam. K3s e mais amigável para começar, mas Talos ensina mais.

Pontos positivos e limitações

Os benefícios de ter um homelab bare-metal são claros: custo operacional baixo depois do investimento inicial, total controle para experimentar sem medo de gastar em cloud, e um ambiente que realmente prepara para operar Kubernetes em produção. Você vai entender ingress, CNI, storage classes e node maintenance de uma forma que nenhum tutorial abstrato consegue ensinar.

As limitações são igualmente reais. Hardware falha, e você cuida disso. Energia vai faltar eventualmente. Atualizações do Kubernetes requerem planejamento manual. Não existe suporte técnico além da comunidade. Para um homelab de aprendizado, tudo isso é parte do exercício. Para produção com SLA, cloud gerenciada continua sendo a escolha certa na maioria dos casos.

Casos de uso reais

Desenvolvedores que querem entender Kubernetes de verdade: rodar em bare-metal expõe cada detalhe que a nuvem esconde. Quem passou por isso tem muito mais confiança para trabalhar com clusters gerenciados em produção.

Times de plataforma e SRE: ter um lab físico para testar upgrades de Kubernetes, mudanças de CNI e procedimentos de recuperação de desastre sem risco de afetar produção e valioso.

Homelabbers que querem self-hosting: rodar serviços pessoais (Nextcloud, Gitea, Jellyfin, Bitwarden) em Kubernetes próprio tem custo elétrico mínimo e total privacidade dos dados.

Educadores e instrutores de DevOps: um cluster físico para aulas e demonstrações ao vivo e muito mais impactante do que slides. Hardware barato de segunda mao viabiliza isso mesmo com orçamento limitado.

Dicas e boas práticas

💡
Dica

Comece com k3s em três nos antes de tentar Talos ou kubeadm. K3s tem a menor curva de entrada e você pode migrar depois quando entender o básico do cluster.

⚠️
Atenção

Use SSD para todos os nos, especialmente o control plane. O etcd e extremamente sensível a latência de I/O. Cartão SD e eMMC de baixa qualidade causam problemas de corrupção e morte do cluster.

💡
Dica

Configure backups do etcd desde o inicio. No k3s: k3s etcd-snapshot save. Sem backup, qualquer falha do control plane pode significar perder toda a configuração do cluster.

🚀
Pro tip

Use um nobreak (UPS) pequeno nos nos de controle. Quedas de energia durante escritas do etcd são a principal causa de corrupção de cluster em homelab. Um nobreak de 300VA custa menos de R$ 200 e elimina 90% dos problemas de corrupção.

Vale a pena?

Para aprender DevOps e Kubernetes de verdade, sim, definitivamente vale. O custo de entrada de R$ 1000 a R$ 2000 em hardware e inferior ao custo de três meses de um cluster mínimo em nuvem pública, e o aprendizado e muito mais profundo porque você lidar com todos os detalhes da infraestrutura.

Se o objetivo e apenas usar Kubernetes para rodar aplicações sem aprender a operar a infraestrutura, os serviços gerenciados de nuvem continuam sendo a escolha mais sensata. A beleza do homelab e precisamente a frição que ele introduz.

O próximo passo: leia o artigo original no Dev.to (link abaixo), liste o hardware que você tem disponível ou quanto esta disposto a investir, e escolha entre k3s (mais fácil) e Talos (mais realista) para começar. Mesmo um cluster de dois nos em dois Raspberry Pi já ensina muito.