k3s vs HeroCtl: quando você precisa de Kubernetes leve e quando não precisa de Kubernetes

A pergunta chega quase semanal na nossa caixa de entrada: "vocês são tipo um k3s, né?". A resposta curta é não. A resposta longa começa percebendo que k3s e HeroCtl são confundidos porque ocupam o mesmo espaço mental — "orquestração sem a complexidade do Kubernetes pleno" — mas resolvem problemas que só parecem iguais por fora. k3s é Kubernetes, destilado. HeroCtl não é Kubernetes, e essa diferença muda tudo o que vem depois: o que você lê, o que você instala, o que você contrata, o que você comemora aos sábados.

Este post é pra tech leads que conhecem K8s o suficiente pra ter cicatrizes e estão considerando alguma alternativa mais leve. A intenção não é convencer ninguém a abandonar Kubernetes — Kubernetes é a escolha certa pra muito caso. A intenção é dar o mapa pra você decidir entre k3s e HeroCtl sem misturar as premissas dos dois.

O que k3s é, exatamente

k3s é uma distribuição de Kubernetes mantida pela Rancher (hoje SUSE). É Kubernetes pleno e certificado pela CNCF — a mesma API, os mesmos controladores, o mesmo modelo de objeto. O que muda é o empacotamento.

Em vez de cinco a sete componentes separados rodando como serviços de sistema, k3s entrega um único binário de cerca de 50 MB que sobe API server, scheduler, controller manager, kubelet e container runtime numa única árvore de processos. O armazenamento padrão é SQLite em vez do banco distribuído tradicional do Kubernetes — você pode trocar pelo banco distribuído quando quiser HA real, ou usar um cluster externo de banco SQL via driver kine. Os plugins de provedor de nuvem foram removidos do binário — se você precisa deles, instala separado.

A instalação cabe num comando, sobe em menos de 30 segundos num servidor modesto, e o requisito mínimo de RAM é 512 MB. Funciona em Raspberry Pi. Funciona em uma VPS de 5 dólares. Funciona em hardware industrial sem ventoinha rodando dentro de uma caixa de aço numa fábrica.

O ponto mais importante: kubectl, manifestos K8s, operators, charts de templating e tudo mais que você aprendeu sobre Kubernetes funcionam idênticos. Um cluster k3s aceita os mesmos arquivos YAML que um cluster gerenciado da AWS aceita. A migração de um pra outro é, na prática, copiar manifestos. Compatibilidade é a feature.

O que k3s NÃO faz, mesmo sendo "leve"

A palavra "leve" engana. k3s é leve em footprint (RAM, disco, número de processos), não em modelo mental. O que ele tira é a barreira de instalação e a dependência de cinco serviços externos pra subir. O que ele mantém é tudo que torna Kubernetes Kubernetes:

• Manifesto de "hello world" continua passando das 100 linhas quando você adiciona Service, Ingress e ConfigMap. Adicionando TLS automático e RBAC mínimo, vai pra 300+.
• Você continua precisando entender namespaces, services, ingress, persistent volumes, secrets, configmaps, RBAC, network policies, pod disruption budgets, liveness/readiness probes, init containers, sidecars, taints, tolerations, affinity rules, e assim por diante.
• Operators e charts de templating continuam sendo o caminho idiomático pra qualquer coisa não-trivial. Postgres replicado? Operator. Kafka? Operator. Certificados automáticos? Operator. Métricas? Stack de três produtos.
• A curva de aprendizado é praticamente a mesma. k3s tira talvez 10% — o pedaço de "instalar e manter o plano de controle". Os 90% restantes — entender como o sistema modela aplicações, como os controladores reconciliam estado, como debugar quando uma probe começa a falhar — continuam ali, intactos.

Se um SRE veterano olha pra um manifesto k3s, ele se sente em casa. Se um desenvolvedor de produto que nunca tocou Kubernetes olha pra esse mesmo manifesto, ele se sente exatamente tão perdido quanto se estivesse olhando pra um manifesto de cluster gerenciado.

