Docker vs Kubernetes: vamos a ver en qué se diferencian

Seguimos escuchando regularmente la pregunta: ¿es mejor usar Docker o Kubernetes? Es uno de los malentendidos más persistentes en el ecosistema de contenedores.

La respuesta corta es: Docker y Kubernetes no son competidores directos. Se encuentran en diferentes capas del mismo stack y la mayoría de los entornos de producción utilizan ambos. Lo que ha cambiado es el ecosistema a su alrededor: Kubernetes eliminó el dockershim, containerd se convirtió en el runtime de facto, Docker lanzó una versión importante con Engine v29.

Esta guía actualizada está escrita para sysadmins y MSPs que necesitan una visión actual y precisa de dónde se encuentran estas dos tecnologías en 2026 y cómo elegir entre ellas.

¿Qué es Docker?

Docker es una plataforma de contenedorización: un conjunto de herramientas que permite construir imágenes de contenedores, ejecutarlas como procesos aislados en un host (contenedores) y compartirlas a través de registros como Docker Hub o un registro privado conforme a OCI.

El componente principal es el Docker Engine, una aplicación cliente/servidor compuesta por:

• un proceso daemon de larga ejecución (dockerd),
• una REST API para interactuar con el daemon,
• la CLI docker.

Por debajo del daemon, Docker ha utilizado containerd como runtime de bajo nivel durante varios años. Con Docker Engine v29, lanzado a finales de 2025, esta alineación se ha completado: el almacén de imágenes de containerd es ahora el predeterminado para nuevas instalaciones, y Docker ha elevado oficialmente la versión mínima de la API a 1.44 (Moby v25), haciendo obsoletas las versiones anteriores a la 25. Para los sysadmins esto es importante porque el nuevo daemon rechazará aceptar clientes con API 1.43 o inferior a menos que DOCKER_MIN_API_VERSION se anule explícitamente.

En el trabajo diario, Docker en 2026 sigue siendo la herramienta de referencia para:

• Construir imágenes de contenedores a partir de un Dockerfile.
• Ejecutar contenedores individuales o stacks multi-contenedor locales mediante Docker Compose.
• Flujos de trabajo del lado del desarrollador en estaciones de trabajo (Docker Desktop en Windows, macOS y Linux).
• Publicar imágenes conformes a OCI en registros que luego serán descargadas por los orquestadores.

Vale la pena destacar para los sysadmins que trabajan en distribuciones derivadas de Red Hat: Podman, el motor de contenedores sin daemon y rootless mantenido por Red Hat, se ha convertido en la herramienta de contenedores predeterminada en RHEL, Fedora, Rocky Linux y AlmaLinux. Es en gran medida compatible con la CLI de Docker (alias docker=podman es un punto de partida habitual) y produce imágenes OCI que funcionan de manera idéntica en Kubernetes. Para flujos de trabajo basados en Docker no es necesario cambiar, pero en hosts de la familia RHEL Podman es lo que encontrarás preinstalado.

Docker sigue siendo la herramienta de construcción dominante y el formato de imagen OCI que Docker popularizó es consumido por prácticamente todos los orquestadores del mercado, incluido Kubernetes.

¿Qué es Kubernetes?

Kubernetes (K8s) es una plataforma de orquestación de contenedores de código abierto, desarrollada originalmente en Google y ahora mantenida por la Cloud Native Computing Foundation (CNCF). Proporciona una API declarativa que describe qué se quiere en ejecución (qué cargas de trabajo, cuántas réplicas, en qué nodos, expuestas cómo) y un bucle de control que reconcilia continuamente el estado del clúster con ese estado deseado.

Kubernetes gestiona la complejidad operativa que surge cuando se escalan contenedores en múltiples hosts: scheduling, descubrimiento de servicios, balanceo de carga, rolling updates, self-healing, gestión de secrets y configuraciones, autoescalado horizontal, abstracción de almacenamiento y aplicación de políticas de red.

Cadencia de lanzamiento y versiones soportadas

