Rodar Kubernetes em bare-metal já foi sinônimo de “montar igreja”. Tinha muito trabalho invisível: provisionamento, upgrade, rede, storage, observabilidade. Muita gente tentou, pouca gente manteve com sanidade.
Em 2026, ainda dá trabalho. Só que a história ficou mais previsível. E previsibilidade é exatamente o que o ICP da Fixx precisa quando a fatura cloud vira risco de orçamento.
O que ainda é verdade (e ninguém deveria romantizar)
- Se você não tem observabilidade, você vai sofrer.
- Se você não automatiza deploy, você vai sofrer.
- Se você não testa restore/DR, você vai sofrer.
Bare-metal não perdoa “ops por sentimento”. Você tem que ter processo. A boa notícia: hoje dá pra ter processo sem virar um time de 20 pessoas.
O que ficou melhor: ciclo de vida do cluster
Um dos ganhos mais claros foi tratar cluster como algo que você provisiona e atualiza com o mesmo tipo de automação que já usa pra app.
Exemplo: Cluster API nasceu com esse objetivo de dar APIs declarativas e tooling pra provisionar, atualizar e operar clusters de forma consistente. Visão geral aqui: Kubernetes Cluster API.
Onde as pessoas ainda erram
O erro não é escolher bare-metal. O erro é escolher bare-metal e operar como se fosse cloud gerenciada.
| Expectativa | Realidade bare-metal | Como lidar |
|---|---|---|
| upgrade “aperta um botão” | upgrade é mudança controlada | janela, canary, rollback |
| storage é “só mais um serviço” | storage define a saúde do stateful | SLA, testes de restore |
| capacidade é elástica | capacidade é planejamento | métrica, headroom, compra |
Quando bare-metal vale a pena
- carga previsível (você sabe o que é “normal”)
- custo virou risco (surpresa no fechamento dói mais que preço médio)
- você quer controle (inclusive pra voltar pra cloud se precisar)
Se o seu negócio depende de pico imprevisível, o caminho saudável quase sempre é híbrido: manter burst na nuvem e trazer o previsível pra casa.
Se você quer uma arquitetura híbrida que não vira Frankenstein, chama a Fixx. contato@fixx.com.br