Introducción a Kubernetes

En este artículo, cubriremos los siguientes temas:

• ¿Qué es Kubernetes?
• Componentes principales de Kubernetes (K8)

¿Qué es Kubernetes?

Kubernetes es un marco de orquestación de contenedores de código abierto desarrollado por Google. En esencia, controla la velocidad de los contenedores y ayuda a gestionar aplicaciones formadas de varios contenedores. Además, le permite operarlos en diferentes entornos, por ejemplo, máquinas físicas, máquinas virtuales, entornos de nube o incluso entornos de implementación híbridos.

¿Qué problemas soluciona?

La aparición de la contenedorización en la tecnología de microservicios ha dado lugar a aplicaciones compuestas por múltiples contenedores.

Sin embargo, administrar esos contenedores en múltiples entornos mediante scripts y herramientas de creación propia puede resultar complejo. Es por eso que este escenario específico generó la necesidad de desarrollar tecnologías de orquestación de contenedores, por ejemplo, herramientas de orquestación como Kubernetes que garantizan las siguientes características:

 

• Alta disponibilidad En palabras simples, significa que la aplicación no tiene tiempo de inactividad, por lo que siempre está accesible para los usuarios.
• Escalabilidad sugiere que la aplicación tiene un alto rendimiento, se carga rápido y los usuarios tienen tasas de respuesta muy altas de la aplicación.   
• Recuperación de desastres indica que en caso de que la infraestructura tenga algunos problemas (por ejemplo, los datos se perdieron, los servidores explotaron o ocurrió cualquier otro problema con el centro de servicio), debe haber un mecanismo para recoger los datos y restaurarlos al último estado para que que la aplicación principal no pierda ninguna información y que la aplicación en contenedor pueda ejecutarse desde el estado más reciente después de la recuperación

Principales componentes de Kubernetes (K8s)

A continuación, podéis encontrar una descripción general de los componentes principales de Kubernetes

Pod

Pod es un concepto fundamental y uno de los componentes centrales de Kubernetes. Un Pod es la unidad implementable más pequeña en Kubernetes y representa una instancia única de un proceso en ejecución en un clúster. Puede contener uno o más contenedores estrechamente acoplados y que comparten el mismo espacio de nombres de red, lo que les permite comunicarse entre sí.

¿Qué hace el pod? Crea un entorno de ejecución o una capa encima del contenedor Docker. Podemos tener un pod de aplicación para nuestra aplicación que posiblemente use un pod de base de datos con su contenedor. Un concepto importante aquí es que normalmente esperamos que el pod ejecute un contenedor de aplicaciones dentro de él. Sin embargo, también puede ejecutar varios contenedores dentro de un pod, pero generalmente, solo sucede si tiene el contenedor de la aplicación principal y un contenedor auxiliar o un servicio secundario que debe ejecutarse dentro de ese pod. Solo tiene un servidor y dos contenedores ejecutándose con una capa de abstracción encima.

Kubernetes ofrece una red virtual. Significa que cada pod obtiene su dirección IP pero no el contenedor. Como resultado, los pods pueden comunicarse entre sí mediante una dirección IP interna.

Los componentes pod en Kubernetes también tienen otro concepto importante llamado "efímero". Significa que pueden morir fácilmente, y cuando eso sucede (por ejemplo, si pierde un contenedor de base de datos porque falló o porque los nodos en el servidor que está usando se quedaron sin recursos), el pod morirá y se creará uno nuevo para reemplazarlo. Cuando ocurra ese evento, a un nuevo pod se le asignará una nueva dirección IP. Es un inconveniente si te estás comunicando con la base de datos usando la dirección IP ya que a partir de ahora tendrás que ajustarla cada vez que se reinicie el pod y porque se utiliza otro componente de Kubernetes llamado "Servicio".

Servicio

El servicio es una dirección IP estática o permanente que se puede adjuntar a cada pod, lo que significa que la aplicación tendrá un servicio y el pod de la base de datos tendrá otro servicio. Lo bueno aquí es que los ciclos de vida del servicio y el Pod no están conectados, por lo que incluso si el Pod muere, el servicio y su dirección IP permanecerán, lo que indica que ya no tendrás que cambiar el punto final.

Para acceder a una aplicación a través del navegador habría que crear un servicio externo. Es un servicio que abre la comunicación desde fuentes externas. Sin embargo, obviamente no querrá que su base de datos esté abierta a solicitudes públicas. Por eso sería necesario desarrollar algo llamado servicio interno.

 

Ingress

Cuando creamos un servicio externo, normalmente especificamos el protocolo HTTP, una dirección IP de nodo y el número de puerto que se parece a http://129.80.102.2:8080. Aunque es lo suficientemente bueno para fines de prueba, para el producto final querrás que tu URL se vea como http://nombre-dominio. Por eso se invirtió en otro componente de Kubernetes llamado "Ingress". Entonces, en lugar del servicio, la solicitud va primero a Ingress, que luego la reenvía al servicio.

ConfigMap

