Introducción a Kubernetes

Hola a todos, mi nombre es Sai Venom y soy un defensor del desarrollo en IBM. Hoy estoy aquí con otro contenido en el que hablaré sobre todo lo relacionado con Kubernetes. Kubernetes es una herramienta de orquestación que te permite ejecutar y gestionar tus cargas de trabajo basadas en contenedores. En esta ocasión, quiero echar un vistazo general a una arquitectura de referencia de servicios de Kubernetes administrados y adentrarnos un poco más en cómo implementar tus microservicios.
¡Comencemos!

Arquitectura de referencia

Para comprender mejor Kubernetes, dividiremos el escenario en dos partes. En el lado izquierdo, tenemos el lado de la nube donde se encuentra el componente vital: el maestro de Kubernetes. El maestro de Kubernetes incluye varios componentes importantes, pero hoy nos centraremos en el servidor de API de Kubernetes. Este servidor de API, que se ejecuta en el maestro, es fundamental para ejecutar todas tus cargas de trabajo. Expone un conjunto de capacidades que nos permiten definir exactamente cómo deseamos ejecutar nuestras cargas de trabajo.

En el lado derecho, tenemos el lado administrativo del cliente donde se encuentran nuestros nodos de trabajo, que también se basan en Kubernetes. Aquí quiero señalar un componente importante que se ejecuta en cada uno de estos nodos de trabajo: el kubelet. El kubelet es el responsable de planificar y asegurarse de que nuestras aplicaciones estén sanas y funcionando correctamente en nuestros nodos de trabajo. Por lo tanto, el maestro y el kubelet trabajarán juntos con bastante frecuencia.

¿Por qué usar Kubernetes?

Antes de sumergirnos en la implementación de microservicios con Kubernetes, debemos preguntarnos por qué alguien querría usar Kubernetes en primer lugar. La respuesta es simple: si tienes una aplicación nativa de la nube compuesta por microservicios, estos microservicios interactúan entre sí a través de la red. Para simplificar este ejemplo, imaginemos que tenemos un front-end y un back-end, y estos son los dos componentes que queremos escalar y desplegar en nuestro clúster hoy.

Kubernetes utiliza YAML para definir los recursos que se envían al servidor de API, lo que resulta en la creación de la aplicación real. Comencemos dibujando un esquema de implementación de un pod, que es la unidad lógica más pequeña de Kubernetes. Un pod te permite ejecutar un contenedor simple en un nodo de trabajo. Imaginemos que tenemos un pod con una imagen ya empujada a Docker Hub, y vamos a usar mi propio registro para este ejemplo. El nombre de la aplicación simplemente será «F» (por front-end) y la versión será «1». También queremos asignar etiquetas a los pods, que son muy importantes para definir el tipo de artefacto que tenemos. Por lo tanto, asignaremos la etiqueta «app: F» a este pod.

Una vez que hemos creado el pod, lo vamos a desplegar en nuestros nodos de trabajo. Para hacer esto, utilizaremos la herramienta Kubectl para ejecutar el manifiesto del pod. Este manifiesto se enviará al servidor de API que se ejecuta en el maestro de Kubernetes, y a su vez, se comunicará con uno de los kubelets para desplegar el pod. Supongamos que se despliega en nuestro primer nodo de trabajo con la etiqueta «app: F». Además, el pod obtendrá una dirección IP interna que termina en «.1». En este punto, podríamos acceder al pod desde cualquiera de los nodos de trabajo utilizando esa dirección IP.

Escalando con despliegues

Si deseamos implementar y escalar nuestra aplicación aún más, Kubernetes ofrece una abstracción llamada «despliegue» que nos permite crear un estado deseado. Podemos definir el número de réplicas que queremos para ese pod, y si algo le sucede a un pod y muere, Kubernetes creará una réplica nueva automáticamente. Para crear un despliegue, necesitamos modificar nuestro manifiesto del pod anterior para convertirlo en una plantilla. Además, necesitaremos agregar la sección de réplicas y un selector que coincida con la etiqueta que ya hemos asignado. Por último, en lugar de especificar un pod, especificaremos un despliegue.

Una vez que hemos creado el despliegue, lo enviaremos a través de Kubectl y este enviará el manifiesto al servidor de API. Como el despliegue no es un objeto efímero, Kubernetes seguirá administrando el estado deseado mientras no eliminemos el despliegue. En este caso, creará tres réplicas del pod. Si en algún momento detecta que solo hay una réplica en funcionamiento, creará dos más automáticamente. Luego, Kubernetes seleccionará automáticamente los nodos de trabajo disponibles para desplegar las nuevas réplicas, asegurándose de que tengamos las tres réplicas en todo momento.

Podemos realizar el mismo procedimiento para nuestro servicio de back-end, creando otro despliegue con dos réplicas. Ahora, tenemos un estado deseado de tres réplicas para el pod del front-end y dos réplicas para el pod del back-end. Todos los componentes están trabajando juntos con el maestro de Kubernetes y los nodos de trabajo para permitirnos redefinir nuestro flujo de trabajo de DevOps para implementar nuestras aplicaciones en un servicio de Kubernetes administrado.

