Docker, Kubernetes, RKE2 y K3s — qué son, cuándo tiene sentido el cambio, y cómo probarlo sin arriesgar producción.
La conversación sobre VMs vs contenedores lleva años circulando en foros técnicos, casi siempre desde un ángulo purista: “los contenedores son el futuro” o “las VMs siguen siendo más seguras”. Ninguno de esos argumentos le sirve a un equipo que necesita tomar una decisión real con infraestructura real y presupuesto limitado.
La pregunta correcta no es cuál tecnología es mejor. Es cuál tiene sentido para tu operación, en este momento, con el equipo que tienes.
Lo esencial
- Los contenedores permiten correr 50–100 instancias donde antes corrías 10 VMs — en el mismo hardware
- Kubernetes orquesta esos contenedores, pero tiene una curva de aprendizaje que muchos equipos subestiman
- K3s te permite probar Kubernetes en producción en menos de 5 minutos, sin AWS ni tarjeta de crédito
- RKE2 es la opción cuando necesitas cumplimiento normativo (CIS Benchmark, FIPS 140-2) en on-premise
- La decisión no es técnica — es financiera y de capacidad del equipo
La diferencia que importa: VMs vs contenedores
Imagina un edificio de apartamentos. Una máquina virtual es como rentar un apartamento completo: tienes tu propio espacio, tu propia cocina, tu propio sistema eléctrico. Todo separado. Todo tuyo. Y todo pagado, aunque solo uses una habitación.
Un contenedor es más parecido a un cohousing: compartes la estructura del edificio — el kernel del sistema operativo — pero cada habitación tiene su propio espacio, sus propios recursos, su propia configuración. Más eficiente, más denso, más económico. El mismo servidor que antes corría 10 VMs puede correr 50 a 100 contenedores.
Docker empaqueta esas habitaciones. Kubernetes administra cuando hay cientos de ellas y necesitas que se escalen, reinicien o redistribuyan automáticamente.
| Máquinas virtuales | Contenedores | |
|---|---|---|
| Aislamiento | Completo (SO propio) | Compartido (kernel del host) |
| Densidad | Baja — 10 VMs por servidor | Alta — 50–100 por servidor |
| Ideal para | Aplicaciones legacy | Microservicios y APIs |
| Boot | Minutos | Milisegundos |
| Costo | Mayor (recursos reservados) | Menor (pagan lo que usan) |
| Madurez | Probada en producción | Estándar moderno |
El argumento económico: por qué el mundo se movió
No fue por moda. Fue por un problema concreto: las VMs desperdician recursos. Una VM asignada con 8 GB de RAM los reserva aunque la aplicación use 1.5 GB. En la nube, ese desperdicio se convierte directamente en factura.
Los contenedores comparten recursos del host de forma eficiente. Para empresas que pagan infraestructura en dólares — y en LATAM eso duele doble con el tipo de cambio — ese número importa.
Contexto LATAM
Pagar servicios de infraestructura en dólares mientras se opera en pesos, reales o soles añade una variable de riesgo cambiario real. Optimizar el uso de recursos no es solo eficiencia técnica — es gestión financiera.
Una empresa SaaS en Bogotá tenía 12 servidores virtuales en AWS. Ocho corrían al 15% de uso. Pagaban por recursos que nadie consumía. Migraron a contenedores en 3 meses y redujeron su factura de infraestructura un 38%. Otra en Ciudad de México hizo lo mismo sin estrategia — y tardó un año en estabilizarse.
La diferencia no fue la tecnología. Fue saber cuándo y cómo.
Si este análisis te resulta útil, recíbelo cada semana: 👉 Suscríbete al newsletter de DacmosGroup
Lo que nadie te dice sobre Kubernetes
Kubernetes es poderoso. También es complejo. Tiene una curva de aprendizaje real, requiere conocimiento especializado para configurarlo bien y puede convertirse en el nuevo cuello de botella si el equipo no está preparado.
El error más común: asumir que contenedores + Kubernetes es el paso natural después de las VMs. Hay una escala intermedia que muchas organizaciones ignoran — y que puede ahorrarte meses de fricciones.
Punto clave
Kubernetes completo tiene sentido cuando: tu equipo ya maneja Docker con soltura, tienes múltiples servicios con necesidades de escala independiente, hay al menos un ingeniero DevOps o SRE dedicado, y el volumen de la operación justifica la inversión en setup. Si alguna de estas condiciones falta, empieza por K3s.
RKE2 y K3s: el camino inteligente para empezar
Antes de comprometerte con un clúster completo en producción, existe una ruta que muchos pasan por alto: probar Kubernetes en tu propio hardware, sin depender de AWS ni pagar en dólares.
K3s — Kubernetes para empezar hoy
K3s es una distribución ligera de Kubernetes creada por Rancher (ahora SUSE). Pesa menos de 100 MB, corre en una Raspberry Pi, en una VM local o en un servidor bare-metal. Es Kubernetes certificado, pero sin la complejidad de instalación del proyecto original.
Ideal para equipos que quieren aprender Kubernetes sin montar un clúster complejo, entornos de desarrollo y staging on-premise, y pruebas de concepto antes de decidir si se escala a producción.
En menos de 5 minutos tienes Kubernetes corriendo en un servidor local. Sin cuenta de AWS. Sin tarjeta de crédito. Sin sorpresas en la factura.
RKE2 — para cuando necesitas más solidez
RKE2 (Rancher Kubernetes Engine 2) es la evolución de RKE1, enfocada en seguridad y cumplimiento normativo. Cumple con CIS Benchmark y FIPS 140-2 — relevante si operas en sectores regulados como finanzas o salud en LATAM.
A diferencia de K3s, RKE2 está diseñado para clústeres multi-nodo en producción on-premise. Es la opción cuando ya validaste con K3s y quieres una base más robusta sin ir a la nube pública.
La ruta recomendada
Empieza con K3s en un servidor de prueba. Familiarízate con pods, deployments, services e ingress. Cuando sientas confianza, evalúa si K3s es suficiente o si necesitas RKE2 para producción. Solo entonces considera la nube pública si el on-premise no escala.
¿Cuándo migrar y cuándo quedarse con VMs?
Migrar a contenedores tiene sentido si:
- Tus VMs están sobreasignadas y la factura crece sin que crezca el uso real
- Tu equipo ya trabaja con CI/CD y despliegues frecuentes
- Tienes arquitectura de microservicios o estás descomponiendo un monolito
- Necesitas consistencia entre entornos: dev, staging y producción idénticos
Mantener VMs tiene sentido si:
- Tienes aplicaciones legacy que no están diseñadas para contenedores
- Operas en sectores con requisitos de aislamiento estrictos sin tiempo para adaptar
- El equipo no tiene experiencia y el costo de capacitación supera el ahorro proyectado
- La infraestructura actual funciona bien y no hay presión de escala
La decisión real no es técnica
Como casi todas las decisiones de infraestructura, esta no se resuelve eligiendo la tecnología más moderna. Se resuelve respondiendo tres preguntas concretas:
¿Cuál es el costo real de mi infraestructura actual y dónde está el desperdicio?
¿Mi equipo tiene la capacidad de gestionar la nueva tecnología o necesito apoyo externo?
¿El beneficio proyectado justifica el costo y el tiempo de transición?
Si aún estás evaluando si la migración a la nube tiene sentido para tu empresa antes de este paso, revisa primero Migración a la Nube para PyMEs: guía esencial y 4 errores a evitar.
Las empresas que migran bien no son las que tienen más presupuesto. Son las que entienden su punto de partida antes de elegir su destino.
K3s te da la respuesta más honesta: instálalo en un fin de semana, despliega tus servicios en un entorno de prueba y mide cuánto esfuerzo real requiere tu equipo. Ese experimento vale más que cualquier análisis teórico.
¿Tienes preguntas sobre tu caso específico? En DacmosGroup analizamos infraestructura TIC para empresas medianas en LATAM. Escríbenos aquí.
👉 Recibe análisis como este cada semana — Newsletter DacmosGroup
Hola Giovanni, muy buen artículo.
Me pareció excelente la analogía del edificio y el enfoque práctico con K3s y RKE2. El punto sobre probar Kubernetes en menos de 5 minutos sin AWS es muy valioso para equipos en LATAM con presupuestos ajustados.
También destaco la claridad al explicar cuándo quedarse con VMs (legacy o aislamiento estricto) en lugar de forzar una migración.
Una pregunta: para un equipo pequeño que tiene una mezcla de aplicaciones legacy y microservicios nuevos, ¿recomiendas empezar con un enfoque híbrido (VMs + K3s en paralelo) o hay una ruta más directa?
Gracias por compartir guías tan aplicables.
¡Saludos!