Durante la creación de esta entrada de blog intentaremos hacer una comparación lineal de las diferencias y capacidades de estos sistemas de manejo de contenedores. Por un lado tendremos a Kubernetes v1.9 y por el otro Docker Swarm 1.2.9 también conocido  como Docker Engine.

Iniciaremos por el principio:

Que es Kubernetes?

No es más que un sistema de código abierto que nos ayuda con la implementación, escalado y administración de aplicaciones en contenedores, fue construido por Google utilizando un sistema interno de administración de clústeres llamado Borg “Omega”. Y se puede diagramar su base de trabajo de la siguiente manera:

Img1:Diagrama-Kubernetes

Como se observa en el diagrama de la img1, existen una serie de  componentes asociados al clúster de Kubernetes. El nodo Master, ubica las cargas de trabajo del contenedor en grupos de usuarios en nodos de trabajadores o en si mismo. Los demás componentes son:

  • Etcd: Almacena los datos de configuración a los que puede acceder el Servidor API de Kubernetes Master utilizando http simple o API JSON.
  • Kube-Apiserver: es el centro de gestión para el nodo Master, facilita la comunicación entre los diversos componentes manteniendo con ello la salud del clúster.
  • Kube-Controller-Manager: es el encargado de asegurar la coincidencia entre el estado deseado del clúster y el estado actual, esto lo consigue esclando cargas de trabajo hacia arriba y hacia abajo
  • Kube-Scheduler: coloca la carga de trabajo en el nodo que corresponde; en este diagrama particular, todas las cargas de trabajo se ubican localmente en su host.
  • Kubelet: recibe las especificaciones del pod del servidor API y administra los pods que se ejecutan en el host.

Para estar en consonancia con los términos utilizados comúnmente cuando se habla de Kubernetes, manejaremos la siguiente lista:

  • Pods: Kubernetes implementa y programa contenedores en grupos llamados pods. Los contenedores en un pod se ejecutan en el mismo nodo y comparten recursos como sistemas de archivos, espacio de nombres en el kernel y una dirección IP.
  •  Despliegues: estos bloques de construcción se pueden usar para crear y administrar un grupo de pods. Los despliegues se pueden usar a nivel de servicio para escalar horizontalmente garantizando disponibilidad.
  •  Servicios: son los puntos finales que se pueden direccionar por nombre y se pueden conectar a los pods utilizando los selectores de etiquetas. El servicio automáticamente enviará solicitudes por turnos entre pods. Kubernetes configurará un servidor DNS para el clúster que busca nuevos servicios y les permite ser direccionados por su nombre. Los servicios son la parte frontal de las cargas de trabajo de su contenedor.
  •  Etiquetas: son pares e clave-valor unidos a objetos y se pueden usar para buscar y actualizar multiples objetos como un conjunto.
¿Quieres hablar con nosotros ahora?
Contáctanos

Que es Docker Swarm?

Es una herramienta que permite a los desarrolladores implementar contenedores en modo swarm. Un clúster Swarm consiste en Docker Engine implem entado en múltiples nodos. Los nodos de administración realizan la orquestación y la administración del clúster. Los nodos de trabajo reciben y ejecutan tareas desde los nodos de administración.

Un servicio consiste en tareas que puedes ejecutarse en nodos de Swarm. Los servicios se pueden replicar para ejecutarse en multiples nodos. En el modelo de servicio replicados, el equilibrio de carga de ingreso y el DNS internos se pueden usar para proporcionar puntos finales de servicio altamente disponibles.

Img2: Diagrama-Docker Swarm

Como se aprecia en la Img2, la arquitectura Docker Swarm consta de Gerentes y Trabajadores. El usuario puede especificar declarativamente el estado de varios servicios para ejecutar en el clúster utilizando para ello ficheros de tipo YAML. Para esta arquitectura también listaremos algunos términos comúnmente mencionados.

  • Nodo: no es más que una instancia de un enjambre. Los nodos se pueden distribuir en las instalaciones o en nubes públicas.
  • Swarm: lo conforman un grupo de nodos (Docker Engine). En este modelo se orquestan servicios en lugar de ejecutar comandos de contenedores.
  • Nodos de administración: reciben las definiciones de servicio del usuario y distribuyen el trabajo a los nodos de trabajadores. Los nodos de administración también pueden realizar las tareas de los nodos de trabajador.
  • Nodos de trabajador: recopilan y ejecutan tareas desde los nodos de administración.
  • Tarea: es una unidad atómica de un servicio programado en un nodo trabajador.

