La virtualización de hardware proporciona una lista de ventajas como escalabilidad, seguridad, aislamiento, etc. mediante el uso de hipervisores para compartir hardware físico con máquinas virtuales (VMs). En la actualidad, las máquinas virtuales no son la única forma de virtualización, ya que los contenedores también se han vuelto bastante populares. Mientras las VMs comparten el hardware físico de las máquinas subyacentes, los contenedores comparten el kernel del sistema operativo subyacente. Los contenedores no son máquinas virtuales ligeras, sino paquetes ejecutables estandarizados utilizados para entregar aplicaciones, incluidas aquellas que se desarrollan mediante la arquitectura de software basada en microservicios, e incluyen todos los componentes necesarios para ejecutar aplicaciones.
El motor Docker es la plataforma más popular para ejecutar contenedores. Kubernetes es un término que puede escuchar con mayor frecuencia en el ámbito de la contenerización y la computación en la nube. Pero ¿qué es mejor, Docker o Kubernetes? Es un tema popular de debate, pero plantearlo así no es técnicamente correcto. Por ejemplo, no se puede preguntar: “¿Qué es mejor, caliente o azul?”
¿Qué es Docker?
Docker es una aplicación independiente de código abierto que funciona como un motor utilizado para ejecutar aplicaciones contenerizadas. Se instala en su sistema operativo (SO), preferiblemente en Linux, pero también se puede instalar en Windows y macOS, que a su vez se ejecuta en una máquina física o virtual.
Una aplicación que se ejecuta en un contenedor está aislada del resto del sistema y de otros contenedores, pero da la ilusión de ejecutarse en su propia instancia de sistema operativo. Múltiples contenedores Docker pueden ejecutarse en un solo sistema operativo simultáneamente; puedes gestionar esos contenedores con Docker, y Docker puede ejecutarse sin Kubernetes. Si tienes múltiples hosts para ejecutar contenedores, gestionarlos manualmente puede ser difícil, y generalmente es mejor seleccionar una herramienta de gestión centralizada o una solución de orquestación.
Docker Compose es una herramienta básica de orquestación de contenedores utilizada para ejecutar aplicaciones multi-contenedor de Docker. Puedes configurar un archivo de configuración YAML (yml) de Docker Compose para definir aplicaciones multi-contenedor en lugar de configurar manualmente archivos Dockerfiles separados para cada contenedor. Después de configurar el archivo YAML único, puedes ejecutar todos los contenedores necesarios con un solo comando en tu consola de Linux. Utilizar Docker Compose es una forma de orquestar tus contenedores Docker, pero hay una alternativa potente a Docker Compose disponible que se llama Kubernetes.
¿Qué es Kubernetes?
Kubernetes es una solución de orquestación de contenedores de código abierto que se utiliza para gestionar software y servicios contenerizados con un alto grado de automatización.
Kubernetes es un proyecto de Google destinado a automatizar el despliegue, escalado y disponibilidad de aplicaciones que se ejecutan en contenedores. Puedes aumentar el número de hosts que ejecutan contenedores hasta 11 o más hosts. Además, puedes crear un clúster de contenedores Docker con Kubernetes para garantizar alta disponibilidad y equilibrio de carga.
Los hosts utilizados en un clúster se denominan nodos. El tipo de arquitectura de Kubernetes es esclavo-maestro – el clúster consta de nodos maestros y nodos de trabajo. El número mínimo de nodos recomendado por Kubernetes es de cuatro. Si bien puede construir un clúster en una sola máquina, para ejecutar todos los ejemplos y pruebas necesita, por lo menos, cuatro nodos. Un clúster de Kubernetes que maneja tráfico de producción debería tener un mínimo de tres nodos de trabajo. El uso de dos nodos maestros protege su clúster contra el fallo de un nodo maestro. Puede usar más de dos nodos maestros si es necesario.
- Los nodos maestros se utilizan para gestionar el estado de un clúster, lo que incluye aceptar solicitudes de cliente, programar operaciones con contenedores, ejecutar bucles de control, etc. Se necesita ejecutar una copia del etcd base de datos que almacena toda la información del clúster en cada nodo maestro. El nodo maestro ejecuta un conjunto de los tres procesos: kube-apiserver, kube-controller-manager y kube-scheduler.
- Los nodos de trabajo se utilizan para ejecutar cargas de trabajo de aplicaciones mediante la ejecución de contenedores. Los dos procesos de Kubernetes se ejecutan en el nodo no maestro: kubelet (para la comunicación con los nodos maestros) y kube-proxy (para reflejar los servicios de red de Kubernetes en cada nodo).
- El Controlador de Replicación es un componente utilizado para garantizar que las réplicas de Pods cuyo número está especificado estén siempre en funcionamiento en cualquier momento dado. Así puedes asegurarte de que los Pods estén siempre disponibles cuando los necesites.
Se utilizan diferentes CLI y APIs para comunicar servicios entre sí si se usa Kubernetes. También hay términos específicos que se utilizan para nombrar objetos y recursos de la API RESTful que son componentes del clúster construido con Kubernetes. - Pod es una unidad básica de programación en Kubernetes. Se trata de un grupo de recursos en el que pueden funcionar varios contenedores. Los contenedores que pertenecen a un Pod pueden ejecutarse en el mismo host y utilizar los mismos recursos y la misma red local. Los contenedores en el Pod están aislados pero pueden comunicarse entre sí con facilidad. Por lo tanto, los Pods se utilizan generalmente en Kubernetes, pero si usas una aplicación Docker independiente, solo están disponibles grupos de contenedores.
- Servicio es un conjunto de contenedores que trabajan juntos proporcionando, por ejemplo, el funcionamiento de una aplicación de varias capas. Kubernetes admite el nombramiento dinámico y el equilibrio de carga de Pods utilizando abstracciones. Este enfoque garantiza una conexión transparente entre los servicios por nombre y te permite rastrear su estado actual.
- Etiquetas son pares de clave/valor que están vinculados a Pods y otros objetos o servicios, además de permitir agruparlos fácilmente y asignar tareas.
- Namespaces es un método que permite dividir lógicamente el clúster unificado de Kubernetes en múltiples clústeres virtuales. Cada clúster virtual puede existir dentro de un entorno virtual limitado por cuotas sin afectar a otros clústeres virtuales.
Kubernetes se puede utilizar con Docker, aunque Docker no es la única plataforma de contenedores con la que se puede utilizar Kubernetes. Kubernetes también puede trabajar en conjunción con contenedores de Windows, contenedores de Linux, rkt, etc. K8s es el nombre de Kubernetes que a veces se puede encontrar en la documentación técnica.
Kubernetes vs Docker: Comparación de Redes
Veamos las opciones de redes para cada solución.
Docker proporciona tres modos de red para la comunicación de red entre contenedores.
Bridge. Este modo se utiliza de forma predeterminada, creando un puente virtual de capa 3. El nombre de red en tu host es docker0 para esta red. Docker crea automáticamente un puente de red de capa 3 y configura reglas de enmascaramiento para la interfaz de red externa, utilizando el principio de traducción de direcciones de red (NAT), lo que permite que los contenedores se comuniquen entre sí y se conecten a redes externas. Puedes configurar el reenvío de puertos para la interfaz de red de la máquina host si deseas conectar un contenedor desde otros hosts y redes externas. Así, al conectarte al puerto adecuado de la máquina host, se te redirige al puerto necesario del contenedor de Docker. Puedes crear más de una interfaz de red para un contenedor de Docker si es necesario.
Host. En este modo, un controlador de red de host garantiza que un contenedor no esté aislado del host de Docker. El contenedor comparte la pila de red del host, y el nombre del host del contenedor es el mismo que el nombre del host del sistema operativo del host. Si ejecuta un contenedor en el que se escucha un puerto TCP 8080, la aplicación del contenedor está disponible en el puerto TCP 8080 de la dirección IP de la máquina anfitriona. El controlador de red del host está disponible solo para máquinas Linux.
Ninguno. No se configuran direcciones IP para la interfaz de red de un contenedor dado, excepto la dirección 127.0.0.1 para la interfaz de bucle local. No hay acceso a redes externas si se establece el modo de red Ninguno.
Redes multihost para contenedores Docker. Si los contenedores se están ejecutando en diferentes hosts, pueden comunicarse entre sí después de configurar la superposición de redes. Se debe configurar un servicio de almacenamiento de clave-valor válido (Consul, Etcd o ZooKeeper) para crear tales redes.
Kubernetes. Si utiliza contenedores Docker independientes, cada contenedor se puede considerar como una unidad básica que se comunica a través de la red utilizando la interfaz de red adecuada. Si está utilizando Kubernetes, los Pods son las unidades básicas del clúster de contenedores. Cada pod tiene su propia dirección IP y consta de al menos un contenedor. Un Pod puede constar de múltiples contenedores que se utilizan para tareas relacionadas. Los contenedores del mismo Pod no pueden abrir el mismo puerto simultáneamente. Este tipo de restricción se usa porque un Pod que consta de múltiples contenedores todavía tiene una sola dirección IP.
Además, Kubernetes crea un contenedor especial de pausa para cada Pod. Este contenedor especial tiene la intención de proporcionar una interfaz de red (para comunicación interna y externa) para otros contenedores, y generalmente está en pausa (en modo de suspensión). Estos contenedores de pausa se activan cuando Kubernetes envía una señal de “SIGTERM”.
Flannel se utiliza típicamente como una tela de red para conectar contenedores en Kubernetes utilizando los principios de superposición de red. La superposición de redes permite ejecutar contenedores comunicándose a través de la red lógica en diferentes hosts físicos del clúster (que se denominan nodos). El almacén de claves/valores de código abierto etcd se utiliza para guardar los mapeos entre las direcciones IP reales asignadas a los contenedores por los hosts en los que se están ejecutando los contenedores, y las direcciones IP en la red de superposición.
La red de Kubernetes se puede integrar con VMware NSX-T mediante el uso del complemento NSX Container. Esta integración le permite utilizar una topología de red multinivel que no está disponible “listo para usar” en Kubernetes.
El modelo de red de Kubernetes proporciona las siguientes características:
- Todos los contenedores pueden comunicarse entre sí dentro de un clúster sin NAT.
- Todos los nodos del clúster pueden comunicarse con todos los contenedores dentro de un clúster sin NAT. Inversamente, todos los contenedores pueden comunicarse con todos los nodos del clúster.
- Los contenedores ven sus propias direcciones IP y esas direcciones IP son vistas por otros componentes de Kubernetes.
Ingress es un objeto API de Kubernetes que se utiliza para gestionar el acceso a los servicios en el clúster desde el exterior (principalmente HTTP y HTTPS). Puede configurar Ingress para realizar acceso externo a los servicios contenerizados, para equilibrio de carga, terminación SSL y hosting virtual basado en nombres. Un controlador de Ingress debe ser desplegado en el nodo maestro para que las reglas de ingreso funcionen.
Casos de Uso
Utilizar Docker como un software independiente es bueno para el desarrollo de aplicaciones, ya que los desarrolladores pueden ejecutar sus aplicaciones en entornos aislados. Además, los probadores también pueden usar Docker para ejecutar aplicaciones en entornos de sandbox. Si desea utilizar Docker para ejecutar un alto número de contenedores en el entorno de producción, puede encontrarse con algunas complicaciones en el camino. Por ejemplo, algunos contenedores pueden sobrecargarse fácilmente o fallar. Puede reiniciar manualmente el contenedor en la máquina apropiada, pero la gestión manual puede consumir mucho de su valioso tiempo y energía.
Kubernetes le permite resolver estos problemas proporcionando características clave como alta disponibilidad, equilibrio de carga, herramientas de orquestación de contenedores, etc. Como resultado, Kubernetes es más adecuado para entornos de producción altamente cargados con un alto número de contenedores Docker. Desplegar Kubernetes es más difícil que instalar una aplicación Docker independiente, razón por la cual Kubernetes no siempre se utiliza para desarrollo y pruebas.
Kubernetes vs Docker Swarm
Docker Swarm es una herramienta de agrupación nativa para Docker que puede convertir un grupo de hosts de Docker en un solo host virtual. Docker Swarm está totalmente integrado con el Motor de Docker y le permite utilizar API estándar y procesos de red; está diseñado para implementar, administrar y escalar contenedores de Docker.
Swarm es un clúster de hosts de Docker que se llaman nodos. Consideremos los siguientes componentes principales de un clúster cuando se está utilizando Docker Swarm antes de comparar la implementación del clúster con Kubernetes y Docker Swarm:
Los nodos de administrador se utilizan para realizar la orquestación de control, la administración del clúster y la distribución de tareas.
Los nodos de trabajador se utilizan para ejecutar contenedores cuyas tareas son asignadas por los nodos de administrador. Cada nodo puede configurarse como un nodo de administrador, nodo de trabajador o como ambos para realizar funciones de nodo de administrador y nodo de trabajador. Tenga en cuenta que los nodos de trabajador ejecutan servicios de swarm.
Servicios. Un servicio de Docker Swarm define el estado óptimo requerido para cada servicio contenerizado. Un servicio controla parámetros como el número de réplicas, los recursos de red disponibles para él, los puertos que deben hacerse accesibles desde redes externas, etc. La configuración del servicio, como la configuración de red, se puede modificar y aplicar a un contenedor sin necesidad de reiniciar el servicio con el contenedor manualmente.
Tareas. Una tarea es un espacio en el que se ejecuta un solo contenedor. Las tareas son las partes de un servicio de Swarm.
Así, Docker Swarm y Kubernetes son dos plataformas diferentes utilizadas para propósitos similares. Ahora es el momento de compararlas en un conjunto adecuado de categorías.
Despliegue del clúster
Docker Swarm. Una API estándar de Docker te permite desplegar un clúster con Swarm mediante una CLI (interfaz de línea de comandos) de Docker estándar que facilita el despliegue, especialmente cuando se utiliza por primera vez. La facilidad de despliegue para Swarm, en comparación con Kubernetes, también se logra gracias a la capacidad de un único maestro de Docker para decidir cómo distribuir los servicios. No se utilizan Pods en Docker Swarm.
Kubernetes requiere que utilices comandos especificados que son diferentes de los comandos estándar de Docker. Se utilizan APIs especificadas en Kubernetes, lo que significa que incluso si conoces los comandos para la gestión de Docker, también es posible que necesites aprender a usar un conjunto adicional de herramientas para el despliegue de Kubernetes. Los nodos deben ser definidos manualmente en el clúster de Kubernetes: debes seleccionar el nodo maestro, definir el controlador, el planificador, etc.
Escala
Docker Swarm. Gracias a la API simple proporcionada por Docker, el despliegue de contenedores y la actualización de servicios en clústeres grandes y pequeños se pueden hacer más rápido. Una interfaz de línea de comandos (CLI) es bastante simple y fácil de entender. Como resultado, Swarm puede considerarse una solución más escalable en comparación con Kubernetes.
Kubernetes proporciona APIs comparativamente unificadas y una serie de características que a menudo resultan en un proceso de implementación más lento. Hay tres tipos de componentes que deben configurarse: Pod, Despliegue y Servicio. Cuando se trata de autoescalado, Kubernetes es preferible debido a su capacidad para analizar cargas de servidores además de proporcionar la oportunidad de escalar automáticamente según los requisitos dados. Kubernetes es la elección óptima para redes distribuidas grandes y sistemas complejos.
Alta disponibilidad
Las dos opciones de solución poseen mecanismos similares de replicación de servicios y redundancia, y en ambos casos el sistema se autorregula y no requiere reconfiguración manual después de que un nodo fallido vuelva a ser un clúster.
Docker Swarm. Los nodos gestores manejan los recursos de los nodos trabajadores y de todo el clúster. Los nodos del clúster Swarm participan en la replicación de servicios.
Kubernetes. Los nodos no saludables son detectados por los servicios de equilibrio de carga de Kubernetes y se eliminan del clúster. Todos los Pods se distribuyen entre los nodos, proporcionando así alta disponibilidad en caso de que falle un nodo en el que se esté ejecutando una aplicación en contenedores.
Balanceo de carga
Docker Swarm. El balanceo de carga es una característica integrada y puede realizarse automáticamente utilizando la red interna de Swarm. Todas las solicitudes al clúster se distribuyen y redirigen a los nodos del clúster; cualquier nodo puede conectarse a cualquier contenedor. Docker Swarm utiliza un elemento DNS para distribuir las solicitudes entrantes a los nombres de servicio.
Kubernetes. Las políticas definidas en los Pods se utilizan para el equilibrio de carga en Kubernetes. En este caso, los Pods de contenedores deben definirse como servicios. Debe configurar manualmente la configuración de equilibrio de carga, mientras que Ingress se puede utilizar para el equilibrio de carga.
Creación y ejecución de contenedores
Docker Swarm. La gran mayoría de los comandos disponibles para Docker CLI se pueden utilizar cuando se utiliza Docker Swarm, gracias a la API estandarizada de Docker Swarm. Docker Compose define el trabajo con volúmenes y redes utilizadas, además de definir qué contenedores deben agruparse. El número preciso de réplicas se puede establecer con Docker Compose para Docker Swarm.
Kubernetes. Kubernetes tiene su propia API, cliente, y necesita archivos YAML para ser configurado. Esta es una de las diferencias clave, ya que Docker Compose y Docker CLI no pueden usarse para implementar contenedores en este caso. En Kubernetes, el sistema para definir servicios sigue un principio de funcionamiento similar al de Docker Compose, pero es más complejo. La funcionalidad de Docker Compose se realiza utilizando Pods, Despliegues y Servicios en Kubernetes, dentro de los cuales cada capa se utiliza para su propio propósito especificado. Los Pods son responsables de la interacción del contenedor, mientras que los despliegues son responsables de la alta disponibilidad y la conexión en red para un único nodo en el clúster (muy similar al Docker Compose para una aplicación Docker independiente sin Swarm), y los servicios de Kubernetes son responsables de la configuración de la operación del servicio dentro del clúster, la tolerancia a fallos, etc.
Redes
Docker Swarm. Existe una red interna predeterminada para la comunicación de contenedores dentro de un clúster, a la que se pueden agregar más redes si es necesario. Las redes están protegidas con certificados TLS generados. Se admite la generación manual de certificados para la encriptación del tráfico de datos del contenedor.
Kubernetes. El modelo de red de Kubernetes es bastante diferente y se implementa utilizando complementos, uno de los cuales es Flannel, la opción más popular. Los pods interactúan entre sí, y esta interacción puede estar restringida por políticas. Existe una red interna gestionada por el servicio etcd. La encriptación TLS también está disponible, pero debe configurarse manualmente. El modelo de red de Kubernetes presume la configuración de dos CIDR, Clasificación Inter-Dominio Sin Clases, que también se conoce como supernetting.
Monitoreo
Docker Swarm. No hay herramientas integradas para monitoreo y registro, aunque puedes configurar manualmente herramientas de monitoreo de terceros. ELK o Reimann se pueden utilizar con este propósito.
Kubernetes. Kubernetes proporciona herramientas integradas para registro y monitoreo. Elasticsearch y Kibana (ELK) se pueden utilizar para monitorear el estado completo del clúster, mientras que Heapster, Grafana e Influx son compatibles para monitorear los servicios de contenedor.
Interfaz de Usuario Gráfica (GUI)
Docker Swarm. La GUI se puede habilitar con herramientas de terceros como Portainer.io, que proporciona una interfaz web fácil de usar. Como alternativa, puedes utilizar la Edición Empresarial de Docker que proporciona una interfaz gráfica para la gestión del clúster.
Kubernetes. El GUI proporcionado por Kubernetes es un panel confiable al que se puede acceder a través de una interfaz web con la que puedes controlar fácilmente tu clúster. El GUI puede ser una herramienta muy valiosa para usuarios con experiencia mínima en el manejo de Kubernetes con la CLI.
Conclusión
Docker Swarm es una solución nativa de Docker que utiliza principalmente la API y la CLI de Docker. Kubernetes, en contraste, es un proyecto de Google que se utiliza para implementar un clúster en el que se ejecutan contenedores.
Tanto Docker Swarm como Kubernetes proporcionan alta disponibilidad, equilibrio de carga, redes de superposición y características de escalabilidad. Docker Swarm es el más fácil de los dos para implementar, ya que la configuración de la mayoría de sus características está automatizada y consume pocos recursos de hardware. Sin embargo, la funcionalidad está limitada por la API de Docker y faltan herramientas de monitoreo nativas.
Por otro lado, Kubernetes es una solución modular con un alto nivel de flexibilidad que ha sido apoyada por la mayoría de las grandes entidades corporativas durante varios años. Herramientas integradas para monitorear servicios y todo el clúster están disponibles para Kubernetes, aunque la implementación y configuración son más difíciles, lo que hace que este recurso sea una solución más exigente. Kubernetes no es compatible con Docker CLI y Docker Compose. Se prefiere el uso de Kubernetes en entornos grandes donde se ejecutan aplicaciones multi-contenedor altamente cargadas.