k3s vs HeroCtl: cuándo necesitas Kubernetes ligero y cuándo no necesitas Kubernetes

La pregunta llega casi semanalmente a nuestra bandeja de entrada: "¿ustedes son tipo un k3s, no?". La respuesta corta es no. La respuesta larga empieza percibiendo que k3s y HeroCtl se confunden porque ocupan el mismo espacio mental — "orquestación sin la complejidad de Kubernetes pleno" — pero resuelven problemas que solo parecen iguales por fuera. k3s es Kubernetes, destilado. HeroCtl no es Kubernetes, y esa diferencia cambia todo lo que viene después: lo que lees, lo que instalas, a quién contratas, qué celebras los sábados.

Este post es para tech leads que conocen K8s lo suficiente para tener cicatrices y están considerando alguna alternativa más ligera. La intención no es convencer a nadie de abandonar Kubernetes — Kubernetes es la elección correcta para muchos casos. La intención es dar el mapa para que decidas entre k3s y HeroCtl sin mezclar las premisas de los dos.

Qué es k3s, exactamente

k3s es una distribución de Kubernetes mantenida por Rancher (hoy SUSE). Es Kubernetes pleno y certificado por la CNCF — la misma API, los mismos controladores, el mismo modelo de objeto. Lo que cambia es el empaquetado.

En lugar de cinco a siete componentes separados corriendo como servicios de sistema, k3s entrega un único binario de cerca de 50 MB que sube API server, scheduler, controller manager, kubelet y container runtime en un único árbol de procesos. El almacenamiento por defecto es SQLite en lugar de la base distribuida tradicional de Kubernetes — puedes cambiar a la base distribuida cuando quieras HA real, o usar un cluster externo de base SQL vía driver kine. Los plugins de proveedor de nube fueron removidos del binario — si los necesitas, los instalas aparte.

La instalación cabe en un comando, sube en menos de 30 segundos en un servidor modesto, y el requisito mínimo de RAM es 512 MB. Funciona en Raspberry Pi. Funciona en una VPS de 5 dólares. Funciona en hardware industrial sin ventilador corriendo dentro de una caja de acero en una fábrica.

El punto más importante: kubectl, manifiestos K8s, operators, charts de templating y todo lo demás que aprendiste sobre Kubernetes funcionan idénticos. Un cluster k3s acepta los mismos archivos YAML que un cluster gestionado de AWS acepta. La migración de uno al otro es, en la práctica, copiar manifiestos. La compatibilidad es la feature.

Qué k3s NO hace, aun siendo "ligero"

La palabra "ligero" engaña. k3s es ligero en footprint (RAM, disco, número de procesos), no en modelo mental. Lo que quita es la barrera de instalación y la dependencia de cinco servicios externos para subir. Lo que mantiene es todo lo que vuelve a Kubernetes Kubernetes:

• Manifiesto de "hello world" sigue pasando de las 100 líneas cuando agregas Service, Ingress y ConfigMap. Agregando TLS automático y RBAC mínimo, va a 300+.
• Sigues necesitando entender namespaces, services, ingress, persistent volumes, secrets, configmaps, RBAC, network policies, pod disruption budgets, liveness/readiness probes, init containers, sidecars, taints, tolerations, affinity rules, y así sucesivamente.
• Operators y charts de templating siguen siendo el camino idiomático para cualquier cosa no trivial. ¿Postgres replicado? Operator. ¿Kafka? Operator. ¿Certificados automáticos? Operator. ¿Métricas? Stack de tres productos.
• La curva de aprendizaje es prácticamente la misma. k3s quita tal vez 10% — el pedazo de "instalar y mantener el plano de control". El 90% restante — entender cómo el sistema modela aplicaciones, cómo los controladores reconcilian estado, cómo depurar cuando una probe empieza a fallar — sigue ahí, intacto.

Si un SRE veterano mira un manifiesto k3s, se siente en casa. Si un desarrollador de producto que nunca tocó Kubernetes mira ese mismo manifiesto, se siente exactamente tan perdido como si estuviera mirando un manifiesto de cluster gestionado.