Kubernetes sigue una cadencia de lanzamiento de aproximadamente cuatro meses (unas tres versiones menores al año) con una política de soporte N-2: solo las tres versiones menores más recientes reciben correcciones de seguridad y errores, para una ventana de soporte total de aproximadamente 14 meses por versión.

A mediados de 2026, las versiones soportadas son:

Versión	Último parche	Estado	Fin de vida
1.37	1.37.0	Estable actual	2027-10-28
1.36	1.36.4	Estable actual	2027-06-28
1.35	1.35.8	Soportada	2027-02-28
1.34	1.34.11	Modo de mantenimiento (solo correcciones críticas)	2026-10-27

Con Kubernetes 1.37 lanzado el 26 de agosto de 2026, la versión 1.34 entró en modo de mantenimiento el 27 de agosto de 2026 y sale de las ramas activamente mantenidas una vez que alcanza el fin de su vida útil el 27 de octubre de 2026; cualquier versión 1.33 o anterior ya debería tratarse como un riesgo de seguridad en cualquier entorno del que seas responsable. Comprueba siempre el estado de soporte actual en kubernetes.io/releases antes de planificar una actualización.

El container runtime: containerd, no Docker

Los nodos de Kubernetes necesitan un container runtime conforme a CRI para iniciar realmente los contenedores en los pods. Desde Kubernetes v1.24 (mayo de 2022) el dockershim integrado ha sido eliminado: kubelet ahora se comunica directamente con el runtime a través de la Container Runtime Interface (CRI), y los runtimes dominantes son containerd y CRI-O.

Esta es una de las fuentes de confusión más comunes en 2026. «Kubernetes eliminó Docker» no significa que Kubernetes ya no pueda ejecutar imágenes construidas con Docker – puede hacerlo, porque esas imágenes son conformes a OCI y cualquier runtime CRI las comprende. Significa que Kubernetes ya no incluye una capa de traducción para utilizar el Docker Engine completo como su runtime. El runtime CRI (containerd, CRI-O, o el cri-dockerd mantenido por Mirantis si realmente lo necesitas) sustituye ese papel.

Para los sysadmins esto es mayormente un no-problema hoy en día: cada servicio gestionado (EKS, GKE, AKS) ha sido containerd-only durante años, y los clústeres autogestionados construidos con kubeadm también usan containerd por defecto.

¿Entonces por qué sigue surgiendo la pregunta «Docker vs Kubernetes»?

Dos razones.

Primero, Docker históricamente distribuía su propio orquestador, Docker Swarm, que era una alternativa directa a Kubernetes. Así que en un momento la comparación era técnicamente válida – pero solo para la orquestación. Volveremos a Swarm en un momento.

Segundo, Docker Desktop incluye un clúster Kubernetes local de un solo nodo, y muchos desarrolladores aprenden ambas herramientas al mismo tiempo. El resultado es que «Docker» y «Kubernetes» acaban mencionándose juntos como si fueran intercambiables, aunque viven en capas diferentes:

Capa	Herramienta
Formato de imagen y registro	OCI / Docker Hub / registros privados
Construcción de imagen	Docker, Buildah, Kaniko, BuildKit
Container runtime (bajo nivel)	containerd, CRI-O, runc
Runtime single-host + tooling	Docker Engine
Orquestación multi-host	Kubernetes, Docker Swarm

Docker opera en las tres capas inferiores. Kubernetes vive en la parte superior.

Dónde encaja Docker Swarm en 2026

Docker Swarm es el modo de orquestación nativo de Docker, integrado directamente en Docker Engine y gestionado mediante la CLI estándar de Docker. Un clúster se inicializa con un único `docker swarm init`, los servicios se despliegan usando el mismo formato Compose file que los desarrolladores ya conocen, y el modelo operativo es intencionalmente mínimo: nodos manager, nodos worker, servicios, tareas. Sin control plane separado que instalar, sin manifiestos YAML más allá de Compose, sin CRDs.

