ATENCIÓN: este contenido tiene más de 2 años de antigüedad y, debido a su temática, podría contener información desactualizada o inexacta en la actualidad.
Docker Swarm Mode es el orquestador de contenedores propio de Docker. Swarm, en inglés, significa "enjambre", e indica de forma visual bastante bien cuál es la idea.
Aunque finalmente Docker se ha rendido a la evidencia de que Kubernetes es el líder en el mercado de orquestadores (y lo ha integrado con Docker Desktop), sigue manteniendo el soporte a Swarm por razones obvias, y lo mantiene a través e un proyecto Open Source: swarmkit.
La siguiente imagen (sacada de la documentación de Docker) te ayudará a entender mejor el rol de cada producto de la empresa:
- Docker Enterprise Edition: manejo de contenedores con necesidades empresariales, como seguridad o capacidad de gestión.
- Docker Community Edition: manejo de contenedores para desarrollo.
- containerd: motor de ejecución de contenedores.
- Swarm y Kubernetes: orquestadores.
Observa como, en la imagen, Docker coloca Swarm y Kubernetes uno al lado de otro: la idea es que juegan el mismo rol. Compiten entre ellos y puedes usar el que prefieras.
En este artículo vamos a ver una breve introducción a Swarm para conocer cómo funciona y cuáles son sus ventajas e inconvenientes. Aunque Kubernetes es el estándar de facto en orquestadores en la actualidad, Swarm también tiene sus usos y puede venirte muy bien para ciertos tipos de usos y por su sencillez.
Comparación entre Swarm y Kubernetes
Vamos a comparar (someramente) Swarm con Kubernetes. La principal diferencia es que Swarm usa el modelo de aplicación de Compose mientras que Kubernetes usa el suyo propio.
A priori usar el modelo de Compose ofrece varias ventajas:
- Uso de mismos conceptos en desarrollo (Compose) y en producción (Swarm)
- No hay dobles configuraciones (en Kubernetes debemos mantener los ficheros Compose y los ficheros YAML de Kubernetes)
Pero la realidad no es tan sencilla. Emplear el modelo de Compose para Swarm implica un acoplamiento entre ambos productos: si no se puede hacer en Compose, no se puede hacer en Swarm. Por su parte, Kubernetes parte de un modelo radicalmente distinto, lo que le ha permitido saltarse muchas de las limitaciones que tenía Compose y ofrecer un modelo de aplicación muy poderoso. Por ejemplo, en Swarm es imposible disponer algo equivalente a un pod multicontenedor, porque en Compose un servicio se compone siempre de un contenedor y, por lo tanto, en Swarm también.
Vamos a ver algunos términos de Swarm y cómo los podemos comparar con su "equivalente más cercano" en Kubernetes.
- Nodo (node): cada una de las máquinas que componen el clúster. Equivale al concepto de nodo en Kubernetes.
- Swarm: es el clúster, entendido como conjunto de nodos.
- Nodos "manager": nodos que se encargan de tareas de gestión del clúster. Equivale a los nodos "master" en Kubernetes.
- Nodos "worker": nodos que ejecutan contenedores. Equivalente a los nodos minion de Kubernetes.
- Servicio: un contenedor en un número determinado de instancias. No hay una equivalencia clara con ningún elemento de Kubernetes.
- Tarea (task): unidad atómica de un servicio. Si un servicio se escala para tener 2 instancias, esto genera dos tasks. Equivale al pod de Kubernetes.
Comparación del modelo de aplicación
En Kubernetes una aplicación se define como un conjunto de pods (que se pueden crear directamente o usando deployments) que ejecutan contenedores. Los pods son la unidad atómica de despliegue y se exponen internamente (y/o externamente) a través de servicios. Un servicio es la "cara externa" de un conjunto de pods y los agrupa bajo una única IP.
En Swarm una aplicación se define como un conjunto de servicios. Cada servicio genera una o más tasks que son ejecutadas en los distintos nodos.
Comparación del modelo de escalabilidad de la aplicación
En Kubernetes una aplicación se escala usando el ReplicaSet que se encarga de garantizar que en todo momento hay un determinado número de instancias de un tipo de pod. El ReplicaSet se configura a través del objeto deployment asociado.
En Swarm una aplicación se escala manejando las instancias de un servicio. Los servicios pueden ser globales o replicados. Los servicios globales ejecutan una instancia en cada uno de los nodos, mientras que los replicados ejecutan N réplicas (tasks) entre los distintos nodos.
Otras comparaciones
- Healthchecks: Kubernetes soporta dos tipos de healthchecks (
readiness y liveness) y utiliza los healthchecks definidos en la imagen (usando HEALTHCHECK en el Dockerfile). Por su parte, Swarm soporta healtchecks a nivel de servicio y las tasks se reinician en función de si se cumple o no.
- Almacenamiento (volúmenes): Kubernetes tiene dos modelos de volúmenes (normales y persistentes) y una API para definir volúmenes y sus peticiones. Swarm usa el modelo de Docker de montar sistemas de ficheros externos en un contenedor.
- Escalado: es difícil de decir. Como referencia el número máximo de nodos en Kubernetes es de 5.000, con un total de pods de 150.000, ejecutando un máximo de 300.000 contenedores. Por su parte, en este post se menciona Swarm escalado con 30.000 contenedores en 1.000 nodos.
Ventajas de Kubernetes sobre Swarm
- Sistema muy maduro, que proviene de la larga experiencia de Google en el uso interno de contenedores (Kubernetes es la evolución de Borg, un orquestador propio de Google).
- Soporte en muchísimos proveedores de cloud y de arquitectura (GCE, Azure, Amazon, IBM Cloud, DC/OS, ...).
- Modelo de aplicación más potente que el de Compose.
- Soporte para otros sistemas de contenedores más allá de Docker.
- Soporte para autoescalado de pods. En Swarm los servicios se escalan manualmente.
Ventajas de Swarm sobre Kubernetes
- Usa el mismo modelo de aplicación y ficheros que Compose.
- Usa la misma CLI que Compose.
Situación actual
La situación actual, como ya se ha comentado, es que Kubernetes ha ganado la batalla de los orquestadores. El mayor impedimento para su uso (instalación compleja) se ha limitado mucho gracias a proveedores de cloud que ofrecen clústeres de k8s administrados.
Incluso Docker se ha rendido a la evidencia del liderazgo de Kubernetes ofreciendo soporte para este en Docker Engine y Docker Desktop y poniéndolo a la par con Swarm.
No obstante, Swarm puede hacer valer su sencillez y compatibilidad con la convifuración de Docker Componse para despliegues pequeños en máquinas propias, por ejemplo, por lo que puede ser interesante conocerlo.
Ahora que ya conoces Swarm y cómo se compara con Kubernetes, en la segunda parte puedes ver en la práctica cómo utilizarlo para poner en marcha aplicaciones escalables.
Fecha de publicación: