Kubernetes vs Docker – ¿Cuál es la diferencia?
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 (VM). En la actualidad, las máquinas virtuales no son la única forma de virtualización, ya que los contenedores también se han hecho bastante populares. Mientras que las máquinas virtuales comparten el hardware físico de las máquinas subyacentes, los contenedores comparten el núcleo del sistema operativo subyacente. Los contenedores no son máquinas virtuales ligeras, sino paquetes ejecutables estandarizados que se utilizan para entregar aplicaciones, incluidas las que se desarrollan utilizando 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 del que se oye hablar cada vez con más frecuencia en el ámbito de la contenedorización y la computación en nube. Pero, ¿qué es mejor, Docker o Kubernetes? Es un tema popular de debate, pero expresarlo 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 en contenedores. Se instala en su sistema operativo (SO), preferentemente en Linux, pero también puede instalarse 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 del sistema operativo. Se pueden ejecutar varios contenedores Docker en el mismo sistema operativo simultáneamente; se pueden gestionar esos contenedores con Docker, y Docker puede ejecutarse sin Kubernetes. Si tienes varios 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 Docker multicontenedor. Puede configurar un archivo de configuración YAML (yml) Docker Compose para definir aplicaciones multicontenedor en lugar de configurar manualmente Dockerfiles separados para cada contenedor. Después de configurar el único archivo YAML, puede ejecutar todos los contenedores necesarios con un único comando en su consola Linux. Utilizar Docker Compose es una forma de orquestar sus contenedores Docker, pero existe una potente alternativa a Docker Compose 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 en contenedores con un alto grado de automatización.
Kubernetes es un proyecto de Google destinado a automatizar la instalación, ampliación y disponibilidad de aplicaciones que se ejecutan en contenedores. Puede aumentar el número de hosts que ejecutan contenedores hasta 11 o más hosts. Además, puede crear un clúster de contenedores Docker con Kubernetes para garantizar la alta disponibilidad y el equilibrio de carga.
Los hosts que se utilizan en un clúster se denominan nodos. El tipo de arquitectura de Kubernetes es maestro-esclavo: el clúster consta de nodos maestros y nodos de trabajo. El número mínimo recomendado de nodos que requiere Kubernetes es de cuatro. Aunque puedes crear un clúster con una sola máquina, para ejecutar todos los ejemplos y pruebas necesitas al menos cuatro nodos. Un clúster Kubernetes que gestiona el tráfico de producción debe 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 utilizar 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 clientes, programar operaciones con contenedores, ejecutar bucles de control, etc. Es necesario ejecutar una copia de la base de datos etcd que almacena todos los datos del clúster en cada nodo maestro. El nodo maestro ejecuta un conjunto de tres procesos: kube-apiserver, kube-controller-manager y kube-scheduler.
- Los nodos de trabajo se utilizan para ejecutar cargas de trabajo de aplicaciones ejecutando contenedores. Los dos procesos de Kubernetes se ejecutan en el nodo no maestro: kubelet (para comunicarse 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 que se utiliza para garantizar que las réplicas Pod cuyo número se especifica estén siempre en ejecución en un momento dado. Así puede asegurarse de que los Pods estén siempre disponibles cuando los necesite.
Se utilizan diferentes CLI y API para comunicar servicios entre sí si se utiliza 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 de programación básica en Kubernetes. Se trata de un grupo de recursos en el que pueden trabajar 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 del Pod están aislados pero pueden comunicarse entre sí con bastante facilidad. Por lo tanto, los Pods se utilizan generalmente en Kubernetes, pero si se utiliza una aplicación Docker independiente, sólo se dispone de grupos de contenedores.
- Servicio es un conjunto de contenedores que trabajan juntos proporcionando, por ejemplo, el funcionamiento de una aplicación multinivel. Kubernetes admite la asignación dinámica de nombres y el equilibrio de carga de Pods mediante el uso de abstracciones. Este enfoque garantiza una conexión transparente entre los servicios por el nombre, y le permite realizar un seguimiento de su estado actual.
- Las etiquetas son pares clave/valor que se vinculan 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 Kubernetes unido en múltiples clústeres virtuales. Cada clúster virtual puede existir dentro de un entorno virtual limitado por cuotas sin que ello repercuta en otros clústeres virtuales.
Kubernetes puede utilizarse con Docker, aunque Docker no es la única plataforma de contenedores con la que puede utilizarse Kubernetes. Kubernetes también puede funcionar en conjunción con contenedores Windows, contenedores Linux, rkt, etc. K8s es el nombre de Kubernetes que puede encontrarse a veces en la documentación técnica.
Kubernetes frente a Docker: comparación de redes
Repasemos las opciones de red de cada solución.
Docker proporciona tres modos de red para la comunicación en red entre contenedores.
Puente. Este modo se utiliza por defecto, creando un puente virtual de capa 3. El nombre de red en su 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), que permite a los contenedores comunicarse entre sí y conectarse a redes externas. Puede configurar el reenvío de puertos para la interfaz de red del equipo host si desea conectarse a un contenedor desde otros hosts y redes externas. De este modo, al conectarse al puerto apropiado de la máquina anfitriona se le redirige al puerto necesario del contenedor Docker. Puede crear más de una interfaz de red para un contenedor Docker si es necesario.
Anfitrión. En este modo, un controlador de red host garantiza que un contenedor no esté aislado del host Docker. El contenedor comparte la pila de red del host, y el nombre de host del contenedor es el mismo que el nombre de host del sistema operativo del host. Si ejecuta un contenedor en el que se escucha un puerto TCP 8080, la aplicación del contenedor estará disponible en el puerto TCP 8080 de la dirección IP de la máquina anfitriona. El controlador de red host sólo está disponible para máquinas Linux.
Ninguna. No se configura ninguna dirección IP para la interfaz de red de un contenedor determinado, excepto la dirección 127.0.0.1 para la interfaz loopback. No hay acceso a redes externas si está configurado el modo de red Ninguno.
Redes multihost para contenedores Docker. Si los contenedores se ejecutan en hosts diferentes, pueden comunicarse entre sí después de configurar la red superpuesta. Debe configurarse un servicio válido de almacén de valores clave(Consul, Etcd o ZooKeeper) para crear este tipo de redes.
Kubernetes. Si utiliza contenedores Docker independientes, cada contenedor puede considerarse como una unidad básica que se comunica a través de la red utilizando la interfaz de red adecuada. Si utiliza 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 consistir en 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 utiliza porque un Pod que consta de varios contenedores sigue teniendo una única dirección IP.
Además, Kubernetes crea un contenedor de pausa especial para cada Pod. Este contenedor especial está destinado a proporcionar una interfaz de red (para comunicación interna y externa) para otros contenedores, y suele estar en pausa (en modo de suspensión). Estos contenedores en pausa se despiertan cuando Kubernetes envía una señal «SIGTERM».
Flannel se utiliza normalmente como un tejido de red para conectar contenedores en Kubernetes utilizando principios de superposición de red. La red superpuesta permite ejecutar contenedores comunicando a través de la red lógica 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 las correspondencias entre las direcciones IP reales asignadas a los contenedores por los hosts en los que se ejecutan los contenedores y las direcciones IP de la red superpuesta.
Las redes Kubernetes pueden integrarse con VMware NSX-T mediante el complemento NSX Container Plugin. Esta integración permite utilizar una topología de red multi-inquilino que no está disponible «out of the box» en Kubernetes.
El modelo de red de Kubernetes ofrece las siguientes funciones:
- Todos los contenedores pueden comunicarse con cualquier otro contenedor dentro de un clúster sin NAT.
- Todos los nodos del clúster pueden comunicarse con todos los contenedores de un clúster sin NAT. A la inversa, 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 del clúster desde el exterior (principalmente HTTP y HTTPS). Puede configurar Ingress para que realice el acceso externo a los servicios en contenedores, para el equilibrio de carga, la terminación SSL y el alojamiento virtual basado en nombres. Debe desplegarse un controlador de entrada en el nodo maestro para que funcionen las reglas de entrada.
Casos prácticos
El uso de Docker como 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 utilizar Docker para ejecutar aplicaciones en entornos aislados. Si desea utilizar Docker para ejecutar un elevado número de contenedores en el entorno de producción, puede encontrarse con algunas complicaciones en el camino. Por ejemplo, algunos contenedores pueden sobrecargarse o fallar con facilidad. Puede reiniciar manualmente el contenedor en la máquina adecuada, pero la gestión manual puede consumir mucho de su valioso tiempo y energía.
Kubernetes permite resolver estos problemas proporcionando funciones 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 muy cargados con un elevado número de contenedores Docker. La instalación de Kubernetes es más difícil que la de una aplicación Docker independiente, por lo que Kubernetes no siempre se utiliza para el desarrollo y las pruebas.
Kubernetes frente a Docker Swarm
Docker Swarm es una herramienta de agrupación nativa para Docker que puede convertir un grupo de hosts Docker en un único host virtual. Docker Swarm está totalmente integrado con el motor Docker y permite utilizar API y procesos de red estándar; está pensado para desplegar, gestionar y ampliar contenedores Docker.
Swarm es un clúster de hosts Docker que se denominan nodos. Consideremos los siguientes componentes principales de un clúster cuando se utiliza Docker Swarm antes de comparar la implementación del clúster con Kubernetes y Docker Swarm:
Los nodos gestores se utilizan para realizar la orquestación del control, la gestión del clúster y la distribución de tareas.
Los nodos trabajadores se utilizan para ejecutar contenedores cuyas tareas son asignadas por los nodos gestores. Cada nodo puede configurarse como nodo Gestor, nodo Trabajador, o como ambos, de forma que realice funciones tanto de nodo Gestor como de nodo Trabajador. Tenga en cuenta que los nodos trabajadores ejecutan servicios de enjambre.
Servicios. Un servicio de Docker Swarm define el estado óptimo requerido para cada servicio en contenedor. Un servicio controla parámetros como el número de réplicas, los recursos de red disponibles para él, los puertos que deben ser accesibles desde redes externas, etc. La configuración del servicio, como la configuración de red, puede modificarse y aplicarse 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 único contenedor. Las tareas son las partes de un servicio Swarm.
Así pues, Docker Swarm y Kubernetes son dos plataformas diferentes utilizadas para fines similares. Ahora es el momento de compararlos en un conjunto adecuado de categorías.
Instalación de clústeres
Docker Swarm. Una API estándar de Docker permite desplegar un clúster con Swarm utilizando una CLI (interfaz de línea de comandos) estándar de Docker que facilita el despliegue, especialmente cuando se utiliza por primera vez. La facilidad de instalación de Swarm en comparación con Kubernetes también se consigue gracias a la capacidad de un único maestro Docker para decidir cómo distribuir los servicios. En Docker Swarm no se utilizan Pods.
Kubernetes requiere el uso de comandos específicos que son diferentes de los comandos estándar de Docker. En Kubernetes se utilizan API específicas, lo que significa que, aunque conozca los comandos para la gestión de Docker, es posible que también tenga que aprender a utilizar un conjunto adicional de herramientas para la implantación de Kubernetes. Los nodos deben definirse manualmente en el clúster de Kubernetes: debe seleccionar el nodo maestro, definir el controlador, el programador, etc.
Escalabilidad
Docker Swarm. Gracias a la sencilla API que proporciona Docker, el despliegue de contenedores y la actualización de servicios en clústeres grandes y pequeños pueden realizarse con mayor rapidez. La interfaz de línea de comandos (CLI) es bastante sencilla 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 funciones que a menudo se traducen en un proceso de instalación más lento. Hay tres tipos de componentes que deben ser configurados: Pod, Instalación y Servicio. Cuando se trata de autoescalado, Kubernetes es preferible debido a su capacidad para analizar las cargas del servidor, además de proporcionar la oportunidad de ampliar y reducir automáticamente de acuerdo con los requisitos dados. Kubernetes es la opción óptima para grandes redes distribuidas y sistemas complejos.
Alta disponibilidad
Las dos opciones de solución poseen mecanismos similares de replicación y redundancia de servicios, y en ambos casos el sistema se autorregula y no requiere reconfiguración manual después de que un nodo averiado vuelva a convertirse en clúster.
Docker Swarm. Los nodos gestores gestionan los recursos de los nodos trabajadores y de todo el clúster. Los nodos del cluster Swarm asisten en la replicación de servicios.
Kubernetes. Los servicios de equilibrio de carga de Kubernetes detectan los nodos no saludables y los eliminan del clúster. Todos los Pods se distribuyen entre nodos, proporcionando así una alta disponibilidad, en caso de que falle un nodo en el que se esté ejecutando una aplicación en contenedor.
Equilibrio de la carga
Docker Swarm. El equilibrio de carga es una función integrada y puede realizarse automáticamente utilizando la red interna de Swarm. Todas las peticiones al clúster se distribuyen y redirigen a los nodos del clúster; cualquier nodo puede conectarse a cualquier contenedor. Un elemento DNS es utilizado por Docker Swarm para distribuir las solicitudes entrantes a los nombres de servicio.
Kubernetes. Las políticas definidas en Pods se utilizan para el equilibrio de carga en Kubernetes. En este caso, los Pods contenedores deben definirse como servicios. Tiene que configurar manualmente los ajustes de equilibrio de carga, mientras que Ingress puede utilizarse para el equilibrio de carga.
Crear y ejecutar contenedores
Docker Swarm. La gran mayoría de los comandos que están 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 exacto de réplicas puede establecerse 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 se pueden utilizar para desplegar contenedores en este caso. En Kubernetes, el sistema de definición de servicios sigue un principio de funcionamiento similar al de Docker Compose, pero es más complejo. Las funciones de Docker Compose se llevan a cabo mediante el uso de pods, implementaciones y servicios en Kubernetes, dentro de los cuales cada capa se utiliza para su propio propósito específico. Los pods se encargan de la interacción de los contenedores, mientras que las instalaciones se encargan de la alta disponibilidad y la conexión en red de un único nodo del clúster (de forma muy parecida a Docker Compose para una aplicación Docker independiente sin Swarm), y los servicios de Kubernetes se encargan de la configuración del funcionamiento de los servicios dentro del clúster, la tolerancia a fallos, etc.
Red
Docker Swarm. Existe una red interna predeterminada para la comunicación de los contenedores dentro de un clúster, a la que se pueden añadir más redes si es necesario. Las redes se protegen con certificados TLS generados. La generación manual de certificados es compatible con el cifrado del tráfico de datos de los contenedores.
Kubernetes. El modelo de red de Kubernetes es bastante diferente y se implementa mediante el uso de plugins, uno de los cuales es Flannel, la opción más popular. Los pods interactúan entre sí, y esta interacción puede restringirse mediante políticas. Existe una red interna gestionada por el servicio etcd. El cifrado TLS también está disponible, pero debe configurarse manualmente. El modelo de red de Kubernetes presupone la configuración de dos CIDR, Classless Inter-Domain Routing, lo que también se conoce como supernetting.
supervisión
Docker Swarm. No hay herramientas integradas de supervisión y registro, aunque puedes configurar manualmente herramientas de supervisión de terceros. Para ello se pueden utilizar ELK o Reimann.
Kubernetes. Kubernetes proporciona herramientas integradas para el registro y la supervisión. Elasticsearch y Kibana (ELK) pueden utilizarse para supervisar el estado de todo el clúster, mientras que Heapster, Grafana e Influx son compatibles para supervisar los servicios de contenedores.
Interfaz gráfica de usuario (GUI)
Docker Swarm. La interfaz gráfica de usuario puede habilitarse con herramientas de terceros como Portainer.io, que proporciona una interfaz web fácil de usar. Como alternativa, puede utilizar la edición Enterprise de Docker, que proporciona una interfaz gráfica para la gestión de clústeres.
Kubernetes. La GUI proporcionada por Kubernetes es un panel de control fiable al que se puede acceder a través de una interfaz web con la que puede controlar fácilmente su clúster. La GUI puede ser una herramienta muy valiosa para los usuarios con una experiencia mínima en la gestión 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 cambio, es el proyecto de Google que se utiliza para desplegar un clúster en el que se ejecutan contenedores.
Tanto Docker Swarm como Kubernetes ofrecen funciones de alta disponibilidad, equilibrio de carga, redes superpuestas y escalabilidad. Docker Swarm es el más sencillo de los dos para la instalación, ya que la configuración de la mayoría de sus funciones está automatizada y consume pocos recursos de hardware. Sin embargo, las funciones están limitadas por la API de Docker y faltan herramientas de supervisión nativas.
Kubernetes, por su parte, es una solución modular con un alto nivel de flexibilidad que cuenta con el respaldo de la mayoría de las grandes entidades corporativas desde hace varios años. Para Kubernetes se dispone de herramientas integradas para la supervisión de los servicios y de todo el clúster, aunque la instalación y la configuración son más difíciles, lo que convierte a este recurso en una solución más exigente. Kubernetes no es compatible con Docker CLI y Docker Compose. El uso de Kubernetes es preferible en entornos grandes donde se ejecutan aplicaciones multicontenedor muy cargadas.