Es una regla general establecer comunicación a través de un servicio. En este caso, nuestra aplicación tendrá un endpoint de la base de datos. Sin embargo, ¿dónde solemos configurar la URL o el endpoint de esta base de datos? Normalmente, lo haríamos en el archivo de propiedades de la aplicación o como una variable ambiental externa. Sin embargo, generalmente se encuentra dentro de la imagen integrada de la aplicación. Por ejemplo, si el endpoint del servicio ha cambiado, tendríamos que ajustar esa URL en la aplicación. Significa que tendríamos que reconstruir la aplicación con una nueva versión y enviarla al repositorio. Luego tendremos que extraer esa nueva imagen en nuestro pod y reiniciar todo. Como podéis ver, es un poco tedioso para un cambio tan pequeño como la URL de una base de datos. Por ese motivo, Kubernetes tiene un componente llamado "ConfigMap".

Por lo general, contiene datos de configuración como URL de una base de datos o algunos otros servicios que empleamos en Kubernetes. Simplemente lo conectamos al Pod para que pueda obtener los datos que contiene ConfigMap. De ahora en adelante, si cambiamos el nombre del servicio y el endpoint, sólo necesitaremos ajustar el mapa de configuración.

Nos ayuda a gestionar los cambios de configuración independientemente del código de la aplicación, lo que facilita la modificación de la configuración sin reconstruir ni volver a implementar la aplicación.

Secret

Poner una contraseña u otras credenciales a un "ConfigMap" en formato de texto plano puede resultar inseguro, incluso considerando que es una configuración externa.

Para ello, Kubernetes dispone de otro componente llamado "secret". Se parece a ConfigMap, pero la diferencia es que lo usamos para almacenar credenciales de datos secretos y se mantiene en formato codificado base64.

Tal como hicimos con ConfigMap, simplemente debemos conectar el secreto a nuestro pod para que el pod pueda ver los datos y leerlos.

 

Volume 

Es hora de examinar más de cerca otro concepto crucial: el almacenamiento de datos. Ocasionalmente, nuestra aplicación utiliza una base de datos y, si se reinicia el contenedor de la base de datos o el Pod, los datos desaparecerán. Es problemático e inconveniente porque queremos que nuestra base de datos o datos de registro persistan de manera confiable a largo plazo. La forma de hacerlo en Kubernetes es utilizando otro componente llamado "Volumes".

Conecta el almacenamiento físico en un disco duro a su pod. El almacenamiento podría ubicarse en una máquina local (es decir, en el mismo nodo del servidor donde se ejecuta el Pod) o en un almacenamiento remoto (es decir, fuera del clúster de Kubernetes). Podría ser almacenamiento en la nube o almacenamiento local que no forma parte del clúster de Kubernetes, con una referencia externa al mismo. En este punto, cuando se reinicia el contenedor o pod de la base de datos, todos los datos persistirán allí. Es un almacenamiento remoto. Simplemente puedes considerarlo como un disco duro externo conectado al clúster de Kubernetes.

 

Deployment

¿Qué pasará si el pod de nuestra aplicación falla o falla o si tenemos que reiniciar el pod porque hemos creado una nueva imagen de contenedor? En este caso, tendremos un tiempo de inactividad cuando un usuario pueda acceder a nuestra aplicación. Es muy negativo si sucede en producción, pero precisamente por eso los sistemas distribuidos y los contenedores tienen ventaja. Entonces, en lugar de depender de un solo módulo, replicamos todo en varios servidores. Ese diseño se llama "Deployment".

Entonces, ahora tendremos otro nodo donde se podrá ejecutar una réplica o clon de nuestra aplicación. También estará conectado al servicio. ¿Recuerdas que anteriormente dijimos que el servicio es como una dirección IP estática persistente con un nombre DNS? Implica que no es necesario ajustar el punto final constantemente cuando muere un pod. Si una de las réplicas de su pod de aplicación falla, el servicio reenviará las solicitudes a otra, por lo que nuestra aplicación seguirá siendo accesible para el usuario.

 

StatefulSet

Del mismo modo, si nuestro módulo de base de datos muere, también necesitamos tener una réplica de la base de datos. Aún así, no podemos duplicar una base de datos usando "Deployment". La razón de esto es que la base de datos tiene un estado que son sus datos.

Esto implica que si tenemos clones o réplicas de la base de datos, todos necesitarán acceder al mismo almacenamiento de datos compartido. En ese escenario, necesitará un mecanismo que pueda administrar qué pods están escribiendo actualmente en ese almacenamiento y cuáles están leyendo desde allí. Es necesario evitar las inconsistencias de los datos. Este mecanismo, además de una función de replicación, lo ofrece otro componente de Kubernetes llamado "StatefulSet".

Los pods de bases de datos siempre deben desarrollarse utilizando StatefulSets para garantizar que la lectura y escritura de la base de datos estén sincronizadas.

En resumen, hemos explorado los componentes de Kubernetes más comunes

• Comenzamos con los pods y los services que necesitábamos para comunicarnos entre nosotros.
• Luego, examinamos el componente Ingress utilizado para enrutar el tráfico al clúster.
• También hemos analizado una configuración externa utilizando ConfigMaps y Secrets.
• Luego, analizamos la persistencia de datos usando volumes.
• Finalmente, hemos echado un vistazo rápido a los planos de pods con mecanismos de replicación como Deployments y StatefulSets, donde este último se emplea específicamente para aplicaciones con estado como bases de datos.

Gracias