Quién debe usar k3s (perfil real)

Vamos a ser concretos. k3s tiene sentido para:

Equipos que ya hablan Kubernetes fluidamente y quieren correr en hardware barato. Edge computing, IoT, tiendas físicas con servidor local, fábricas con gateways industriales, ambientes on-prem con hardware modesto. El equipo ya sabe operar K8s — k3s solo permite llevar esa expertise a lugares donde un plano de control de 4 GB de RAM sería inviable.

Empresa migrando de Kubernetes gestionado a self-managed para reducir costo. Cluster gestionado en proveedor de nube cobra cerca de US$73/mes solo por el plano de control, multiplicado por el número de clusters. Suma NAT, balanceadores de carga, observabilidad — sale caro. Quien ya pagó ese peaje y quiere parar puede subir k3s en VPS comunes y cortar la cuenta en orden de magnitud. La operación no se vuelve más simple; la factura se vuelve menor.

Workloads que dependen del ecosistema CNCF. Operators maduros para Postgres con replicación automática (CloudNativePG, Zalando), Kafka (Strimzi), Cassandra, Elasticsearch — esos operators existen porque alguien invirtió tres años puliendo. Si tu arquitectura depende de cuatro de ellos en producción, quieres Kubernetes pleno, y k3s te da Kubernetes pleno.

Quien quiere herramientas K8s-compatibles funcionando 1:1. kubectl, charts de templating, ArgoCD para GitOps, herramientas de scanning de imagen, herramientas de policy como OPA Gatekeeper. Si tu pipeline de CI/CD existente usa esas herramientas, k3s mantiene todas funcionando sin adaptación.

Compliance que exige distribución CNCF-certified. Algunos frameworks de auditoría piden nominalmente una distribución certificada. k3s aparece en esa lista. HeroCtl no — somos demasiado jóvenes para estar en cualquier lista, y nuestra propuesta es lo suficientemente diferente para que algunas listas nunca lleguen a incluirnos.

Qué es HeroCtl, exactamente

HeroCtl es un orquestador independiente. No es una distribución derivada de Kubernetes; no comparte API; no usa los mismos primitivos. Es una capa diferente que atiende una intención parecida — correr contenedores en varios servidores con alta disponibilidad real — usando otro vocabulario y otras decisiones de diseño.

Concretamente: un único archivo ejecutable que instalas en N servidores Linux. Los primeros tres se vuelven quórum para el plano de control replicado. Sometes jobs vía CLI, API o panel web embebido. Un job es un archivo de configuración de cerca de 50 líneas que describe la aplicación entera — incluyendo réplicas, ingress, certificados, secretos. El cluster decide dónde correr, hace health check, gestiona rolling updates, emite certificados automáticos vía router integrado.

No hay operadores especializados que instalar, no hay stacks de observabilidad montadas por separado, no hay malla de servicio configurada aparte. Métricas persistentes corren como job del propio sistema. Logs tienen escritor único embebido. Cifrado entre servicios y gestión de claves vienen listos. Ingress con TLS automático es parte del binario.

La consecuencia es un modelo operacional corto. Subir una aplicación nueva es describir, someter, esperar — y el cluster cuida de ruteo, certificado, replicación, métricas y health check sin que instales nada extra.

Qué HeroCtl NO hace (límites honestos)

No es compatible con la API de Kubernetes. kubectl no conversa con HeroCtl. Charts de templating no corren. Manifiestos K8s no son aceptados. Si tu dependencia crítica es una herramienta del ecosistema CNCF que habla con la API de Kubernetes, HeroCtl no sustituye — es una herramienta diferente, con vocabulario propio.

No tiene ecosistema de operadores especializados. No hay un operador maduro de Postgres con replicación automática esperando ser instalado. Corres Postgres como un job común y cuidas backup y replicación como humano cuida — no delegas a controlador externo. Para muchos equipos eso es alivio; para otros es regresión.