Comunicación entre servicios

Al interactuar con nuestros servicios, necesitamos una forma estable de acceder a ellos. Aunque cada pod tiene su propia dirección IP, cuando un pod muere y se vuelve a crear, recibe una nueva dirección IP. Si queremos acceder a esos pods desde el back-end o desde usuarios externos, necesitamos una dirección IP estable a la que podamos confiar. Este es un problema que ha existido desde hace mucho tiempo, y para solucionarlo se crearon capacidades de registro y descubrimiento de servicios que vienen integradas en Kubernetes.

Para lograr esto, crearemos un servicio que cree una dirección IP más estable para nuestros pods, de modo que podamos acceder a ellos como una sola aplicación en lugar de diferentes servicios individuales. Para hacer esto, crearemos una nueva sección en nuestro archivo YAML para definir el servicio. Necesitaremos especificar un selector que coincida con la etiqueta que hemos asignado, y también necesitaremos especificar el tipo de servicio que queremos utilizar. Por defecto, el tipo de servicio es «Cluster IP», lo que significa que los servicios solo pueden accederse dentro del clúster.

Incluiremos el servicio delantero y el servicio trasero en nuestro manifiesto para crear los servicios correspondientes. Ahora tenemos una dirección IP estable para cada uno de estos servicios que podemos utilizar para la comunicación entre ellos. Además, el servicio kube-DNS, que normalmente se ejecuta de forma predeterminada, facilita aún más la comunicación entre estos servicios, ya que pueden accederse entre sí mediante sus nombres (por ejemplo, front-end y back-end o F y B de forma abreviada).

Exponiendo a los usuarios finales

Pero, ¿cómo exponemos nuestro front-end a los usuarios finales? Para hacerlo, debemos especificar el tipo de servicio y lo que queremos es un balanceador de carga. Un balanceador de carga nos permite crear una dirección IP externa para que los usuarios finales puedan acceder a nuestro front-end directamente. Al hacerlo, creamos un punto de entrada externo para acceder a nuestro servicio sin preocuparnos por los nodos de trabajo internos en los que se ejecuta nuestro clúster Kubernetes.

En resumen, hemos hablado sobre tres componentes principales de Kubernetes: los pods, que se despliegan y gestionan mediante despliegues, y los servicios, que facilitan el acceso a los pods creados por los despliegues. Estos componentes funcionan junto con el maestro de Kubernetes y todos los nodos de trabajo para permitirte redefinir tu flujo de trabajo de DevOps para implementar tus aplicaciones en un servicio de Kubernetes administrado. Espero que esta explicación haya sido útil y que estés listo para profundizar en estos temas en futuros artículos relacionados. Si tienes alguna pregunta, no dudes en consultar nuestra sección de preguntas frecuentes a continuación. ¡Gracias por acompañarme hoy!

ComponentesDescripción
Maestro de KubernetesIncluye el servidor de API de Kubernetes, que es esencial para ejecutar las cargas de trabajo
Nodos de trabajoBasados en Kubernetes y alojan los pods
PodsUnidades lógicas más pequeñas de Kubernetes donde se ejecutan los contenedores
DesplieguesAbstracción para crear un estado deseado y gestionar réplicas
ServiciosFacilitan el acceso a los pods y crean direcciones IP estables

Preguntas frecuentes

1. ¿Cuál es la función del kubelet en Kubernetes?
El kubelet es responsable de programar y garantizar que las aplicaciones estén saludables y funcionando correctamente en los nodos de trabajo de Kubernetes.

2. ¿Qué son los despliegues en Kubernetes?
Los despliegues son una abstracción en Kubernetes que te permite crear un estado deseado para tus pods y gestionar réplicas automáticas en caso de fallos.

3. ¿Cómo se accede a los servicios en Kubernetes?
En Kubernetes, los servicios se acceden mediante direcciones IP estables que se crean para los pods. Además, el servicio Kub-DNS facilita aún más la comunicación entre ellos mediante el uso de los nombres de los servicios.

4. ¿Por qué usar Kubernetes en lugar de otras herramientas de orquestación de contenedores?
Kubernetes es una de las herramientas de orquestación de contenedores más populares y ampliamente utilizadas debido a su escalabilidad, capacidad de gestión y amplia comunidad de soporte.

5. ¿Cuál es la función del servidor de API de Kubernetes?
El servidor de API de Kubernetes es esencial para ejecutar todas las cargas de trabajo. Expone una serie de capacidades que permiten definir exactamente cómo se deben ejecutar las aplicaciones.

Espero que estas preguntas frecuentes hayan aclarado algunas dudas que puedas tener sobre Kubernetes. Si tienes más preguntas, déjalas en los comentarios y estaré encantado de responder. ¡No te olvides de suscribirte para recibir más artículos relacionados en el futuro!

¡Gracias por visitar mi blog y nos vemos la próxima vez!

¿Te ha resultado útil??

0 / 0

Deja una respuesta 0

Your email address will not be published. Required fields are marked *