Quem deve usar k3s (perfil real)

Vamos ser concretos. k3s faz sentido pra:

Times que já falam Kubernetes fluente e querem rodar em hardware barato. Edge computing, IoT, lojas físicas com servidor local, fábricas com gateways industriais, ambientes on-prem com hardware modesto. O time já sabe operar K8s — k3s só permite levar essa expertise pra lugares onde um plano de controle de 4 GB de RAM seria inviável.

Empresa migrando de Kubernetes gerenciado pra self-managed pra reduzir custo. Cluster gerenciado em provedor de nuvem cobra cerca de US$73/mês só pelo plano de controle, multiplicado pelo número de clusters. Some NAT, balanceadores de carga, observabilidade — fica caro. Quem já pagou esse pedágio e quer parar pode subir k3s em VPS comuns e cortar a conta em ordem de magnitude. A operação não fica mais simples; o boleto fica menor.

Workloads que dependem do ecossistema CNCF. Operators maduros pra Postgres com replicação automática (CloudNativePG, Zalando), Kafka (Strimzi), Cassandra, Elasticsearch — esses operators existem porque alguém investiu três anos polindo. Se a sua arquitetura depende de quatro deles em produção, você quer Kubernetes pleno, e k3s te dá Kubernetes pleno.

Quem quer ferramentas K8s-compatíveis funcionando 1:1. kubectl, charts de templating, ArgoCD pra GitOps, ferramentas de scanning de imagem, ferramentas de policy como OPA Gatekeeper. Se o seu pipeline de CI/CD existente usa essas ferramentas, k3s mantém todas funcionando sem adaptação.

Compliance que exige distribuição CNCF-certified. Alguns frameworks de auditoria pedem nominalmente uma distribuição certificada. k3s aparece nessa lista. HeroCtl não — somos jovens demais pra estar em qualquer lista, e nossa proposta é diferente o suficiente pra que algumas listas nunca venham a nos incluir.

O que HeroCtl é, exatamente

HeroCtl é um orquestrador independente. Não é uma distribuição derivada de Kubernetes; não compartilha API; não usa os mesmos primitivos. É uma camada diferente que atende uma intenção parecida — rodar contêineres em vários servidores com alta disponibilidade real — usando outro vocabulário e outras decisões de design.

Concretamente: um único arquivo executável que você instala em N servidores Linux. Os primeiros três viram quórum pro plano de controle replicado. Você submete jobs via CLI, API ou painel web embutido. Um job é um arquivo de configuração de cerca de 50 linhas que descreve a aplicação inteira — incluindo réplicas, ingress, certificados, segredos. O cluster decide onde rodar, faz health check, gerencia rolling deploys, emite certificados automáticos via roteador integrado.

Não há operadores especializados pra instalar, não há stacks de observabilidade montadas em separado, não há malha de serviço configurada à parte. Métricas persistentes rodam como job do próprio sistema. Logs têm escritor único embutido. Criptografia entre serviços e gerenciamento de chaves vêm prontos. Ingress com TLS automático é parte do binário.

A consequência é um modelo operacional curto. Subir uma aplicação nova é descrever, submeter, esperar — e o cluster cuida de roteamento, certificado, replicação, métricas e health check sem que você instale nada extra.

O que HeroCtl NÃO faz (limites honestos)

Não é compatível com a API do Kubernetes. kubectl não conversa com HeroCtl. Charts de templating não rodam. Manifestos K8s não são aceitos. Se a sua dependência crítica é uma ferramenta do ecossistema CNCF que fala com a API do Kubernetes, HeroCtl não substitui — é uma ferramenta diferente, com vocabulário próprio.

Não tem ecossistema de operadores especializados. Não há um operador maduro de Postgres com replicação automática esperando pra ser instalado. Você roda Postgres como um job comum e cuida de backup e replicação como humano cuida — não delega pra controlador externo. Pra muitos times isso é alívio; pra outros é regressão.