Rango de escala recomendado va de 1 a 500 servidores. Probamos hasta cientos en laboratorio, validamos algunas decenas en producción. Por encima de eso, Kubernetes (pleno o en distribución como k3s) gana por ecosistema — herramientas de federación multi-cluster, autoscaling cruzado entre regiones, primitivas de migración de almacenamiento entre nubes existen ahí y todavía no existen aquí.

Federación multi-cluster no es nativa. Si necesitas varias regiones orquestadas como una única superficie, con workloads moviéndose automáticamente entre ellas, herramientas como Rancher Fleet o los recursos multi-cluster de Kubernetes resuelven hoy. HeroCtl no.

Compliance que lista Kubernetes nominalmente. Si tu certificación exige nominalmente una distribución certificada por la CNCF, HeroCtl no cumple — somos un producto nuevo, demasiado joven para figurar en listas establecidas. k3s, OpenShift y Talos cumplen. Ese es el camino.

Quién debe usar HeroCtl (perfil real)

Equipos que NO quieren aprender Kubernetes pero necesitan orquestación con HA real. Paneles self-hosted populares funcionan bien en un servidor pero no tienen consenso distribuido — cuando quieres tres servidores aguantando pérdida de uno sin downtime, esos paneles no sirven. Kubernetes serviría, pero cuesta un SRE en el equipo. HeroCtl es el medio que faltaba.

Indie hackers y startups hasta cerca de R$1M de ingresos anuales. Stack típica: aplicación web, base relacional, cola asíncrona, cache. No hay Kafka, no hay Cassandra, no hay siete operadores de base. Para ese perfil, el ecosistema CNCF es capacidad ociosa cara — pagas en curva de aprendizaje y en complejidad operacional sin usar lo que pagas.

Aplicaciones web típicas sin dependencias exóticas. HTTP encima de base SQL y cache en memoria cubre tal vez 70% del mercado SaaS. Para ese pedazo, Kubernetes es overkill y HeroCtl está dimensionado.

Quien quiere "simplicidad de Coolify con HA real". Coolify, Dokploy y similares acertaron la experiencia pero erraron la alta disponibilidad. Kubernetes acertó la alta disponibilidad pero erró la experiencia. HeroCtl intenta acertar los dos al costo de no ser Kubernetes.

Compliance LGPD-only. Si tu compliance es LGPD y contratos comerciales brasileños, sin FedRAMP ni ITAR en el horizonte, la ausencia de certificaciones específicas no es bloqueo.

Lado a lado, sin adornos

La tabla abajo cubre los criterios que más aparecen en la decisión. Cada línea tiene reserva — lee el texto.

La columna que más importa varía por contexto. Para equipo que ya tiene expertise K8s, "compatibilidad kubectl" pesa mucho. Para equipo que está empezando, "líneas para hello world" y "curva de aprendizaje" pesan más.

Cuando los dos están en la conversación (decisión práctica)

Cinco escenarios reales que aparecen en conversaciones con lectores. Las respuestas son directas porque la realidad es directa.

"Ya tenemos Kubernetes gestionado y duele operacionalmente." k3s reduce costo cloud porque sales del plano de control pagado. El dolor operacional permanece — manifiestos largos, operadores de TLS, stacks externas de observabilidad. Ahorras en la factura pero no en el tiempo. HeroCtl reduce el dolor de raíz, pero exige aprender otra herramienta y reescribir los primitivos. Si el dolor es financiero, k3s. Si el dolor es tiempo de ingeniería, HeroCtl.

"Estamos empezando ahora, queremos algo simple." HeroCtl. Kubernetes (pleno o k3s) agrega meses de curva de aprendizaje que no generan valor para el producto en la fase inicial. Pasas tres meses aprendiendo charts de templating e ingress controllers en lugar de shippar features. En early-stage, el costo de oportunidad es todo.

"Compliance exige distribución CNCF-certified." k3s o Talos. HeroCtl no cumple esa lista. No es orgullo — es honestidad. Cuando estemos listos para esas listas, volvemos a conversar.