Durante años esto convirtió a Swarm en la alternativa «ligera» obvia a Kubernetes. En 2026 el panorama es más matizado. Swarm sigue mantenido, sigue distribuyéndose con Docker Engine y sigue ejecutando cargas de trabajo en producción – pero ha recibido muy pocas funcionalidades nuevas en comparación con el ritmo del ecosistema Kubernetes, y el papel de «orquestador simple para clústeres pequeños» ha pasado en gran medida a distribuciones Kubernetes ligeras como K3s y MicroK8s (tratadas más adelante en esta guía).

Para un sysadmin o MSP que evalúa Swarm hoy, el resumen honesto es este:

• Opción razonable para entornos pequeños y estables donde la simplicidad es el objetivo: unos pocos servicios en dos o tres nodos, herramientas internas, homelabs, o entornos donde el equipo ya conoce Docker y no quiere asumir la carga operativa de Kubernetes.
• No la opción predeterminada para nuevos proyectos de tamaño significativo, despliegues multi-tenant, o cualquier cosa que necesite el ecosistema CNCF más amplio (charts de Helm, operators, service mesh, tooling GitOps como Argo CD o Flux).
• Vale la pena tener en cuenta si heredas un clúster Swarm existente: no está roto y no necesariamente debes migrarlo mañana, pero las nuevas inversiones es mejor dirigirlas a otro lugar.

Kubernetes es mucho más complejo que Swarm y ofrece funcionalidades muy superiores, especialmente en escala, primitivas de seguridad y el ecosistema circundante. El trade-off es el mismo que en 2022 – simplicidad vs. capacidad – pero el centro de gravedad de la industria se ha desplazado claramente.

Cómo Docker y Kubernetes trabajan realmente juntos

En un pipeline típico de 2026 las dos tecnologías están apiladas, no son alternativas entre sí:

1. Build. Un desarrollador escribe un Dockerfile y usa Docker (o BuildKit) para construir una imagen OCI localmente.
2. Test. La imagen se ejecuta localmente mediante docker run o docker compose, o contra el clúster Kubernetes de un solo nodo incluido en Docker Desktop.
3. Push. La CI publica la imagen en un registro (Docker Hub, GHCR, ECR, GAR, Harbor, Artifactory).
4. Deploy. Una herramienta nativa de Kubernetes (kubectl, Helm, Argo CD, Flux) despliega la imagen en un clúster.
5. Ejecución. Kubernetes descarga la imagen mediante containerd en cada nodo y la ejecuta dentro de pods, gestionando scheduling, escalado, health checks y rollout.

Docker domina los pasos 1-2; Kubernetes domina los pasos 4-5; el registro del paso 3 es tecnológicamente neutro.

Elegir la herramienta adecuada: una guía práctica para sysadmins y MSPs

Para el tipo de audiencia para la que normalmente escribimos en The Solving – administradores de sistemas, MSPs, equipos IT que mantienen entornos heterogéneos de clientes – la pregunta rara vez es «¿Docker o Kubernetes?» de forma aislada. Es más frecuentemente «¿cuánta orquestación necesito realmente, y dónde la ejecuto?»

Usa Docker solo cuando

• Una carga de trabajo se ejecuta en un único host y no necesitas failover automático entre nodos.
• Estás empaquetando una aplicación para distribuirla a clientes como imagen de contenedor sin prescribir cómo la orquestan.
• Estás ejecutando cargas de trabajo de utilidad en una estación de trabajo de sysadmin o un servidor pequeño: un DNS privado, un endpoint Wireguard, una instancia Vaultwarden, algunos stacks Compose.
• Estás haciendo desarrollo local y builds de CI.

Docker Compose solo cubre una cantidad sorprendentemente grande de escenarios MSP de pequeño y mediano tamaño.

Usa Kubernetes cuando

• Necesitas ejecutar cargas de trabajo en múltiples nodos con reprogramación automática en caso de fallo.
• Necesitas autoescalado horizontal impulsado por métricas o eventos.
• Estás gestionando decenas o cientos de servicios que se benefician de un flujo de trabajo declarativo y GitOps.
• Necesitas multi-tenancy con aislamiento adecuado, RBAC y políticas de red.
• Los requisitos de compliance o de ingeniería de plataforma del cliente lo exigen explícitamente.