Faixa de escala recomendada vai de 1 a 500 servidores. Testamos até centenas em laboratório, validamos algumas dezenas em produção. Acima disso, Kubernetes (pleno ou em distribuição como k3s) ganha por ecossistema — ferramentas de federação multi-cluster, autoscaling cruzado entre regiões, primitivas de migração de armazenamento entre nuvens existem ali e ainda não existem aqui.

Federação multi-cluster não é nativa. Se você precisa de várias regiões orquestradas como uma única superfície, com workloads se movendo automaticamente entre elas, ferramentas como Rancher Fleet ou os recursos multi-cluster do Kubernetes resolvem hoje. HeroCtl não.

Compliance que lista Kubernetes nominalmente. Se a sua certificação exige nominalmente uma distribuição certificada pela CNCF, HeroCtl não cumpre — somos um produto novo, jovem demais pra figurar em listas estabelecidas. k3s, OpenShift e Talos cumprem. Esse é o caminho.

Quem deve usar HeroCtl (perfil real)

Times que NÃO querem aprender Kubernetes mas precisam de orquestração com HA real. Painéis self-hosted populares funcionam bem em um servidor mas não têm consenso distribuído — quando você quer três servidores aguentando perda de um sem downtime, esses painéis não servem. Kubernetes serviria, mas custa um SRE no time. HeroCtl é o meio que faltava.

Indie hackers e startups até cerca de R$1M de receita anual. Stack típica: aplicação web, banco relacional, fila assíncrona, cache. Não há Kafka, não há Cassandra, não há sete operadores de banco. Pra esse perfil, o ecossistema CNCF é capacidade ociosa cara — você paga em curva de aprendizado e em complexidade operacional sem usar o que paga.

Aplicações web típicas sem dependências exóticas. HTTP em cima de banco SQL e cache em memória cobre talvez 70% do mercado SaaS. Pra esse pedaço, Kubernetes é overkill e HeroCtl é dimensionado.

Quem quer "simplicidade do Coolify com HA real". Coolify, Dokploy e similares acertaram a experiência mas erraram a alta disponibilidade. Kubernetes acertou a alta disponibilidade mas errou a experiência. HeroCtl tenta acertar os dois ao custo de não ser Kubernetes.

Compliance LGPD-only. Se o seu compliance é LGPD e contratos comerciais brasileiros, sem FedRAMP nem ITAR no horizonte, a ausência de certificações específicas não é bloqueio.

Lado a lado, sem floreio

A tabela abaixo cobre os critérios que mais aparecem na decisão. Cada linha tem ressalva — leia o texto.

A coluna que mais importa varia por contexto. Pra time que já tem expertise K8s, "compatibilidade kubectl" pesa muito. Pra time que está começando, "linhas pra hello world" e "curva de aprendizado" pesam mais.

Quando os dois estão na conversa (decisão prática)

Cinco cenários reais que aparecem em conversas com leitores. As respostas são diretas porque a realidade é direta.

"Já temos Kubernetes gerenciado e dói operacionalmente." k3s reduz custo cloud porque você sai do plano de controle pago. A dor operacional permanece — manifestos longos, operadores de TLS, stacks externas de observabilidade. Você economiza na fatura mas não no tempo. HeroCtl reduz a dor de raiz, mas exige aprender outra ferramenta e re-escrever as primitivas. Se a dor é financeira, k3s. Se a dor é tempo de engenharia, HeroCtl.

"Estamos começando agora, queremos algo simples." HeroCtl. Kubernetes (pleno ou k3s) adiciona meses de curva de aprendizado que não geram valor pro produto na fase inicial. Você passa três meses aprendendo charts de templating e ingress controllers em vez de shippar features. Em early-stage, custo de oportunidade é tudo.

"Compliance exige distribuição CNCF-certified." k3s ou Talos. HeroCtl não cumpre essa lista. Não é orgulho — é honestidade. Quando estivermos prontos pra essas listas, voltamos a conversar.