"El equipo tiene 1 SRE fuerte que adora Kubernetes." k3s. Deja al SRE feliz, mantiene todo el conocimiento existente del equipo, y aún así corta la factura cloud. HeroCtl forzaría al SRE a reaprender y abandonar herramientas que domina — fricción innecesaria cuando la expertise ya está pagada.

"El equipo tiene 0 SRE y crece por el producto." HeroCtl. Kubernetes sin expertise es receta para desastre — vas a descubrir qué es un pod stuck en CrashLoopBackOff en una noche de viernes, sin tener contexto para depurar. HeroCtl está dimensionado para equipo que no tiene guardia dedicada a infra.

La migración improbable

Migrar de k3s a HeroCtl, o viceversa, es una operación que parece peor de lo que es.

Conceptualmente, los dos son similares. Ambos corren contenedores, ambos tienen noción de réplicas, ambos tienen ingress, ambos tienen health check, ambos tienen rolling update. Si sabes hacer una cosa, sabes pensar la otra.

Sintácticamente, son incompatibles. Manifiesto Kubernetes no convierte 1:1 a job spec HeroCtl. Los campos no encajan, las abstracciones no son las mismas, los defaults son diferentes. Reescribes.

Reescribir no es tan caro como parece. Para equipo típico con 20 a 40 specs en producción, la migración toma una tarde. La razón es que la mayoría de los manifiestos K8s tiene repetición estructural enorme — 80% de los campos son estandarizados, y descubres rápidamente el mapeo. Para equipos con pocas decenas de jobs, conversor manual basta. Por encima de eso, estamos abiertos a conversar sobre conversores experimentales.

La migración del otro lado (HeroCtl → k3s) es más cara, porque estás saliendo de un modelo escueto para un modelo verboso. Ganas ecosistema; pagas en verbosidad.

Costo concreto comparado

Escenario: 4 VPS en proveedor europeo de bajo costo, cada una con 4 vCPU y 8 GB de RAM. Costo de infraestructura: cerca de R$100/mes por VPS, R$400/mes total.

k3s self-managed en ese escenario cuesta R$400/mes de infra más salario parcial de SRE. SRE fuerte en Brasil cuesta R$15k a R$25k/mes lleno. Aunque solo asignes 30% de su tiempo al cluster — lo que es optimista para equipo pequeño — son R$5k a R$7,5k de costo de gente. Total: R$5,4k a R$7,9k/mes.

HeroCtl Community en el mismo escenario cuesta R$400/mes de infra más asignación de dev part-time al cluster. Como el modelo operacional es más corto, 10% del tiempo de un dev sénior basta — R$1,5k a R$2,5k/mes. Total: R$1,9k a R$2,9k/mes.

La diferencia está en el salario de gente. k3s pide más expertise; más expertise cuesta más. La infra es prácticamente igual.

Ese cálculo se invierte cuando el equipo ya tiene SRE pagado independientemente de la elección de orquestador. Si el SRE existe por el resto del stack, el costo marginal de operar k3s es bajo, y el ecosistema CNCF pasa a valer oro. Es otro tipo de empresa.

FAQ

¿k3s sigue siendo Kubernetes pleno? Sí. k3s está certificado por la CNCF como distribución conformante. Los mismos manifiestos corren, kubectl funciona idéntico, la API es la misma. Las remociones fueron de dependencias y plugins de nube — no de la API ni de la semántica.

¿HeroCtl puede correr en Raspberry Pi como k3s? Técnicamente, sí — HeroCtl corre en cualquier servidor Linux con Docker, incluyendo ARM. Prácticamente, el caso de uso "edge en Raspberry Pi" es territorio donde k3s tiene años de pulido y HeroCtl todavía no fue ejercitado lo suficiente. Si tu uso es edge industrial en hardware ARM modesto, k3s es la elección más probada hoy. HeroCtl en Pi funciona para hobby; para producción edge, espera algunos trimestres más.

