Introducción

Kubernetes es una tendencia en auge. En los últimos años, Kubernetes (k8s) ha experimentado un rápido ascenso desde ser un pequeño proyecto de código abierto de Google hasta llegar a ser el proyecto principal de la Cloud Native Computing Foundation (CNCF).

¿Qué es Kubernetes?

Kubernetes es un sistema de orquestación de clusters. Fue diseñado desde el principio para ser un entorno para construir aplicaciones distribuidas a partir de contenedores.

El objetivo de Kubernetes es simplificar la organización y la programación de tus aplicaciones a través de la flota. Básicamente, te permite no preocuparte por cuáles máquinas en concreto en el centro de datos ejecutan qué componentes de tu aplicación.

Además, proporciona primitivas comunes para probar y replicar tu aplicación en estas máquinas, así como servicios para conectar tu aplicación a los microservicios para que cada capa de tu aplicación esté separada de las otras capas, para que puedas escalarla, actualizarla y/o mantenerla independientemente de las otras.

¿Por qué necesito la Orquestación de Contenedores?

1.Despliega aplicaciones en servidores sin preocuparte por servidores específicos.

Necesitas orquestadores de contenedores cuando tienes una aplicación de microservicios formada por varios servicios, los cuales consisten en contenedores. Y hay otro motivo: los servidores en los que se puede ejecutar esta aplicación.

El orquestador de contenedores realiza muchas tareas. La primera tarea consiste en colocar inicialmente los contenedores de tu aplicación en el número necesario de servidores, teniendo en cuenta la carga de los servidore para evitar que el contenedor llegue a un servidor sobrecargado, y considerando también los requisitos de memoria y de procesador para un contenedor determinado.

2. Escala la aplicación horizontalmente, hacia arriba y hacia abajo.

Existe otro escenario, en el que es necesario escalar horizontalmente una aplicación, añadiendo más contenedores del mismo tipo.

El orquestador del contenedor realiza la tarea de escalar hacia arriba o hacia abajo las aplicaciones teniendo en cuenta los recursos consumidos en cada servidor de destino, así como los requisitos de recursos de cada aplicación.

En este caso, el orquestador puede apoyar los llamados principios de afinidad y anti-afinidad. Este último permite garantizar que, por ejemplo, todos los contenedores del mismo tipo se lanzarán en diferentes servidores físicos.

3. Restaura la aplicación si el servidor en el que ha funcionado falla

Esto se llama auto-curación o reprogramación de contenedores.

Si el servidor falla, es necesario restaurar adecuadamente la aplicación. K8s puede monitorear cada contenedor/vaina (pod) de la aplicación para ver si ese contenedor/vaina está vivo o no. Y si no, Kubernetes lo reiniciará.

De hecho, en K8s, esta función se llama "mantener el número correcto de réplicas".

En el caso de los Kubernetes, puedes decir: "Quiero tener 5 contenedores de mi WordPress", y los K8 se asegurarán de que tengas siempre 5 contenedores. Si de repente hay menos de 5 contenedores, los Kubernetes lanzarán un nuevo contenedor para mantener la cantidad. Esto es importante para procesar la solicitud y predecir la carga.

K8s también monitorea el estado de los servidores en los que se ejecuta la aplicación, y si el servidor está muerto, reprogramará todos sus contenedores en otros servidores.

¿Cómo simplifica Kubernetes el despliegue contenedorizado?

Kubernetes ofrece varias ventajas de serie:

• En Kubernetes, hay un descubrimiento de servicio incorporado. En otras palabras, cuando aparece un nuevo servicio, se le asigna un nombre de dominio único y otros servicios pueden obtener información sobre este servicio en etcd.

• El segundo punto es que Kubernetes ofrece manifiestos flexibles para el despliegue de aplicaciones que soportan diferentes estrategias de despliegue de aplicaciones contenedoras. Kubernetes tiene soporte de despliegue para las pruebas A/B. También hay incorporados controles de salud y monitorización basada en Prometheus.