"Time tem 1 SRE forte que adora Kubernetes." k3s. Deixa o SRE feliz, mantém todo o conhecimento existente do time, e ainda corta a fatura cloud. HeroCtl forçaria o SRE a re-aprender e abandonar ferramentas que ele domina — fricção desnecessária quando a expertise já está paga.

"Time tem 0 SRE e cresce pelo produto." HeroCtl. Kubernetes sem expertise é receita pra desastre — você vai descobrir o que é um pod stuck em CrashLoopBackOff numa noite de sexta, sem ter contexto pra debugar. HeroCtl é dimensionado pra time que não tem plantão dedicado a infra.

A migração improvável

Migrar de k3s pra HeroCtl, ou vice-versa, é uma operação que parece pior do que é.

Conceitualmente, os dois são similares. Ambos rodam contêineres, ambos têm noção de réplicas, ambos têm ingress, ambos têm health check, ambos têm rolling deploy. Se você sabe fazer uma coisa, sabe pensar a outra.

Sintaticamente, são incompatíveis. Manifesto Kubernetes não converte 1:1 pra job spec HeroCtl. Os campos não casam, as abstrações não são as mesmas, os defaults são diferentes. Você re-escreve.

Re-escrever não é tão caro quanto parece. Pra time típico com 20 a 40 specs em produção, a migração toma uma tarde. O motivo é que a maioria dos manifestos K8s tem repetição estrutural enorme — 80% dos campos são padronizados, e você descobre rapidamente o mapeamento. Pra times com poucas dezenas de jobs, conversor manual basta. Acima disso, estamos abertos a conversar sobre conversores experimentais.

A migração do outro lado (HeroCtl → k3s) é mais cara, porque você está saindo de um modelo enxuto pra um modelo verboso. Você ganha ecossistema; paga em verbosidade.

Custo concreto comparado

Cenário: 4 VPS em provedor europeu de baixo custo, cada uma com 4 vCPU e 8 GB de RAM. Custo de infraestrutura: cerca de R$100/mês por VPS, R$400/mês total.

k3s self-managed nesse cenário custa R$400/mês de infra mais salário parcial de SRE. SRE forte no Brasil custa R$15k a R$25k/mês cheio. Ainda que você aloque só 30% do tempo dele pro cluster — o que é otimista pra time pequeno — são R$5k a R$7,5k de custo de gente. Total: R$5,4k a R$7,9k/mês.

HeroCtl Community no mesmo cenário custa R$400/mês de infra mais alocação de dev part-time pro cluster. Como o modelo operacional é mais curto, 10% do tempo de um dev sênior basta — R$1,5k a R$2,5k/mês. Total: R$1,9k a R$2,9k/mês.

A diferença está no salário de gente. k3s pede mais expertise; mais expertise custa mais. A infra é praticamente igual.

Esse cálculo se inverte quando o time já tem SRE pago independentemente da escolha de orquestrador. Se o SRE existe pelo resto da stack, o custo marginal de operar k3s é baixo, e o ecossistema CNCF passa a valer ouro. É outro tipo de empresa.

FAQ

k3s ainda é Kubernetes pleno? Sim. k3s é certificado pela CNCF como distribuição conformante. Os mesmos manifestos rodam, kubectl funciona idêntico, a API é a mesma. As remoções foram de dependências e plugins de nuvem — não da API nem da semântica.

HeroCtl pode rodar em Raspberry Pi como k3s? Tecnicamente, sim — HeroCtl roda em qualquer servidor Linux com Docker, incluindo ARM. Praticamente, o caso de uso "edge em Raspberry Pi" é território onde k3s tem anos de polimento e HeroCtl ainda não foi exercitado o bastante. Se o seu uso é edge industrial em hardware ARM modesto, k3s é a escolha mais batida hoje. HeroCtl em Pi funciona pra hobby; pra produção edge, espere mais alguns trimestres.

kubectl funciona no HeroCtl? Não. HeroCtl tem CLI própria e API própria. A intenção foi diferente desde o início — não tentamos ser compatíveis com Kubernetes. Quem quer kubectl quer Kubernetes; é a ferramenta certa pra essa pessoa.

Como migrar de Kubernetes gerenciado pra k3s? A maioria dos manifestos roda direto. As exceções costumam ser: anotações específicas do provedor de nuvem (load balancer, storage class), integrações de IAM nativas e algum ingress controller que assumia infraestrutura cloud. Você troca por equivalentes do ecossistema CNCF (MetalLB pra LB, longhorn ou storage local pra volumes) e refaz as anotações. Pra cluster com poucas dezenas de manifestos, a migração leva alguns dias.

HeroCtl tem multi-region como Rancher Fleet? Não nativo. Hoje o quórum do plano de controle é dimensionado pra um cluster por região. Você pode operar HeroCtl em várias regiões em paralelo, cada uma com seu cluster, mas não há hoje uma camada de federação que apresente todos como superfície única. Está no roadmap. Quem precisa disso hoje, k3s + Rancher Fleet ou Kubernetes pleno + Karmada são caminhos exercitados.

Qual escala mais alto? Kubernetes (pleno ou k3s). Empresas operam clusters K8s com dezenas de milhares de nós em produção. HeroCtl mira faixa "1 a 500 servidores" e não pretende competir acima disso. Se você opera no nível de centenas de milhares de máquinas, K8s é o caminho — não por escolha, por dimensionamento.

Posso rodar os dois lado a lado? Sim. Ambos são orquestradores que rodam contêineres em servidores Linux. Você pode ter um cluster k3s pra workloads que dependem do ecossistema CNCF e um cluster HeroCtl pra apps web típicas — eles não conflitam, são produtos diferentes. Alguns clientes nossos fazem exatamente isso: HeroCtl pro produto principal, k3s pra ambiente de testes que precisa imitar o cluster gerenciado de produção do cliente final.

Fechamento honesto

A pergunta inicial — "vocês são tipo um k3s, né?" — tem agora uma resposta longa. Não somos. k3s é Kubernetes empacotado pra caber em hardware modesto, mantendo intacta toda a curva de aprendizado e todo o ecossistema. HeroCtl é uma camada diferente de Kubernetes, com vocabulário próprio, modelo operacional mais curto, sem ecossistema de operadores e sem compatibilidade com kubectl.

Se você já fala Kubernetes fluente e quer levar essa expertise pra hardware barato ou edge, k3s é a escolha. Se você nunca quis aprender Kubernetes mas precisa de orquestração com alta disponibilidade real, HeroCtl é a escolha. Se a sua dor é compliance que lista distribuições certificadas, k3s ou Talos. Se a sua dor é tempo de engenharia gasto em manifestos longos e operadores externos, HeroCtl.

Não há vencedor universal — há ferramentas que combinam com contextos diferentes. A escolha errada não é nem k3s nem HeroCtl; é adotar qualquer uma das duas sem entender qual problema você está realmente resolvendo.

Quem quiser experimentar HeroCtl no servidor mais próximo, o caminho é único:

curl -sSL get.heroctl.com/install.sh | sh

Cinco minutos depois você tem um cluster de um nó rodando. Adicione mais dois servidores com o mesmo comando + token, e tem alta disponibilidade real — sem instalar operador externo, sem montar stack de observabilidade, sem aprender vocabulário novo de manifestos.

Pra continuar a leitura, dois posts conversam diretamente com este: Kubernetes é overkill: quando você não precisa trata da decisão geral de não adotar K8s; AWS ECS vs Kubernetes vs auto-hospedado compara as três famílias quando o servidor da nuvem está na mesa. E pra entender por que existimos como produto separado em vez de ser mais uma distribuição K8s, por que criamos o HeroCtl tem o histórico completo.

A intenção, como sempre, é simples: orquestração de contêineres, sem cerimônia — mas com honestidade sobre quando cerimônia é o que você precisa.