Docker Swarm vs. Kubernetes
Con este artículo vamos a tratar de explicar las diferencias que existen entre Docker Swarm y Kubernetes con el objetivo de ayudar a decidir cuál de ellos poder usar en nuestra infraestructura.
Éstos son los orquestadores de contenedores más usados actualmente, aunque hay una gran gama de otros menos conocidos como Mesos, Elastic Container Service de Amazon (ECS), Azure Container Service, CoreOS Fleet…
Tienen el objetivo de poder desplegar contenedores Docker en un entorno clusterizado.
Para poder tener claras las diferencias es recomendable conocer tanto Docker Swarm como Kubernetes. La idea es centrarnos en las diferencias y aspectos que nos ayuden a decidir entre ellos.
¿QUÉ ES KUBERNETES?
Este orquestador es un sistema open source (https://github.com/kubernetes/kubernetes/releases) que fue creado por Google al verse en la necesidad de desplegar, escalar y monitorizar contenedores. Actualmente lo ha donado a la Cloud Native Computing Foundation. Google había estado trabajando con contendores Linux más de 15 años cuando adaptó su forma de trabajar con estos contenedores a Docker creando así Kubernetes.
No solamente funciona con contenedores Docker, sino que es capaz de soportar más runtime de contendores como rkt o cri-o.
Google usa Kubernetes en su infraestructura, así como en muchas de las aplicaciones de su plataforma. Gmail, el buscador o Google Maps están actualmente usando Kubernetes para gestionar sus servicios.
De hecho, se dice que Google ha liberado mucho conocimiento sobre el funcionamiento de los contenedores al crear Kubernetes.
¿QUÉ ES DOCKER SWARM?
Con el objetivo de proveer a los usuarios de la posibilidad de orquestar sus contenedores, Docker creó su propio mecanismo de orquestación (también es open source https://github.com/docker/swarm). Al ser nativo de Docker, Swarm utiliza la API de Docker Engine, por lo que lo que cualquier persona que ya trabaje con Docker puede trabajar en modo Swarm sin tener que aprender una tecnología o API diferente, ya que los conceptos básicamente son los mismos. Los comandos son muy parecidos y siguen la misma estructura que los que provee Docker.
Swarm está completamente integrado con Docker Engine, por lo que no requiere ninguna instalación adicional para comenzar a usarlo.
CONCEPTOS BÁSICOS
Como comentábamos el objetivo de este artículo no es explicar el funcionamiento sino las diferencias que nos ayuden a decidir qué orquestador encaja mejor en nuestra arquitectura, por lo que antes de ver diferencias, hay que tener claro algunos conceptos básicos que ayudan a entender la arquitectura de estos orquestadores.
Docker Swarm
Nodo: Es una instancia de un Swarm (cluster).
Swarm: Es el cluster de los nodos en los que está instalado Docker Engine. En modo Swarm se despliegan servicios en lugar de contenedores.
Nodo Manager: Es el que gestiona el cluster y programa los servicios en los disintos nodos. Puede existir más de uno y pueden correr imágenes en él también.
Nodo Worker: Serán los nodos donde corren las tareas de los servicios.
Servicio: Es la propia imagen, el contendor. Se pueden crear varias réplicas de estos servicios.
Tarea: Es una unidad atómica de un servicio que corre en un nodo, es decir una réplica de un servicio. Se ejecutan independientemente una de la otra.
Kubernetes
Pods: Kubernetes despliega y programa los contenedores en estos grupos llamados pods. Los contendores en un mismo pod corren en el mismo nodo y comparten recursos.
Deployments: Son bloques de script escritos en YAML para construir y administrar pods. Se puede añadir una configuración a muy bajo nivel.
Servicios: Son endpoints que se pueden conectar a los pods usando selectores de etiqueta. Esto hace que no tengamos que acceder a cada Pod por IP y puerto. Actúa de balanceador de carga como explicaremos al ver las diferencias.
DIFERENCIAS A DESTACAR
Tanto Swarm como Kubernetes ofrecen casi las mismas funcionalidades, aunque si es cierto que hay diferencias a la hora de usarlos.
Hay multitud de información detallando técnicamente las diferencias entre los 2 gigantes, pero vamos a intentar resumir las que hemos experimentado trabajando con ellos teniendo en cuenta distintos aspectos importantes que deberían de ser tomados en cuenta a la hora de decidirnos por uno u otro.
¿Cómo instalar y comenzar a usar estos orquestadores?
La instalación de Kubernetes es totalmente manual y más complicada, ya que requiere de configuraciones no automáticas y de un conocimiento previo de la configuración del cluster que se quiera crear, ya que antes de comenzar a trabajar con el cluster, se necesita saber el número de nodos que lo conformarán, qué roles va a tomar cada nodo, su IP…
Existen aplicaciones que te ofrecen ayuda a la hora de instalar y definir este proceso.
Instalar Swarm es mucho más sencillo, ya que a partir de la versión 1.12 de Docker Engine, está embebido en Docker, por lo que simplemente hay que inicializar el modo swarm y además de ser más rápido y fácil, con el cluster ya en funcionamiento podemos crear nodos y cambiar los roles de estos nodos en cualquier momento mientras el cluster funciona sin perder servicio.
¿Qué acciones podemos realizar en nuestro entorno clusterizado?
Kubernetes usa su propia API para trabajar con el cluster, básicamente cuenta con los métodos que Swarm tiene ya que se replican, pero tiene como ventaja que al ser propia la API, se pueden añadir nuevas operaciones personalizadas para ser ejecutadas, permitiendo definir nuevas acciones y operaciones que se puedan necesitar.
Usa la API propia de Docker, por lo que los comandos que se pueden ejecutar son los propios de Docker, pero no se pueden añadir más operaciones a las ya existentes.
Tiene como ventaja que conociendo Docker, es muy sencillo comenzar con el modo Swarm, pero si necesitamos operaciones personalizadas no se pueden añadir a Docker. Está limitado a lo que ofrezca el Docker Engine.
Escalando aplicaciones
Kubernetes tiene la gran ventaja de que puede escalar las aplicaciones automáticamente usando la política que establezcamos en los deployments. Kubernetes creará réplicas dependiendo de esta política y el estado del cluster en ese momento.
Se pueden definir el número de réplicas de las que queremos disponer de cada servicio, es un proceso manual. Se programará una tarea por cada réplica y correrán en los distintos nodos que existen. Se puede escalar incrementando o disminuyendo réplicas. Es más rápido que en Kubernetes y fácil ya que consta de un solo comando.
¿Como se asegura la alta disponibilidad?
Los ‘deployments’ permiten a los pods ser programados en los distintos nodos del cluster e incluso detecta aquellos pods que no se están ejecutando correctamente eliminándolos.
Los nodos también tienen roles, existe el nodo Master (parecido al manager de Swarm), que permite recuperar aquellos pods en mal estado y desplegarlos en los nodos workers dependiendo del deployment.
Básicamente el nodo manager de Swarm se encarga de asegurar el estado del cluster y de notificar si las tareas están ejecutándose correctamente. Es capaz de crear tareas si un nodo entra en un estado de mantenimiento y despliega las tareas entre los nodos intentando asegurar la alta disponibilidad (no todas las tareas en el mismo nodo).
Balanceador de carga
En Kubernetes es bastante más potente, ya que más que un componente, es un servicio desplegado que hace de balanceador de carga en el cluster. Los pods son expuestos a través de este servicio.
Swarm tiene un componente que permite realizar el balanceo entre los nodos. Ese componente es una red creada automáticamente al inicializar el modo Swarm (ingress network), que permite balancear las peticiones haciéndolas llegar al nodo que corresponda.
Actualización de las aplicaciones
Kubernetes puede ser configurado (a través de su deployment) para definir la estrategia de actualización de los pods que queramos usar. Es más amplia que en Swarm ya que además de contar con ‘RollingUpdate’ (explicado en la columna de Swarm), también dispone de ‘Recreate’ (todos los pods son parados antes de que los nuevos sean creados).
En caso de fallo, se hace un rollback automático.
Swarm permite Rolling Update. Es capaz de actualizar las aplicaciones sin tener que detener el servicio. Es capaz de parar las tareas de un servicio, actualizarlas y volverlas a iniciar si no hay ningún error. Por lo que distintas versiones del mismo servicio pueden estar corriendo hasta que todas las tareas se actualicen. Se puede aplicar una amplia configuración como por ejemplo actualizar todas la tareas a la vez, esperar X segundos entre una actualización y otra, políticas de reinicio…
En caso de fallo, también se hace un rollback automático.
Gestión de redes
En Kubernetes los contenedores se pueden comunicar a través de una red virtual. Se puede aplicar autenticación TLS en esta red generando e instalando manualmente certificados en los nodos que conforman el cluster. Como comentábamos anteriormente, en Swarm se crea una red superpuesta que permite conectar todos los nodos del cluster (overlay network). Esta red es cifrada automáticamente con TLS. También se pueden crear nuevas redes donde poder desplegar los contenedores y establecer conexiones entre ellos. Se puede incluso configurar el cifrado y encriptar la comunicación entre éstos.
Service Discovery
Se puede añadir DNS a los servicios, de esta manera se crea un registros de DNS y si éste está activado en el cluster los pods pueden comunicarse a través de los nombre a los que están asignados.
En kubernetes también se pueden crear variables de entorno por cada pod que permite resolver cada servicio.
A través de la red que se crea al inicializar el modo Swarm y desplegar todos los contenedores en esta red, los contenedores se pueden comunicar mediante las IP’s virtuales y los nombres que se les asignan a los servicios independientemente del nodo en el que estén desplegados.
Rendimiento
Alcanza unos 150.000 pods desplegados en un clúster de unos 5.000 nodos.
Es parecido a Kubernetes, ya que según las estadísticas que podemos ver, es posible hacer correr 30.000 contenedores en un cluster de 1.000 nodos.
VENTAJAS E INCONVENIENTES DE KUBERNETES
Cada orquestador dispone de sus ventajas e inconvenientes.
A grandes rasgos, Kubernetes tiene la gran ventaja de que es open source (Swarm también, pero la comunidad y aportaciones son mayores en Kubernetes), por lo que podemos aprovecharnos de futuras modificaciones que la comunidad aporte al proyecto.
Grandes plataformas están funcionando ya con Kubernetes desde hace varios años, y tiene detrás a Google como uno de sus principales contribuidores como se aprecia en el número de commits hechos por Google a este proyecto.
Otra de sus principales ventajas es que es una aplicación modular, y que funciona con distintos tipos de contenedores y no solamente con Docker.
La comunidad de Kubernetes es enorme y se puede encontrar mucha información, meetups, eventos y patrocinadores que hacen que exista una amplia documentación del orquestador
Kubernetes permite escalar nuestras aplicaciones de manera automática sin tener que hacerlo manualmente, lo que nos ahorra tiempo y costes en monitorizarlos.
Como inconvenientes, Kubernetes presenta la dificultad a la hora de instalarlo y aprender a utilizarlo, ya que es complejo. Requiere más software para poder trabajar con él como por ejemplo instalar kubectl CLI.
Al ser un orquestador propio creado por Google, es incompatible con herramientas de Docker como por ejemplo el propio Docker CLI, o Docker Compose.
VENTAJAS E INCONVENIENTES DE DOCKER SWARM
Por otra parte Docker Swarm cuenta como principal ventaja una gran facilidad para instalar y empezar a usarlo, esto se traduce en una gran rapidez a la hora de comenzar a trabajar con Swarm.
También es open source, pero bien es cierto que hay menos contribuidores que en Kubernetes.
Swarm es la solución de Docker para lanzar un soporte que permita orquestar contenedores, por lo que está incluido dentro de Docker Engine (a partir de la versión 1.12), esto se traduce en que no es necesario instalar software como complemento para hacer funcionar Docker en modo Swarm.
Los comandos que se utilizan en Swarm son de Docker, por lo que siguen el mismo concepto y son fáciles de usar.
Se pueden utilizar todas las herramientas nativas de Docker como por ejemplo Docker Compose (en modo Swarm se llama Docker Stack pero es básicamente lo mismo), Docker CLI…
Pero poder utilizar la API de Docker tiene también sus desventajas como por ejemplo que las operaciones que se pueden realizar son las que están soportadas por la API de Docker, no podemos usar funcionalidad que no esté en Docker.
Comparado con Kubernetes, la comunidad de Docker Swarm es más pequeña y por supuesto hay menos proyectos que actualmente están trabajando con Swarm.
Como comentábamos antes, los servicios solamente pueden ser escalados manualmente, no como en Kubernetes, pero es cierto que se pueden escalar aplicaciones más rápido que en Kubernetes y a un número de réplicas muy alto por cada servicio.
Swarm también presenta como desventaja que no presenta un manejo de fallos de los nodos tan bueno como Kubernetes.
¿CÓMO DECIDIR QUÉ ORQUESTADOR ENCAJA EN NUESTRA INFRAESTRUCTURA?
Al final la pregunta que nos hacemos si necesitamos un orquestador de contendores es: ¿Docker Swarm o Kubernetes? Resolver esta pregunta va a depender de varios factores.
¿Necesitamos arrancar ya con el orquestador? ¿Conocemos Docker? ¿Las operaciones que Swarm ofrece son las que necesitamos? ¿Necesitamos modificar nuestro cluster de manera dinámica ¿Buscamos simplicidad y rápidez?
Si no hay tiempo o recursos para investigar en una solución, Docker Swarm es nuestra elección. La simplicidad de usar Docker Swarm hace que sea un factor importante a la hora de adoptar este orquestador.
Conocer Docker es una de los factores que ayuda a elegir Swarm frente a Kubernetes ya que utiliza la API de Docker.
En Swarm es bastante más fácil crear y configurar nodos, y se puede modificar el cluster dinámicamente como necesitemos una vez arrancado y funcionando sin tener que perder servicio.
Swarm es una opción muy válida para compañías que están comenzando con contenedores o no necesitan llegar a una configuración de muy bajo nivel, muy detallada.
Además de ser más fácil de configurar, está totalmente ligado a las herramientas de Docker, por lo que si tenemos experiencia trabajando con Docker, queremos seguir usando Docker y lo que necesitamos puede ser hecho con las herramientas nativas de Docker, Swarm sería la mejor opción para usar.
Si lo que buscamos es desplegar contenedores rápidamente y sin molestia, Swarm es nuestro aliado.
¿Necesitamos algo más que una organización de contenedores? ¿Tenemos que desplegar algún contenedor que no sea Docker? ¿Necesitamos más operaciones que las que Docker Engine
provee? ¿Nuestro cluster es complejo y con muchos nodos? ¿Necesitamos una configuración muy detallada a bajo nivel? ¿Disponemos de tiempo para aprender una nueva tecnología? ¿Necesitamos gestionar un gran número de contenedores?
Kubernetes parece algo más que un software de gestión de contenedores, ya que fue diseñado para ser un entorno con el objetivo de crear aplicaciones distribuidas de contenedores.
Es bastante más maduro que Swarm.
Recordemos que tiene la capacidad de trabajar con contenedores que no solamente son de Docker, por lo que, si nuestra organización necesita trabajar con más operaciones que las permitidas por el Docker Engine, Kubernetes es mejor opción.
Es bastante adecuado usar Kubernetes para entornos donde los clústeres medianos y grandes ejecutan aplicaciones complejas o requieren de una configuración muy detallada.
En términos generales, Kubernetes es más dificil de usar y configurar que Swarm, pero ofrece mucha más potencia y flexibilidad a la hora de usar y configurarlo.
Si no solamente necesitamos desplegar contenedores y hacerlos correr en nuestros hosts, si no que necesitamos un paso más allá, un extra de configuración y operaciones que Docker no soporta, Kubernetes es nuestro aliado.
CONCLUSIÓN
La sensación de ambas plataformas tras leer y trabajar con ellas es que:
- Docker sabe de la potencia de la tecnología de sus contenedores y decidió construir una plataforma para que los propios usuarios de Docker comenzasen a orquestar sus contendores en entornos clusterizados. El problema es que sacrifica un poco en funcionalidad ya que está al 100% acoplado a Docker, por lo que las operaciones a realizar son aquellas que Docker Engine soporte.
- Por otro lado, Kubernetes crea la orquestación de contenedores basándose en su experiencia con contenedores Linux. Se centra más en la fiabilidad, sacrificando simplicidad.
Tras investigar sobre estos orquestadores también nos damos cuenta de que parece que cada vez más Kubernetes va siendo más fácil de usar de la misma manera que Swarm. Parece que Kubernetes está emergiendo como líder en cuanto a orquestador de contenedores gracias a su gran posibilidad de configuración, su comunidad y fiabilidad. Pero cada orquestador tiene sus ventajas e inconvenientes y al final la decisión recaerá en qué es lo que necesitamos: rapidez “encerrados” en Docker, o una extensa posibilidad de configuración y fiabilidad con Kubernetes.
Es importante hacer saber que en la última DockerCon17, Docker anunció que ofrecerá soporte para Kubernetes como orquestador oficial (https://www.muylinux.com/2017/10/18/docker-kubernetes/), es decir, que Docker EE integrará a Kubernetes en la plataforma, aunque se seguirá usando Swarm para otros componentes de la plataforma, ya que publicaron que van a seguir invirtiendo en Swarm para que aproveche parte del ecosistema de Kubernetes para evolucionar todo lo rápido que se pueda.
Habrá que esperar a la siguiente versión de Docker (se lanza la reléase este 2018) para comprobar si efectivamente, como se hizo público en la DockerCon17, el usuario dentro de Docker puede elegir entre usar Swarm, Kubernetes o quizás ambas.
Cloud Foundry y Pivotal Container Service también apoyarán a Kubernetes.