Diferencias Kubernetes vs Docker Swarm

Si en un artículo anterior nos centrábamos en explicar qué era Docker en modo Swarm y cómo funcionaba, en este explicaremos las diferencias con su mayor competidor: Kubernetes. ¿Cuál será mejor: Kubernetes o Docker Swarm?

Definición de la aplicación

Por un lado, en Kubernetes las aplicaciones se pueden implementar usando una combinación de pods, implementaciones y servicios. Una implementación que puede tener réplicas en múltiples nodos.

Por otro lado, en Docker Swarm las aplicaciones se pueden implementar como servicios en un clúster Swarm. Las aplicaciones de varios contenedores pueden especificarse utilizando archivos YAML. Docker Compose puede implementar la aplicación. Asimismo, las tareas se pueden distribuir a través de centros de datos usando etiquetas.

Construcciones de escalabilidad de aplicaciones

En Kubernetes, 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.

En cambio, en Docker Swarm los servicios se pueden escalar utilizando plantillas Docker Compose YAML. Los servicios pueden ser globales o replicados. Los globales se ejecutan en todos los nodos, y los 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 en Kubernetes 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. Además, se pueden cargar múltiples nodos maestros y nodos de trabajo para solicitudes de kubectl y clientes.

A diferencia de los primeros, los servidores 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 asimismo un número impar de gerentes, y la mayoría de los gerentes deben estar disponibles para un clúster Swarm en funcionamiento.

Balanceo de Carga Kubernetes vs Docker Swarm

Los pods de Kubernetes 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.

En 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 de Kubernetes se usa 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.

En cambio, no está disponible directamente en Docker Swarm. Para cada servicio, puede declararse el número de tareas que desea ejecutar. Cuando escala manualmente hacia arriba o 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 de Kubernetes 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, Docker Swarm 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

En Kubernetes encontramos 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.

Redes de Kubernetes y Docker Swarm

El modelo de red plana de Kubernetes 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 obtiene 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 puente Docker solo para contenedores. Por defecto, los nodos en el clúster 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 en Kubernetes utilizando variables de entorno o DNS. Kubelet agrega un conjunto de variables de entorno cuando se ejecuta un pod. Además, 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 backend 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 5000 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 se devuelven en 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.

El Docker Swarm ha sido escalado y probado en hasta 30000 contenedores y 1000 nodos con 1 administrador de Swarm.

Conclusión: ¿Kubernetes o Docker Swarm?

Ahora que hemos visto las principales diferencias en Kubernetes y Docker Swarm nos queda por decir que, en cuanto a la popularidad y uso actual, Kubernetes es el líder en todas las métricas . Este ya que el 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.