• Kubernetes utiliza una estrategia de actualización continua para desplegar las actualizaciones de las versiones de los pods. La estrategia de actualización continua ayuda a evitar que la aplicación pierda el tiempo, ya que mantiene algunas instancias en funcionamiento en todo momento mientras se realizan las actualizaciones. Cuando las nuevas vainas de la nueva versión de despliegue están listas para manejar el tráfico, el sistema las activa primero y sólo después cierra las antiguas.

¿Cuál es la diferencia entre un Pod y un contenedor?

El problema es que la gente que viene del mundo Docker sólo trabaja con contenedores.

Están tratando de transferir el conocimiento que obtuvieron al usar el Docker Swarm y los contenedores para trabajar con los Kubernetes. Pero no funciona así. En Kubernetes, la unidad de control es la vaina, no el contenedor.

Una vaina es un grupo de uno o más contenedores que realizan una misma función. Éste es un componente de una sola aplicación. Kubernetes administra las vainas, las escala y monitoriza su estado. La aplicación en Kubernetes escala por el número de vainas, no de contenedores.

En una vaina, lo normal es que haya un solo contenedor, pero puede haber varios, y este conjunto de contenedores está rígidamente definido. Los contenedores de las vainas no se escalan de ninguna manera y hay que considerar esto cuando se diseñen las aplicaciones.

¿Por qué no Docker Swarm?

Docker Swarm fue creado por Docker Inc. y creció como orquestador para Docker. Kubernetes fue creado por Google inicialmente para uso interno pero ahora todo el mundo del código abierto está trabajando sobre él. Docker Swarm es un sistema cerrado.

Ambos tratan de resolver el mismo problema: La orquestación de contenedores en un gran número de hosts. Aunque son dos sistemas fundamentalmente similares, todavía hay diferencias:

• Kubernetes se está desarrollando mucho más rápido y ocupa la mayor parte del mercado  (Kubernetes 51% y Docker Swarm 11%).

• Docker Swarm es menos escalable y no tiene un soporte incorporado para el balanceo de carga, como sí tiene K8s. De hecho, Docker Swarm ofrece sólo un método de equilibrio de carga, que se basa en la apertura de un puerto fijo para cada servicio en cada servidor incluido en el clúster.

• A diferencia de Docker Swarm, K8s ofrece una implementación incorporada para el equilibrio de carga tanto interno (Este-Oeste) como externo (Norte-Sur). El balanceo interno lo proporciona el objeto Service y permite llegar desde una aplicación de un clúster a todas las instancias vivas de otra aplicación haciendo referencia al objeto Service. El Service es un balanceador de carga interno, que sabe en cada momento del tiempo cuáles de los backends de la aplicación están vivos y cuáles no funcionan, y envía solicitudes sólo a las réplicas vivas.

• El balanceo de carga externo en Kubernetes es proporcionado por el concepto de NodePort (abriendo un puerto fijo en el balanceador de carga), así como a través de la primitiva incorporada LoadBalancer, que puede crear automáticamente un balanceador de carga en la nube si Kubernetes trabaja en un entorno de nube, por ejemplo, AWS, Google Cloud, MS Azure, OpenStack, Hidora etc.

• Docker Swarm no soporta autoescalado, ni contenedores de autoescalado ni nodos de autoescalado.

• Kubernetes soporta todos los autoescaladores posibles: escalado vertical debido al Vertical Pod Autoscaler, aplicaciones de autoescalado horizontal (Horizontal Pod Autoscaler), así como el autoescalado del propio clúster (el número de nodos) basado en el Cluster AutoScaler. Este último sólo funciona si ejecutas Kubernetes en la nube.

• Docker Swarm tiene dificultades con la monitorización. Puede monitorear los contenedores en su mayoría sólo con la ayuda de herramientas propietarias.

• El almacenamiento persistente para aplicaciones con estado no está soportado de forma nativa en Docker Swarm. Tienes que trabajar con almacenamiento conectado a la red, lo cual no es bueno para todo tipo de cargas de trabajo.

• Docker Swarm sólo funciona con contenedores Docker, mientras que los K8 pueden funcionar con muchas opciones de tiempo de ejecución de contenedores, como Docker, Rocket, ContainerD y otros. Esto es muy importante porque no hay dependencia de características específicas de Docker (algunas de ellas sólo están disponibles en Docker EE).