La virtualización y la contenerización resuelven el mismo problema histórico desde dos niveles distintos de abstracción: cómo aislar y empaquetar software para que se ejecute de forma reproducible, independiente del hardware subyacente. La máquina virtual virtualiza el hardware completo y carga un sistema operativo invitado encima de un hipervisor (VMware ESXi, KVM, Hyper-V). El contenedor, en cambio, virtualiza el sistema operativo: comparte el kernel del anfitrión y aísla los procesos mediante primitivas del kernel de Linux como los namespaces (aislamiento de visibilidad) y los cgroups (control de recursos). Esa diferencia explica por qué un contenedor arranca en milisegundos y pesa megabytes, mientras una máquina virtual tarda segundos o minutos y ocupa gigabytes.
Docker popularizó los contenedores en 2013 al ofrecer una experiencia de empaquetado sencilla, y Kubernetes —liberado por Google en 2014 y hoy bajo la Cloud Native Computing Foundation— se ha convertido en el orquestador estándar para ejecutar contenedores a escala. En este artículo desglosamos ambas tecnologías con rigor técnico: cómo se construye una imagen, cómo orquesta Kubernetes, qué errores cuestan caros en producción y qué normativa de seguridad aplica.
Docker: imágenes, capas y el modelo de empaquetado
Una imagen Docker es una plantilla inmutable de solo lectura, construida en capas apiladas (cada instrucción del Dockerfile genera una capa) sobre un sistema de archivos union (overlayfs). Un contenedor es una instancia en ejecución de esa imagen, con una fina capa de escritura encima. Esta arquitectura de capas permite compartir capas comunes entre imágenes y acelerar las descargas, ya que solo se transfieren las capas nuevas.
El valor de Docker es la reproducibilidad: el clásico «en mi máquina funciona» desaparece porque la imagen contiene la aplicación y todas sus dependencias congeladas. Las buenas prácticas de construcción incluyen:
- Multi-stage builds: compilar en una imagen pesada y copiar solo el binario resultante a una imagen final mínima, reduciendo drásticamente el tamaño y la superficie de ataque.
- Imágenes base mínimas (Alpine, distroless) para limitar las dependencias vulnerables.
- Ejecutar como usuario no root con la directiva
USER, evitando que un escape de contenedor herede privilegios del anfitrión. - Inmutabilidad y etiquetado por versión en lugar de
:latest, para garantizar despliegues deterministas.
Kubernetes: la orquestación de contenedores a escala
Cuando se pasa de unos pocos contenedores a cientos repartidos en decenas de servidores, hace falta un orquestador que decida dónde colocar cada carga, reinicie lo que falle, escale según la demanda y enrute el tráfico. Eso es Kubernetes. Su arquitectura separa el control plane (el kube-apiserver como punto de entrada, etcd como almacén de estado, el scheduler que asigna pods a nodos y los controllers que reconcilian) de los worker nodes, donde el kubelet ejecuta los contenedores a través de un runtime compatible con CRI (containerd, CRI-O).
La unidad mínima desplegable no es el contenedor sino el pod, que agrupa uno o varios contenedores que comparten red y almacenamiento. Sobre los pods, Kubernetes ofrece abstracciones declarativas: el Deployment gestiona réplicas y despliegues progresivos (rolling updates), el Service da una IP estable y balanceo a un conjunto de pods, el Ingress expone HTTP/S al exterior, y el ConfigMap y el Secret externalizan configuración y credenciales. El modelo es declarativo: el usuario describe el estado deseado en YAML y el bucle de reconciliación de Kubernetes trabaja sin descanso para que el estado real coincida con él.
El escalado automático se articula en tres niveles: el Horizontal Pod Autoscaler (HPA) añade o quita réplicas según CPU, memoria o métricas personalizadas; el Vertical Pod Autoscaler ajusta los recursos por pod; y el Cluster Autoscaler añade o retira nodos del proveedor cloud según la demanda agregada.
Tabla comparativa: máquina virtual frente a contenedor
| Dimensión | Máquina virtual | Contenedor |
|---|---|---|
| Aislamiento | Hardware completo (hipervisor) | Proceso (namespaces + cgroups) |
| Sistema operativo | SO invitado completo por VM | Comparte kernel del anfitrión |
| Tiempo de arranque | Segundos a minutos | Milisegundos |
| Tamaño típico | Gigabytes | Megabytes |
| Densidad por host | Decenas | Cientos o miles |
| Superficie de aislamiento | Mayor (kernel propio) | Menor (kernel compartido) |
La conclusión práctica no es que una tecnología sustituya a la otra: conviven. Es habitual ejecutar Kubernetes sobre máquinas virtuales, combinando el fuerte aislamiento de la VM en la frontera de seguridad con la densidad y agilidad del contenedor en la capa de aplicación.
Microservicios y patrón de despliegue
Los contenedores son el vehículo natural de la arquitectura de microservicios, donde una aplicación monolítica se descompone en servicios pequeños, desplegables y escalables de forma independiente. Esto habilita despliegues sin caída mediante estrategias como rolling update (Kubernetes reemplaza pods progresivamente), blue-green (dos entornos paralelos y conmutación de tráfico) o canary (se enruta un porcentaje pequeño de tráfico a la versión nueva y se observa antes de generalizar). Estas técnicas son la base de la entrega continua moderna, integradas con pipelines de CI/CD y, cada vez más, con GitOps (Argo CD, Flux), donde el repositorio Git es la fuente única de verdad del estado del clúster.
Seguridad y normativa en entornos de contenedores
La superficie de ataque cambia respecto a las máquinas virtuales y exige controles específicos. El NIST SP 800-190, Application Container Security Guide, es la referencia oficial y aborda riesgos de la imagen (vulnerabilidades, secretos embebidos), del registro, del orquestador y del runtime. La organización CIS publica benchmarks de hardening tanto para Docker como para Kubernetes, que conviene aplicar como línea base. Medidas concretas: escanear imágenes en el pipeline (Trivy, Clair), firmar imágenes (Cosign/Sigstore), aplicar Network Policies para microsegmentar el tráfico este-oeste, usar RBAC con privilegio mínimo y gestionar secretos con un almacén externo (Vault) en lugar de dejarlos en variables de entorno.
En el plano de cumplimiento, cuando los contenedores procesan datos personales aplica el RGPD: el principio de seguridad del tratamiento (artículo 32) obliga al cifrado y a la minimización, y la portabilidad de los contenedores entre regiones y proveedores debe respetar las reglas de transferencia internacional de datos.
Errores comunes en producción
El primero es no definir límites de recursos (requests y limits): sin ellos, un pod desbocado consume toda la memoria del nodo y provoca el desalojo de los vecinos. El segundo es tratar los contenedores como mascotas y no como ganado, guardando estado dentro del contenedor en lugar de en volúmenes persistentes o bases de datos externas. El tercero es ejecutar como root y montar el socket de Docker dentro del contenedor, lo que equivale a regalar el anfitrión. El cuarto es ignorar los health checks (liveness y readiness probes), sin los cuales Kubernetes no sabe si un pod está realmente listo para recibir tráfico. El quinto, muy frecuente, es adoptar Kubernetes para tres servicios: su complejidad operativa solo se amortiza a cierta escala, y para cargas pequeñas a menudo basta con Docker Compose o un PaaS gestionado.
Preguntas frecuentes
¿Necesito Kubernetes si ya uso Docker?
No necesariamente. Docker resuelve el empaquetado y la ejecución de contenedores en un host. Kubernetes resuelve la orquestación de muchos contenedores en muchos hosts: autoescalado, recuperación ante fallos, despliegues progresivos y balanceo. Si gestiona pocos servicios en un único servidor, Docker Compose puede ser suficiente; Kubernetes aporta valor cuando la escala y la alta disponibilidad lo justifican.
¿Los contenedores son menos seguros que las máquinas virtuales?
El aislamiento del contenedor es más débil porque comparte el kernel del anfitrión, de modo que un escape compromete potencialmente toda la máquina. Sin embargo, con imágenes mínimas, ejecución sin root, políticas de red, escaneo de vulnerabilidades y, si se requiere aislamiento fuerte, runtimes sandbox (gVisor, Kata Containers), se alcanza un nivel de seguridad apto para producción. La regla es defensa en profundidad.
¿Qué runtime usa Kubernetes ahora que Docker fue deprecado?
Kubernetes retiró el componente dockershim, pero esto no significa que las imágenes Docker dejen de funcionar: siguen el estándar OCI y se ejecutan con runtimes compatibles con CRI como containerd (que de hecho subyace a Docker) o CRO-O. El cambio fue interno; las imágenes construidas con Docker siguen siendo plenamente válidas.
¿Cómo se gestiona el estado y las bases de datos en contenedores?
El estado se externaliza en volúmenes persistentes (PersistentVolume) respaldados por almacenamiento de bloque o de red. Para bases de datos en Kubernetes se usan StatefulSets, que dan identidad de red estable y almacenamiento dedicado por réplica, aunque muchas organizaciones prefieren delegar la base de datos en un servicio gestionado del proveedor cloud por su criticidad.
Conclusión
La elección entre máquinas virtuales y contenedores no es un duelo, sino una decisión de capas: la VM aporta aislamiento fuerte en la frontera de seguridad y los contenedores aportan densidad, velocidad de arranque y reproducibilidad en la capa de aplicación, y lo habitual en 2026 es combinarlas ejecutando Kubernetes sobre VMs. Docker resolvió el empaquetado reproducible que eliminó el «en mi máquina funciona», y Kubernetes resolvió la orquestación declarativa que permite que cientos de contenedores se autorreparen y escalen sin intervención manual. El riesgo real no está en la tecnología sino en adoptarla sin disciplina: contenedores root sin límites de recursos, imágenes sin escanear y clústeres sin RBAC convierten una arquitectura moderna en una superficie de ataque. Adoptar contenedores compensa cuando la escala lo justifica y cuando el hardening (NIST SP 800-190, benchmarks CIS) se trata como requisito y no como adorno. En Summum Sistemas diseñamos arquitecturas de contenedores reproducibles, pipelines de CI/CD con escaneo de imágenes y clústeres Kubernetes endurecidos, dimensionados a la escala real de cada cliente y no a la moda del momento.