Kubernetes ligero para MSPs y sitios edge

Si la carga de trabajo genuinamente necesita orquestación pero un clúster Kubernetes upstream completo es excesivo – típicamente el caso en oficinas remotas, sitios edge, instalaciones de clientes y entornos gestionados por MSPs de pequeño tamaño – existen ahora distribuciones ligeras maduras y conformes a CNCF:

• K3s (Rancher / SUSE). La distribución ligera más adoptada. Binario único, valores predeterminados definidos (Traefik como ingress, ServiceLB), SQLite o etcd integrado como datastore. Listo para producción y utilizado a escala en despliegues edge de telecomunicaciones.
• MicroK8s (Canonical). Basado en Snap, con un potente sistema de add-ons (microk8s enable ingress prometheus). Excelente opción si ya estás estandarizado en Ubuntu.
• K0s (Mirantis). Binario único autocontenido con muy pocas dependencias del sistema operativo host; una sólida elección para despliegues inmutables o air-gapped.
• Minikube. Sigue siendo la opción de referencia para desarrollo local y aprendizaje, no para producción.

Las tres distribuciones están diseñadas para funcionar cómodamente dentro de 1-2 GB de RAM en una configuración de un solo nodo – una fracción de lo que requiere un control plane upstream completo – haciéndolas viables en una Raspberry Pi, un PC industrial sin ventilador o una pequeña VM. El footprint de memoria exacto depende de los add-ons habilitados y del backend de almacenamiento, así que realiza benchmarks contra tu propia carga de trabajo antes de dimensionar.

Para un MSP, la implicación práctica es que ahora puedes desplegar un clúster Kubernetes certificado por CNCF en las instalaciones de un cliente, en hardware que normalmente considerarías demasiado pequeño para la orquestación, y gestionarlo remotamente con las mismas herramientas kubectl y GitOps que utilizas en cualquier otro lugar.

Kubernetes gestionado: EKS, GKE, AKS

Cuando el clúster reside en una nube pública, los tres servicios gestionados dominan:

• Amazon EKS. El más flexible, el menos dogmático. Se combina bien con Karpenter para el aprovisionamiento rápido de nodos. EKS Anywhere extiende el modelo a on-premises.
• Google GKE. A menudo citado como la mejor experiencia «pura» de Kubernetes, dado que Google originó el proyecto. GKE Autopilot gestiona completamente el plano de datos: solo defines pods, Google gestiona los nodos. El más potente para cargas de trabajo AI/ML gracias al soporte de TPU.
• Azure AKS. Tres niveles de precios para el control plane: Free (sin SLA, destinado a dev/test), Standard (SLA con respaldo financiero en el servidor de la API de Kubernetes, el predeterminado para cargas de trabajo de producción) y Premium (añade Long-Term Support, extendiendo el mantenimiento para una versión determinada de Kubernetes hasta 2 años). Estrecha integración con Entra ID (anteriormente Azure AD), Azure Monitor y Azure DevOps. Azure Arc extiende la gestión de AKS a on-premises y edge a través de un único plano de control.
• Red Hat OpenShift. Merece una mención aparte para entornos enterprise y regulados: OpenShift es una distribución Kubernetes certificada por CNCF con una capa de plataforma definida encima (CI/CD integrada, registro interno, consola para desarrolladores, valores predeterminados de seguridad más estrictos). Disponible autogestionado (OpenShift Container Platform) o como servicios gestionados en AWS (ROSA), Azure (ARO), Google Cloud e IBM Cloud. Opción habitual en finanzas, sanidad y sector público donde los contratos de soporte de Red Hat y las certificaciones de cumplimiento son relevantes.

Los cuatro soportan las versiones menores actuales de Kubernetes, siendo GKE típicamente la más rápida en adoptar nuevas versiones, seguida de AKS, EKS y OpenShift, que se mantiene intencionalmente por detrás del upstream para permitir hardening y certificación adicionales. 

