Concrete Logo
Hamburger button

Todo lo que usted necesita saber sobre Kubernetes – Parte 1

  • Blog
  • 18 de Junho de 2019
Share



Usted ya debe haber oído hablar de Kubernetes, ¿no? En el blog de Concrete ya hemos hecho un post con una pequeña introducción sobre el tema, diferenciando de Openshift y Docker. En este post, sin embargo, voy a explicar lo que es, para qué sirve y porque la comunidad está bien interesada en usarlo para escalar ambientes en producción. ¿Vamonos?

El Kubernetes

Antes de empezar voy a dar una pista:

Este es el logotipo de Kubernetes, un timón de barco. ¿Puedes imaginar lo que hace? =) Vamos entonces! ¡Es hora de asumir el control de estos contenedores!

El Kubernetes, o K8S (un juego de palabras con el nombre Kubernetes – k + 8 caracteres + s) o “kube”, para aquellos que ya están más íntimos, es un sistema de clúster y orquestación para contenedores Docker que soporta otros sistemas de contenedor, como el Rocket, por ejemplo.

En otras palabras, Kubernetes es una herramienta de código abierto que se utiliza para orquestar y administrar clústeres de contenedores. Sólo que aquí el clúster son varias máquinas con un motor de contenedor, que en nuestro caso y en la mayoría de todos los casos es Docker, el motor más usado para ese trabajo de aprovisionar los contenedores en los hosts del clúster.

Kubernetes entra aquí para administrar estos hosts y ejecutar las demandas que recibe el clúster. Muchas personas todavía tienen duda o confusión tratando de comparar Docker y Kubernetes, pero la comparación correcta sería “Docker Swarm” y Kubernetes, ambas herramientas de orquestación de clúster. Kisketes utiliza Docker para crear los contenedores en los nodos del clúster. Su trabajo aquí es administrar, controlar y monitorear el estado de estos contenedores a lo largo del clúster.

UN POCO DE HISTORIA

Kubernetes fue creado y desarrollado por los ingenieros de Google, uno de los pioneros en el desarrollo de la tecnología de contenedores. Google ya ha revelado que ejecuta algunos de sus servicios en contenedores, como Google Docs y Gmail, por ejemplo, y tiene algunas cifras surrealistas: son más de 2 mil millones de implementaciones de contenedores por semana, que son viabilizadas por una plataforma interna llamada Borg, antecesor del Kubernetes y que sirvió como base para su desarrollo.

En 2015, el Kubernetes fue donado a la “Cloud Native Computing Foundation” y Linux Foundations, y se convirtió en un proyecto de código abierto. Una curiosidad sobre el Kubernetes es que los siete rayos del logotipo hacen referencia al nombre original del proyecto, “Proyecto Seven of Nine” (Proyecto Siete de Nueve).

La palabra Kubernetes viene de la palabra griega Kuvernetes, que representa a la persona que pilota el barco.

ESTRUCTURA DE LOS KUBERNETES

Kubernetes tiene algunos términos y componentes para determinadas funciones y tareas. Inicialmente, puede parecer confuso y no tener mucho sentido algunos de estos componentes, pero cuando empiezas a usar Kubernetes y entender cómo funciona, es más fácil saber lo que cada uno de ellos hace.

Antes de ellos, sin embargo, vamos a hablar de cómo es la estructura del clúster. Hasta este punto, es muy similar al Enjambre, en el que tenemos los nudos de Maestros y Obra, que llamamos “Minions” aquí. Este concepto ya no se utiliza, pero todavía se puede encontrar en algunos artículos y documentos más antiguos.

Master, a su vez, es la máquina que controla los nudos de Kubernetes. Es en ella que todas las asignaciones de tareas del clúster se originan. En el Master tenemos todos los componentes girando, así:

Ahora vamos a los componentes, o los servicios que suben en la máquina Master para mantener el estado deseado de nuestros servicios en el clúster. Son cuatro:

•ETCD: es una base de datos de clave de valor. Almacena los datos de configuración del clúster y el estado del clúster;

•API de servidor: proporciona API de kriptetes utilizando Jason. Los estados de objetos de la API se almacenan en el ETCD, y el kubectl utiliza el API Sirve para comunicarse con el clúster;

•Controller Manager: supervisa los controladores de replicación y crea los pods para mantener el estado deseado;

•Scheduler: es responsable de realizar las tareas de programación, como la ejecución de contenedores en los minions basados ​​en la disponibilidad de recursos.

 Kubectl es una utilidad de línea de comandos que se conecta al servidor API, utilizado por los administradores para crear pods, deployments, servicios, etc. Este tipo vamos a usar bastante para gestionar nuestro clúster. Workes es el nombre dado para cada host del clúster (nodos o nodos). Son las máquinas que realizan las tareas solicitadas.

¿Y cuáles son los componentes que giran en los Minions?

Kubelet: agente que se ejecuta en cada nodo de trabajo, se conecta a Docker y se encarga de la creación, ejecución y eliminación de contenedores;