Ya conociendo las arquitecturas y componentes de Kubernetes y Docker Swarm, pasaremos a realizar una comparativa de ambos ecosistemas.

Comparativa entre las dos tecnologias de gestión de contenedores

Nota: La tecnología de Kubernetes y Docker Swarm evoluciona muy rápidamente por lo que algunos de estos detalles pueden estar desactualizados  cuando los lea.

Caracteristicas kubernetes
Kubernetes
Docker Swarm
Definición de la aplicación Las aplicaciones se pueden implementar usando una combinación de pods, implementaciones y servicios (o "microservicios").
Una implementación puede tener réplicas en múltiples nodos. 		Las aplicaciones se pueden implementar como servicios (o "microservicios") en un clúster Swarm. Las aplicaciones de varios contenedores pueden especificarse utilizando archivos YAML.
Docker Compose puede implementar la aplicación. Las tareas se pueden distribuir a través de centros de datos usando etiquetas.
Construcciones de escalabilidad de aplicaciones Cada nivel de aplicación se define como un pod y se puede escalar cuando se administra mediante una implementación, que se especifica en YAML.
La escala puede ser manual o automatizada.
Los Pods se pueden usar para ejecutar pilas de aplicaciones integradas verticalmente, aplicaciones compartidas y coadministradas.		 Los servicios se pueden escalar utilizando plantillas Docker Compose YAML.
Los servicios pueden ser globales o replicados.
Los servicios globales se ejecutan en todos los nodos, los servicios replicados ejecutan réplicas de los servicios en los nodos. Las tareas se pueden ampliar o reducir, y desplegar en paralelo o en secuencia.
Alta disponibilidad Las implementaciones permiten que los pods se distribuyan entre los nodos para proporcionar HA, tolerando así las fallas de la aplicación.
Los servicios de carga equilibrada detectan pods no saludables y los eliminan.
Se admite alta disponibilidad de Kubernetes.
Se pueden cargar múltiples nodos maestros y nodos de trabajo para solicitudes de kubectl y clientes. Etcd se pueden agrupar en clústeres y los servidores API se pueden replicar. 		Los servicios se pueden replicar entre los nodos de Swarm.
Los administradores de Swarm son responsables de todo el clúster y administran los recursos de los nodos de trabajadores.
Los gerentes utilizan el equilibrio de carga de entrada para exponer los servicios externamente.
Los administradores de swarm usan el algoritmo de consenso de Raft para garantizar que tengan información de estado consistente.
Se recomienda un número impar de gerentes, y la mayoría de los gerentes debe estar disponible para un clúster Swarm en funcionamiento.
Balanceo de carga Los pods se exponen a través de un servicio, que se puede usar como un equilibrador de carga dentro del clúster.
Por lo general, una entrada se usa para equilibrar la carga.		 El modo Swarm tiene un componente DNS que se puede usar para distribuir solicitudes entrantes a un nombre de servicio. Los servicios pueden ejecutarse en los puertos especificados por el usuario o pueden asignarse automáticamente.
Escalado automático para la aplicación El escalado automático utilizando un objetivo simple de número de pods, se define de manera declarativa mediante implementación.
El objetivo de utilización de CPU por pod está disponible.
Otros objetivos están en la hoja de ruta.		 No disponible directamente.
Para cada servicio, puede declarar el número de tareas que desea ejecutar. Cuando escala manualmente hacia arriba o hacia abajo, el administrador Swarm se adapta automáticamente al agregar o eliminar tareas
Actualizaciones de aplicaciones continuas y reversión El controlador de implementación es compatible con estrategias de actualización gradual y recreación.
Las actualizaciones continuas pueden especificar el número máximo de pods no disponibles o el número máximo que se ejecuta durante el proceso.		 En el momento del despliegue, puede aplicar actualizaciones continuas a los servicios.
El administrador de Swarm le permite controlar la demora entre la implementación del servicio a diferentes conjuntos de nodos, con lo cual solo se actualizan 1 tarea a la vez.
Chequeos de salud Dos tipos de comprobaciones de salud: vitalidad (es sensible a la aplicación) y preparación (responde a la aplicación, pero está ocupado preparando y aún no puede servir) Los controladores de salud de docker swarm están limitados a los servicios.
Si un contenedor que respalda el servicio no aparece (estado de ejecución), se inicia un nuevo contenedor.
Los usuarios pueden incrustar la funcionalidad de verificación de estado en sus imágenes Docker usando la instrucción HEALTHCHECK.
Almacenamiento Dos API de almacenamiento:
El primero proporciona abstracciones para backends de almacenamiento individual.
El segundo proporciona una abstracción para una solicitud de recursos de almacenamiento “Storage”, que puede cumplirse con diferentes backends de almacenamiento.
La modificación del recurso de almacenamiento utilizado por el daemon de Docker en un nodo del clúster requiere la eliminación temporal del nodo del clúster.
Kubernetes ofrece varios tipos de volúmenes persistentes con soporte de bloque o archivo. Los ejemplos incluyen iSCSI, NFS, FC, Amazon Web Services, Google Cloud Platform y Microsoft Azure.
El volumen EmptyDir no es persistente y puede usarse para leer y escribir archivos con un contenedor. 		Docker Engine y Swarm admiten volúmenes de montaje en un contenedor.
Los sistemas de archivos compartidos, incluidos NFS, iSCSI y el canal de fibra, se pueden configurar nodos. Las opciones de complementos incluyen AWS, Azure, Google Cloud Platform, NetApp, Dell EMC y otros.
Redes El modelo de red plana, lo que permite que todos los pods se comuniquen entre sí. Las políticas de red especifican cómo los pods se comunican entre sí. La red plana generalmente se implementa como una superposición.
El modelo requiere dos CIDR: uno de los cuales los pods obtienen una dirección IP, el otro para los servicios. 		El nodo que se une a un clúster Docker Swarm crea una red de superposición para servicios que abarcan todos los hosts en Swarm y una red de puente Docker solo para contenedores.
Por defecto, los nodos en el cluster Swarm encriptan el control de superposición y el tráfico de administración entre ellos. Los usuarios pueden optar por cifrar el tráfico de datos del contenedor al crear una red de superposición por sí mismos
Descubrimiento del servicio Los servicios se pueden encontrar utilizando variables de entorno o DNS.
Kubelet agrega un conjunto de variables de entorno cuando se ejecuta un pod. Kubelet admite variables {SVCNAME_SERVICE_HOST} Y {SVCNAME_SERVICE_PORT} simples, así como también variables compatibles de Docker.
El servidor DNS está disponible como un complemento. Para cada servicio de Kubernetes, el servidor DNS crea un conjunto de registros DNS. Si DNS está habilitado en todo el clúster, los pods podrán usar nombres de servicio que se resolverán automáticamente. 		El nodo de Swarm Manager asigna a cada servicio un nombre DNS único y equilibrios de carga que ejecutan contenedores. Las solicitudes a los servicios se equilibran de carga a los contenedores individuales a través del servidor DNS integrado en el Enjambre.
Docker Swarm viene con múltiples backends de descubrimiento:
• Docker Hub como un servicio de descubrimiento alojado está destinado a ser utilizado para desarrollo / prueba. No recomendado para producción.
• Se puede usar un archivo estático o una lista de nodos como back-end de descubrimiento. El archivo debe almacenarse en un host al que se pueda acceder desde Swarm Manager. También puede proporcionar una lista de nodos como opción cuando inicie Swarm.
Rendimiento y escalabilidad A partir de 1.6, Kubernetes escala a clúster de 5.000 nodos. La escalabilidad de Kubernetes se compara con los siguientes objetivos de nivel de servicio (SLO):
• Capacidad de respuesta de la API: el 99% de todas las llamadas API devuelven menos de 1s.
• Tiempo de inicio del Pod: el 99% de los pods y sus contenedores (con imágenes pre-tiradas) comienzan en 5 segundos. 		Docker Swarm ha sido escalado y probado en hasta 30,000 contenedores y 1,000 nodos con 1 administrador de Swarm.

Conclusiones

En cuanto a la popularidad y uso actual, Kubernetes es líder en todas las métricas cuando se compara con Docker Swarm, tiene más del 80% del interés en artículos de noticias, popularidad en herramientas como Github y búsquedas en la web.

Por otra parte no es menos cierto la diferencia en la complejidad implicada en implementar Kubernetes en comparación con Docker Swarm, pero Kubernetes ha tratado de mitigar este inconveniente incorporando una variedad de opciones de implementación como Minikube y Kubeadm…

Si estás interesado en Kubernetes, conoce cómo podemos ayudarte con nuestro servicio de Kubernetes Management.