Consideraciones de seguridad y operativas para 2026

Algunas cosas han cambiado lo suficiente desde 2022 como para merecer ser señaladas explícitamente:

• La seguridad de la cadena de suministro es ahora un requisito básico. La firma de imágenes (Cosign / Sigstore), la generación de SBOM (docker scout sbom, syft) y los admission controllers que aplican imágenes firmadas ya no son opcionales en entornos regulados. La iniciativa de Docker para imágenes hardened y políticas como Kyverno u OPA Gatekeeper en el lado de Kubernetes son las respuestas estándar.
• Las CVE de runtime afectan a ambos mundos. Docker Engine v29 cerró tres vulnerabilidades graves en docker cp (CVE-2026-41567, CVE-2026-41568, CVE-2026-42306) que permitían a un contenedor malicioso ejecutar binarios del host o escribir en rutas arbitrarias del host, y Docker Desktop recibió una corrección urgente en el ciclo anterior para CVE-2025-9074 (CVSS 9.3), una toma de control de contenedor a host. Kubernetes tampoco está aislado: cada runtime CRI finalmente lanza contenedores mediante runc, por lo que una CVE de escape de contenedor en runc (como CVE-2024-21626, corregida en runc 1.1.12) se propaga de manera idéntica a cualquier clúster que dependa de él. La conclusión práctica es que «solo usamos Docker, no Kubernetes» – o viceversa – no te mueve a una superficie más segura. Ambos stacks comparten el mismo linaje OCI/runc aguas abajo, y ambos necesitan la misma disciplina de parcheo.
• El versionado de la API y el skew importan. Con Docker Engine v29 elevando la versión mínima de la API a 1.44 y Kubernetes aplicando estrictamente la política de soporte N-2, «no hemos actualizado en dos años» ya no es una posición sostenible. Planifica una cadencia de actualización regular, idealmente vinculada a un flujo GitOps.
• El backup y la recuperación ante desastres no desaparecen con los contenedores. Las cargas de trabajo sin estado son sencillas; las cargas de trabajo con estado (bases de datos en StatefulSets, volúmenes persistentes) siguen necesitando una estrategia de backup real. Velero es la opción canónica nativa de Kubernetes; para el lado del host, las VMs subyacentes y el almacenamiento persistente también deben estar cubiertos por una solución de backup a nivel de infraestructura.

La conclusión práctica para sysadmins y MSPs

El enfoque original de «Docker vs Kubernetes» era engañoso en 2022 y sigue siéndolo en 2026 – solo que ahora el panorama subyacente ha evolucionado.

• Docker es la herramienta de construcción y el runtime single-host que casi todos utilizan, y Engine v29 con el almacén de imágenes de containerd ha consolidado su lugar en el stack.
• Kubernetes es el orquestador en el que la industria se ha estandarizado para cualquier cosa más allá de un único host, con tres versiones menores activamente soportadas y una cadencia de lanzamiento de cuatro meses.
• Docker Swarm sigue existiendo y sigue funcionando, pero ha dejado de ser la respuesta obvia a «quiero una orquestación simple»; las distribuciones Kubernetes ligeras han asumido en gran medida ese papel.
• K8s ligero (K3s, MicroK8s, k0s) es la forma en que MSPs y sysadmins llevan la orquestación real a sitios pequeños y dispositivos edge en 2026.
• K8s gestionado (EKS, GKE, AKS, OpenShift) es la forma en que la mayoría de las organizaciones consume Kubernetes en la nube, y cuál elegir depende más del resto de tu footprint en la nube, las relaciones con los proveedores y los requisitos de compliance que del propio Kubernetes.

Para un sysadmin o MSP que empieza hoy, la recomendación no ha cambiado mucho: familiarízate primero con Docker, porque es el punto de entrada universal a la contenedorización, y aprende suficiente Kubernetes – empezando por una distribución ligera como K3s – para operar la capa de orquestación que se ha convertido en el estándar de facto para las cargas de trabajo de contenedores en producción.