Docker: ni necesito ni hablar mucho, ¿verdad? Es responsable de rodar y ejecutar los contenedores, sólo que quien va a solicitar es el Kubernetes;

Kube-Proxy: reenvía el tráfico a los contenedores apropiados basados ​​en la dirección IP y en el número de puerto de la solicitud recibida.

Además de estos, todavía tenemos algunos conceptos que son interesantes tener en mente en el Kubernetes:

Pod, se puede definir como un grupo de contenedores que se implementan en un solo nodo de trabajo. Es la unidad más pequeña dentro de un clúster Kubernetes y nada más es que contenedores que se ejecuta dentro de su clúster de Kubernetes. Puede ser un contenedor girando nginx, php, apache, etc. Puede ser la abstracción de contenedores, puede tener uno o más contenedores en un Pod y puedo tener varios Pods dentro de cada nodo.

Replication Controller es el responsable de mantener un número determinado de pods en ejecución. Es en el RC que usted dice cuántos contenedores desea que se ejecute para atender a un determinado servicio, y si un caiga el RC otra instancia se crea automáticamente. Por ejemplo: en tres réplicas de Nginx, el RC es responsable de garantizar el estado de ese servicio, y si uno cae el RC sube otro automáticamente.

 Services es el responsable de atrelar una banda de IP a un determinado RC. Cada vez que el RC crea una nueva instancia de pod, se inicia con una IP determinada por el servicio. Servicios será el punto de entrada de nuestros servicios.

Con el espacio de nombres usted puede dividir su Clúster de Kubernetes en dos ambientes, como Producción y prueba, por ejemplo, pudiendo limitar los recursos computacionales para ambos.

¿CUÁNDO USAR KUBERNETES?

Kubernetes se puede ejecutar en varias plataformas: en su computadora portátil, VMs en un proveedor de nube y en varios servidores de bare metal, además de poder instalar en varios sistemas Linux (Centos, Ubuntu, Debian o Redhat). La principal ventaja de usar es que los clusters pueden abarcar hosts en nubes públicas, privadas o híbridas y funciona muy bien para entornos que rondan varios contenedores con varios nodos a gran escala. Todavía soporta más de un runtime de contenedor, alta disponibilidad, escalable entre otros factores.

 Por otro lado, la documentación no es amigable para los marineros de primer viaje y la curva de aprendizaje es más larga si se compara con su competidor directo, el Docker Swarm.

Sin embargo, vale recordar que el hecho de que el Kubernetes es más difícil no lo desabona en nada! La plataforma es excelente para este tipo de trabajo y es más madura que el Swarm, que es relativamente nuevo en comparación con los Kubernetes. La comunidad es muy buena y viene creciendo cada día, y además el sitio de kubernetes.io viene tratando de dejar la documentación más fácil, separando los temas y sugiriendo tutoriales.

 Estos son sólo algunos de los motivos que hacen que el Kubernetes sea más utilizado en la producción y ser el queridito de la mayoría. Pero si usted todavía no está convencido puede saber más acerca de un reciente caso interesante, el Pokémon Go.

A finales de 2017, la propia Docker lanzó la compatibilidad entre Docker y Kubernetes, y con esa versión de Docker podemos tener en el mismo cluster el Swarm y el Kubernetes. Es sólo elegir qué orquestal queremos en el momento de la implantación de los servicios.

Pero eso es asunto para otro post =)

EL MINIKUBE

Como ya hemos hablado, la configuración de Kubernetes es más compleja si se compara con su competidor Docker Swarm. Para realizar un lab o incluso colocar un ambiente en producción da un poco de trabajo y demanda más conocimiento de red y ambientes distribuidos de quien va a ejecutar e implementar el cluster. Antiguamente, cuando íbamos a realizar un laboratorio de Kubernetes el mínimo requerido era cinco máquinas para simular un clusters con tres Master y dos Workes / Nosotros.

Pensando en ello la galera de la comunidad creó el Minikube, así como Docker hizo con Docker Toolbox, para facilitar los labs / estudios y dejó un poco más suave la vida de quien está empezando con el Kubernetes. La herramienta sube rápido un ambiente, en el que es posible conocer y ver el Kubernetes funcionando, usando el VirtualBox para crear la Vm del Minikube. El setup es muy tranquilo y podemos correr en cualquier plataforma Windows / Linux o Mac.

Esto ayudó mucho, ya que el Minikube simula un clúster real de un solo nodo con todo lo necesario ya instalado y funcionando. También ha subido algunos servicios que son usados ​​por el sistema, el de red para los pods se comunican por el cluster y un pod que es el Dashboard de Kubernetes. Este último sirve para facilitar y tener una visión general del cluster usando interfaz gráfica, basta pasar la URL del cluster en el navegador, que en nuestro caso es el Minikube corriendo en nuestra máquina.

Aquí está el enlace del Github de Minikube.

Después de esta introducción, es hora de poner la mano en la masa, ¿verdad? Cálmate! Mañana vuelvo con esa parte del post. Pero si usted tiene alguna duda o alguna contribución hasta aquí, no deje de dejar abajo su comentario. ¡Hasta mañana!