Estoy seguro que ya habrás escuchado hablar de Kubernetes antes. Una plataforma basada en código abierto creada por Google cada vez más popular desde su primera versión en 2013. El objetivo de Kubernetes es hacer la vida más fácil de aquellos que trabajamos en el desarrollo de aplicaciones basadas en contenedores Docker al orquestar o coordinar la gestión de múltiples desarrollos simultáneamente a gran escala en un mismo proyecto.
Cuando trabajamos con aplicaciones grandes y distribuidas en contenedores es fácil encontrar el problema de coordinar su funcionamiento y administración. Al hacer que las aplicaciones en contenedores sean mucho más fáciles de administrar a escala, Kubernetes se ha convertido en una parte clave de la revolución de los contenedores.
Trabajar con contenedores ha cambiado por completo la forma en la que las personas piensan sobre el desarrollo, la implementación y el mantenimiento del software. Los contenedores permiten un ahorro de tiempo en su despliegue, similar a una máquina virtual pero con mucha menos sobrecarga y mucha más flexibilidad, liberándonos de preocupaciones añadidas. Click and point como si estuviéramos trabajando con un juego de construcción por bloques, en una arquitectura basada en contenedores los diferentes servicios que constituyen una aplicación se empaquetan de manera separada y se implementan en un clúster de máquinas físicas o virtuales.
Cuando el desarrollo es simple su administración no requiere de grandes recursos pero a medida que nuestro proyecto crece aparece la necesidad de orquestación de contenedores, una herramienta que automatiza la implementación, la administración, el escalado, la creación de redes y la disponibilidad de aplicaciones basadas en esta tecnología.
La arquitectura de Kubernetes, no es en grandes rasgos difícil de entender. Como toda tecnología hace uso de varios conceptos y abstracciones. La mayoría de estas nos resultan conocidas pues son variaciones de las nociones existentes y familiares, pero otras son específicas de Kubernetes.
Esta es la abstracción Kubernetes de más alto nivel. Un clúster se refiere al grupo de máquinas que ejecutan Kubernetes (en sí, es una aplicación en clúster) y los contenedores administrados por él. Un clúster de Kubernetes debe tener un maestro, el sistema que ordena y controla todas las otras máquinas de Kubernetes en el clúster. En esta estructura, el clúster de Kubernetes de alta disponibilidad replica las instalaciones del maestro en múltiples máquinas. Pero solo un maestro a la vez ejecuta el planificador de trabajos y el controlador-administrador.
Cada cluster contiene a su vez los nodos de Kubernetes. Estos nodos pueden ser máquinas físicas o máquinas virtuales. Una vez más, la idea es la abstracción: sea cual sea la aplicación en la que se ejecuta, Kubernetes se encarga de la implementación en ese nivel. Kubernetes incluso hace posible garantizar que ciertos contenedores se ejecuten solo en máquinas virtuales o directamente en un servidor físico (bare-metal).
Los nodos ejecutan pods, los objetos de Kubernetes más básicos que se pueden crear o administrar. Cada pod representa una única instancia de una aplicación o proceso en ejecución en Kubernetes, y consta de uno o más contenedores.
Kubernetes se encarga de iniciar, detener y replicar todos los contenedores en un pod como grupo. Las cápsulas mantienen la atención del usuario en la aplicación, en lugar de en los propios contenedores. Los detalles sobre cómo se debe configurar Kubernetes, desde el estado de los pods en adelante, se mantienen en Etcd , un almacén de valores clave distribuido.
Los pods se crean, despliegan y destruyen en los nodos según sea necesario para cumplir con el estado deseado especificado por el usuario en la definición del pod mediante el controlador que Kubernetes encargado de su gestión.
Debido a que los pods viven y mueren según sea necesario, necesitamos una abstracción diferente para lidiar con el ciclo de vida de la aplicación. Se supone que una aplicación es una entidad persistente, incluso cuando las vainas que ejecutan los contenedores que componen la aplicación no son persistentes. Para ese fin, Kubernetes proporciona una abstracción llamada servicio.
Un servicio en Kubernetes describe cómo se puede acceder a un grupo determinado de pods (u otros objetos de Kubernetes) a través de la red. Como dice la documentación de Kubernetes , los pods que constituyen el back-end de una aplicación pueden cambiar, pero el front-end no debería tener que saberlo o rastrearlo. Los servicios lo hacen posible.
Kubernetes tiene varios componentes que la comunicación de los diferentes servicios con el mundo exterior con diversos grados de simplicidad y robustez, incluidos NodePort y LoadBalancer, pero el componente con mayor flexibilidad es Ingress. Ingress es una API que administra el acceso externo a los servicios de un clúster, generalmente a través de HTTP.
Y ya por último toca mencionar el Panel, un componente que nos ayuda conocer el estado de todos los componentes que componen nuestro cluster y proyecto. Este panel de control o Dashboard se presenta como una interfaz de usuario basada en web con la que puede implementar y solucionar problemas de aplicaciones y administrar los recursos del clúster.
Debido a que Kubernetes presenta nuevo conceptos y quizá una curva de aprendizaje que requiere de tiempo y recursos para su implementación resulta inevitable preguntar cuáles son sus beneficios a largo plazo. Aunque las razones no son pocas y dependen de cada escenario este es un resumen de algunas de las razones por las que ejecutar aplicaciones dentro de Kubernetes se vuelve más fácil en comparación con otras opciones.
Kubernetes es una tecnología basada en código abierto y está disponible de muchas formas. Podemos descargar y compilar su código nosotros mismos, descargar una distribución comercialmente respaldada o directamente contratar un servicio de un proveedor en la nube. Por ejemplo:
Kubernetes es actualmente una de las tecnologías de moda y cuenta con un notable éxito con el respaldo de compañías como Google, IBM, Red Hat, etc, además de una más que activa comunidad de usuarios. Comenzar a usar Kubernetes es el siguiente paso lógico si ya trabajas con Docker o si tienes experiencia en el despliegue de aplicaciones basado en contenedores. El cómo hacerlo, depende en gran medida de la elección que hagamos de acuerdo a las necesidades de nuestro proyecto y el tiempo que deseemos invertir en configurar nuestro entorno al detalle o directamente lanzarnos a experimentar sus posibilidades para mejorar nuestras habilidades con esta tecnología.