Concrete Logo
Hamburger button

Todo lo que usted necesita saber sobre Kubernetes – Parte 2

  • Blog
  • 18 de Junho de 2019
Share



Volví, ahora para poner la mano en la masa y entender de vez lo que es el Kubernetes. Listo? Si no, echa un vistazo aquí en la primera parte de esta serie, en la que hago una larga introducción sobre el tema: qué es, cómo usar, cuáles son los principales términos y etc … La teoría está todo allí. Ok? Hoy vamos a la práctica. Bora!

A pesar de haber explicado en el primer post la arquitectura del cluster y mostrar la estructura necesaria para componer el Master y los Minions, pasando por los componentes que componen esa arquitectura, vamos a usar el Minikube como punto de partida. En breve vamos a hablar más aquí en el Blog sobre la creación del cluster pasando por la configuración y configuración y usando los conceptos que se han explicado.

En este repositorio (artículo-kubernetes) tiene todo lo necesario para ejecutar nuestra primera aplicación.

ANTES DE EMPEZAR

  • Asegúrese de tener instalado VirtualBox;
  • Descargar Minikube para la versión de tu sistema operativo;
  • Y el Kubectl para poder administrar nuestro cluster, que en nuestro caso es el Minikube.

¿Todo instalado? ¡Entonces vamos a trabajar!

En el terminal, vamos a subir el Minikube:

La salida será similar a la siguiente imagen. El comando va a bajar la ISO y subir una VM en el Virtualbox. No vamos a necesitar interactuar con Virtualbox y ni siquiera abrir para el Minikube funcionar. Si desea comprobar la VM girando, abra el Virtualbox y allí va a estar una máquina virtual con nombre de Minikube y el estado corriente.

El siguiente comando va a enumerar nuestros nodos y usar kubectl para ello. ¿Recuerdas que he dicho que íbamos a usar ese cariño para interactuar con el clúster? Así que ahora va a ser uno de nuestros mejores amigos! =)

Si todo ocurrió bien vamos a ver el Minikube con status “Ready”, es decir, está listo para recibir solicitudes. Este comando sirve para listar todos los nodos del clúster, y como sólo tenemos una máquina virtual que sólo va a aparecer aquí.
Ah, faltó clonar nuestro repositorio que vamos a usar para subir el servicio.

Ahora vamos a entrar en el directorio que acabamos de clonar del Git (kubernetes-basico-nginx), como en la imagen:

He enumerado los archivos de ese repositorio. Como pueden ver, tiene tres archivos YAML, que vamos a usar para crear los objetos en Kubernetes. Allí, todo lo que declaramos en el campo “Kind” en el archivo Yaml llamamos objetos. A título de curiosidad, vamos a crear un objeto de tipo Pod, pero antes vamos a abrir el archivo de aplicación .yaml para entender lo que este archivo está haciendo.

Primero especificamos qué API vamos a usar, y luego decimos qué tipo de objeto estamos declarando con “kind”. Después, vamos a usar un nombre para nuestro objeto en “metadata” y en el “spec” vamos a especificar cuál es el objeto que el Pod está abstrayendo, que en este caso es nuestro contenedor de Nginx. En esa parte informamos el nombre y la imagen que el contenedor va a usar y el puerto que ese contenedor va a responder, el puerto “80”.

Antes de crear el pod vamos a ver si no tiene ningún pod corriendo en nuestro clúster.

Este comando mostrará todos los objetos de tipo pod en nuestro clúster, y como todavía no creamos nada, la respuesta será: No resources found.

Ahora vamos a crear el Pod que contiene nuestra aplicación Nginx. En el directorio en el que tenemos nuestros archivos yaml, escriba el comando:

El mando es muy tranquilo y fácil de entender. Básicamente estamos informando al cluster con kubectl que queremos crear un objeto “create” pasando la flag “f” de archivo / archivo y la ruta de nuestro archivo, que aquí en nuestro ejemplo está en el mismo directorio. Entonces, sólo informamos el nombre del archivo: “aplicación.yaml”. La salida del comando indica que el objeto se ha creado, como se puede ver en la imagen anterior.

Ahora cuando usamos el comando “kubectl get pods” podemos ver el objeto creado.

¡Pero tenemos un problema! ¿Cómo accede a este contenedor?

La respuesta es: ¡no accedemos! En el caso de que el usuario no pueda acceder a este Pod, pero no es una buena práctica, ya que no exponemos un solo objeto Pod en el clúster, incluso porque pueden ser efímeros y mueren todo el tiempo, entonces no tiene sentido tener estos objetos incoherentes y con poca gerencia expuestos en clúster. Eso sin contar que si ese puede morir no sube a otro en su lugar. Para resolver estos problemas tenemos otros dos objetos, Deployments y Services.

Por lo que vamos a excluir este poder. El comando es similar a crear un objeto, la diferencia que en lugar de pasar “create” usamos el “delete”.

Listo! Objeto excluido de nuestro clúster.
Ahora vamos a abrir nuestro archivo deployment.yaml.

En este archivo se indica el tipo, que es un objeto Deployment.