¿kubectl funciona en HeroCtl? No. HeroCtl tiene CLI propia y API propia. La intención fue diferente desde el inicio — no intentamos ser compatibles con Kubernetes. Quien quiere kubectl quiere Kubernetes; es la herramienta correcta para esa persona.

¿Cómo migrar de Kubernetes gestionado a k3s? La mayoría de los manifiestos corre directo. Las excepciones suelen ser: anotaciones específicas del proveedor de nube (load balancer, storage class), integraciones de IAM nativas y algún ingress controller que asumía infraestructura cloud. Cambias por equivalentes del ecosistema CNCF (MetalLB para LB, longhorn o storage local para volúmenes) y rehaces las anotaciones. Para cluster con pocas decenas de manifiestos, la migración lleva algunos días.

¿HeroCtl tiene multi-region como Rancher Fleet? No nativo. Hoy el quórum del plano de control está dimensionado para un cluster por región. Puedes operar HeroCtl en varias regiones en paralelo, cada una con su cluster, pero no hay hoy una capa de federación que presente todos como superficie única. Está en el roadmap. Quien necesita eso hoy, k3s + Rancher Fleet o Kubernetes pleno + Karmada son caminos ejercitados.

¿Cuál escala más alto? Kubernetes (pleno o k3s). Empresas operan clusters K8s con decenas de miles de nodos en producción. HeroCtl apunta al rango "1 a 500 servidores" y no pretende competir por encima de eso. Si operas en el nivel de cientos de miles de máquinas, K8s es el camino — no por elección, por dimensionamiento.

¿Puedo correr los dos lado a lado? Sí. Ambos son orquestadores que corren contenedores en servidores Linux. Puedes tener un cluster k3s para workloads que dependen del ecosistema CNCF y un cluster HeroCtl para apps web típicas — no entran en conflicto, son productos diferentes. Algunos clientes nuestros hacen exactamente eso: HeroCtl para el producto principal, k3s para ambiente de pruebas que necesita imitar el cluster gestionado de producción del cliente final.

Cierre honesto

La pregunta inicial — "¿ustedes son tipo un k3s, no?" — tiene ahora una respuesta larga. No lo somos. k3s es Kubernetes empaquetado para caber en hardware modesto, manteniendo intacta toda la curva de aprendizaje y todo el ecosistema. HeroCtl es una capa diferente de Kubernetes, con vocabulario propio, modelo operacional más corto, sin ecosistema de operadores y sin compatibilidad con kubectl.

Si ya hablas Kubernetes fluidamente y quieres llevar esa expertise a hardware barato o edge, k3s es la elección. Si nunca quisiste aprender Kubernetes pero necesitas orquestación con alta disponibilidad real, HeroCtl es la elección. Si tu dolor es compliance que lista distribuciones certificadas, k3s o Talos. Si tu dolor es tiempo de ingeniería gastado en manifiestos largos y operadores externos, HeroCtl.

No hay ganador universal — hay herramientas que combinan con contextos diferentes. La elección equivocada no es ni k3s ni HeroCtl; es adoptar cualquiera de las dos sin entender qué problema estás resolviendo realmente.

Quien quiera experimentar HeroCtl en el servidor más cercano, el camino es único:

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

Cinco minutos después tienes un cluster de un nodo corriendo. Agrega dos servidores más con el mismo comando + token, y tienes alta disponibilidad real — sin instalar operador externo, sin montar stack de observabilidad, sin aprender vocabulario nuevo de manifiestos.

Para continuar la lectura, dos posts conversan directamente con este: Kubernetes overkill: cuándo no lo necesitas trata de la decisión general de no adoptar K8s; AWS ECS vs Kubernetes vs auto-hospedado compara las tres familias cuando el servidor de la nube está en la mesa. Y para entender por qué existimos como producto separado en lugar de ser una distribución K8s más, por qué creamos HeroCtl tiene el historial completo.

La intención, como siempre, es simple: orquestación de contenedores, sin ceremonia — pero con honestidad sobre cuándo ceremonia es lo que necesitas.