Deployments sirven para decir al clúster el estado deseado de un objeto a ser implantado. Estoy diciendo que quiero subir tres réplicas de mi aplicación Nginx en el clúster y que ese estado se mantenga en caso de que un pod mura y sólo dos en el clúster. En este caso, el Kube va a subir al tercer Pod, manteniendo así el estado deseado. En el final del archivo decimos cuál es el tipo de objeto que estamos abstrayendo, que en nuestro ejemplo va a ser el Pod creado al principio de nuestro lab, pasando el nombre, la imagen y el puerto que va a usar.

El comando será similar al que ya conocemos:

¡Y pronto!

Vamos a ver.. ¿Cuántos Pods el Deployment creó? ¿Cómo hacemos para listar los Pods mismo? Sólo utilizar el comando:

Y podemos ver nuestros tres Pods creados allí! ¿Por qué? Si uno de estos puede morir, nuestro clúster tratará de subir otro. Si desea hacer las pruebas! En los ejemplos anteriores se puede ver cómo eliminamos un pod. Voy a dejar que pruebe esto, OK?

También podemos enumerar nuestros Deployments creados en el clúster.

Podemos observar cuántos puede entonces girar, cuántos están disponibles y el tiempo de vida de ese objeto.

Pero aún no llegamos donde queremos. Tenemos los tres Pods, garantizamos la disponibilidad de nuestro servicio pero aún falta acceder de hecho a estos Pods, en el caso, nuestra aplicación.

Para resolver esto vamos a usar el servicio. Él será el End Point de nuestros Pods, va a abstraerlos y englobándolos. Es un objeto de tipo service, también funciona como un equilibrador de carga para nuestra aplicación.

Vamos a abrir nuestro archivo “servico-aplicacion.yaml”.

Este archivo también es muy tranquilo de entender. En este caso, el tipo de objeto, como ya hemos aprendido, que será el servicio, pasamos el nombre de ese servicio, el tipo que será nuestro LoadBalancer, la puerta de los Pods que es el 80, y en el selector decimos cuál es el objeto que vamos a el servicio, que es el uso-nginx.

Nota: el nombre tiene que ser el mismo que se utilizó en nuestro ejemplo de Deployments.

Entonces, como ya estamos los safos, vamos a crear este objeto con kubectl en el clúster.

Bueno, vamos a comprobar si todo está bien. Como ya sabemos listar los objetos en el clúster y queremos listar el objeto Service, es fácil entender cómo interactuar con el clúster.

Como no especificé ningún puerto en mi archivo “servico-aplicacion.yaml”, el Kubernetes asigna un puerto al azar para nuestro servicio. Que, como podemos ver en la imagen, es 30848.

Obs: puede ser que cuando gire en su máquina la puerta sea otra. Colocar la puerta deseada en el archivo del service es un desafío que voy a dejar aquí, bien tranquilo de hacer.

¿Y ahora, cómo accedemos? ¿Cómo hacemos para recoger la URL y acceder a nuestra aplicación? Tiene dos maneras. O preguntando al Minikube:

O por el IP de nuestra VM del Minikube, pasando el puerto que fue listado con el comando kubectl get services, que nada más es lo que ese comando arriba hace.

Al colocar la dirección en nuestro navegador, usando el IP y la puerta que ya tomamos con los comandos arriba, podemos acceder de hecho a nuestra aplicación:

¡Y está ahí nuestra aplicación funcionando! Si abre otra pestaña, puede ver que vamos a caer probablemente en otra instancia, ya que estamos usando el Service LoadBalance.

He utilizado la misma imagen que está en el Docker Hub y que fue utilizada en el ejemplo del Post sobre Docker Swarm, que publiqué hace unas semanas aquí en el Blog, para mostrar que podemos alcanzar el mismo objetivo con ambos orquestadores de clúster. Esta también es una aplicación simple y ligera de reproducir por ser stateless.

Preview(opens in a new tab)

El último comando para mostrar es acceder al Kubernetes por la parte gráfica. Como estamos rodando con el Minikube, basta con ejecutar

Como podemos ver el comando se abrirá el navegador automáticamente y podemos acceder a la interfaz gráfica de nuestro clúster. Hemos logrado gestionar nuestros objetos creados a través de esta interfaz, así como lo hacemos con kubectl. Kubernetes muestra una supervisión de los servicios que se ejecutan en nuestro clúster. No voy a enfocar en esa parte, usted ahora puede explorar. =) De sólo el mapa del tesoro, Ahora le toca a usted encontrarlo.

CONCLUSIÓN

Kubernetes es mucho más que eso, tanto en la parte de configuración e implementación. En el repositorio del GitHub tiene más detalles y ejemplos de los comandos usados ​​aquí. He intentado reducir esta serie para dejar lo más claro posible, con ejemplos prácticos, cómo usar la herramienta. Si aún queda alguna duda o tiene algo que decir, aproveche los campos abajo. ¡Hasta la próxima!

Algunas referencias, si usted desea saber más:

  • Minikube: https://kiscetes.io/docs/getting-started-guides/minikube/
  • Kubernetes: https://kiscetes.io/
  • Kubernetes GitHub: https://github.com/kubernetes/kubernetes

¿Quieres trabajar en el mejor equipo de DevOps?
trabajeconnosotros@concrete.com.br