Kubernetes Crash Course for Absolute Beginners [NEW]

Introducción al Curso de Kubernetes

Presentación del curso

• Bienvenida al curso intensivo de Kubernetes, donde se enseñará todo lo necesario para comenzar en una hora.

• Se presentará un resumen de los temas a tratar: definición de Kubernetes, su arquitectura y componentes principales.

• Se realizará una demostración práctica para obtener experiencia inicial con Kubernetes.

Recursos adicionales

• Si se desea profundizar en el conocimiento sobre Kubernetes, se recomienda un curso completo para administradores de Kubernetes que incluye preparación para el examen CKA.

¿Qué es Kubernetes?

Definición y origen

• Kubernetes es un marco de orquestación de contenedores de código abierto desarrollado originalmente por Google.

• Facilita la gestión de aplicaciones compuestas por cientos o miles de contenedores en diversos entornos (físicos, virtuales o en la nube).

Problemas que resuelve

• La creciente adopción de microservicios ha incrementado el uso de tecnologías de contenedores, creando la necesidad de herramientas como Kubernetes.

• Manejar múltiples contenedores manualmente puede ser complejo e incluso imposible sin una herramienta adecuada.

Características Clave de Orquestación

Funcionalidades ofrecidas por Kubernetes

• Alta disponibilidad: asegura que las aplicaciones estén siempre accesibles sin tiempo inactivo.

• Escalabilidad: permite aumentar o disminuir rápidamente los recursos según la carga del usuario.

• Recuperación ante desastres: proporciona mecanismos para respaldar datos y restaurar aplicaciones a su último estado operativo tras fallos.

Arquitectura Básica de Kubernetes

Estructura del clúster

• Un clúster típico consta al menos un nodo maestro y varios nodos trabajadores; cada nodo ejecuta procesos esenciales como kubelet.

Procesos en el nodo maestro

• El nodo maestro ejecuta varios procesos críticos, incluyendo:

• API Server: punto central para la comunicación entre clientes y el clúster.

• Controller Manager: supervisa el estado del clúster y gestiona reparaciones necesarias.

Componentes Clave de Kubernetes

Estado del Clúster y Snapshots de etcd

• El estado actual del clúster de Kubernetes se almacena en etcd, que contiene todos los datos de configuración y estado de cada nodo y contenedor. Los snapshots de etcd permiten recuperar el estado completo del clúster.

Red Virtual en Kubernetes

• La red virtual es un componente esencial que permite la comunicación entre nodos (nodos trabajadores y nodos maestros). Esta red convierte todos los nodos en una única máquina poderosa, sumando los recursos individuales.

Diferencias entre Nodos Maestros y Trabajadores

• Los nodos trabajadores suelen ser más grandes y tener más recursos porque ejecutan múltiples aplicaciones (cientos de contenedores), mientras que los nodos maestros manejan solo unos pocos procesos críticos.

• La pérdida de un nodo maestro impide el acceso al clúster, por lo que es crucial tener copias de seguridad. En entornos productivos, se recomienda tener al menos dos nodos maestros para garantizar la continuidad.

Configuración Básica en Kubernetes

• Se presentará un caso práctico con una aplicación web simple y una base de datos para ilustrar cómo cada componente ayuda a desplegar aplicaciones en Kubernetes.

Pods: Unidad Fundamental

• Un pod es la unidad más pequeña en Kubernetes, actuando como una abstracción sobre un contenedor. Permite crear un entorno ejecutable sobre el contenedor sin depender directamente del runtime específico.

Comunicación entre Pods

• Cada pod recibe su propia dirección IP interna, permitiendo la comunicación directa entre ellos. Sin embargo, los pods son efímeros; si uno falla, se crea uno nuevo con una nueva IP.

Servicios Estáticos en Kubernetes

• Para manejar las direcciones IP cambiantes de los pods, se utilizan servicios que proporcionan direcciones IP estáticas permanentes. Esto asegura que las aplicaciones puedan comunicarse sin necesidad de actualizar constantemente las direcciones.

Acceso Externo a Aplicaciones

• Para hacer accesible una aplicación desde el exterior, se crean servicios externos. Sin embargo, no se recomienda abrir bases de datos al público; por eso existen servicios internos para protegerlas.

Uso del Ingress para Gestión Avanzada

Introducción a Kubernetes y su Configuración

Comunicación entre Pods

• La configuración inicial incluye un servidor y varios contenedores, donde los pods se comunican mediante servicios.

• Un ejemplo es el servicio de MongoDB que se utiliza para la comunicación con la base de datos, configurado generalmente en un archivo de propiedades o como variable ambiental.

Uso de Config Maps

• Cambiar la URL del servicio requiere reconstruir la aplicación, lo cual puede ser tedioso.

• Kubernetes ofrece "Config Maps" para gestionar configuraciones externas, permitiendo ajustes sin necesidad de reconstruir imágenes.

Manejo de Credenciales con Secrets

• Los "Secrets" son similares a los Config Maps pero están diseñados para almacenar datos sensibles como contraseñas en formato codificado (base64).

• Es importante utilizar herramientas externas para cifrar estos secretos ya que Kubernetes no lo hace automáticamente.

Almacenamiento de Datos en Kubernetes

Persistencia de Datos

• Los volúmenes permiten adjuntar almacenamiento físico a los pods, asegurando que los datos persistan incluso si el pod se reinicia.

• El almacenamiento puede ser local o remoto, pero es responsabilidad del usuario gestionar la persistencia y respaldo de datos.

Gestión del Tiempo de Inactividad

• Si un pod falla o necesita reiniciarse, esto puede causar tiempo de inactividad.

• Para evitar esto, se utilizan réplicas en múltiples nodos para asegurar disponibilidad continua.

Implementación y Escalabilidad

Uso de Deployments

¿Cómo funcionan los Pods y Deployments en Kubernetes?

Abstracción de Pods y Deployments

• Los pods son una capa de abstracción sobre los contenedores, mientras que los deployments son otra capa que facilita la interacción con los pods, permitiendo especificar el número de réplicas y escalar según sea necesario.

• En la práctica, se trabaja principalmente con deployments. Si un pod replica muere, el servicio redirige las solicitudes a otro pod, manteniendo la accesibilidad de la aplicación para el usuario.

Manejo de Bases de Datos

• Las bases de datos requieren réplicas también; sin embargo, no se pueden replicar usando deployments debido a su estado (datos), lo que implica que todas las réplicas deben acceder al mismo almacenamiento compartido.

• Para manejar esto, Kubernetes ofrece un componente llamado StatefulSet, diseñado específicamente para aplicaciones con estado como bases de datos (ej. MySQL, MongoDB).

Sincronización y Desafíos

• StatefulSets aseguran que las lecturas y escrituras en la base de datos estén sincronizadas para evitar inconsistencias. Sin embargo, implementar aplicaciones de bases de datos con StatefulSets puede ser complicado.

• Es común alojar aplicaciones de bases de datos fuera del clúster Kubernetes y permitir que las aplicaciones sin estado se repliquen dentro del clúster.

Robustez del Sistema

• Con dos réplicas tanto para la aplicación como para la base de datos balanceadas por carga, el sistema es más robusto. Si un nodo falla o se reinicia, el segundo nodo mantiene la accesibilidad hasta que se recrean las réplicas.

Componentes Clave en Kubernetes

Componentes Utilizados

• Se han revisado componentes clave como pods y servicios para comunicación entre ellos; además del componente Ingress utilizado para enrutar tráfico hacia el clúster.

• También se ha discutido sobre configuraciones externas mediante ConfigMaps y Secrets así como persistencia de datos utilizando Volumes.

Creación y Configuración

• La creación y configuración en un clúster Kubernetes pasa por un nodo maestro a través del proceso llamado API Server. Los clientes interactúan enviando solicitudes en formato YAML o JSON.

• Un ejemplo muestra cómo enviar una solicitud a Kubernetes para crear un deployment con dos réplicas llamadas "my app", incluyendo variables ambientales y configuración del puerto.

Declaratividad en Configuraciones

Estructura de Archivos de Configuración en Kubernetes

Partes de un Archivo de Configuración

• Cada archivo de configuración en Kubernetes consta de tres partes: metadata, specification y status. La metadata incluye el nombre del componente que se está creando.

• La segunda parte, la especificación, contiene todos los detalles sobre la configuración deseada para el componente. Aquí se declara qué tipo de recurso se va a crear, como un deployment o un service.

• Los atributos dentro de la sección de especificación son específicos para cada tipo de componente; por ejemplo, un deployment tendrá atributos diferentes a los de un service.

• La tercera parte es el status, que es generado automáticamente por Kubernetes. Este compara el estado deseado con el estado actual del componente y realiza ajustes si es necesario.

• Esta funcionalidad permite a Kubernetes mantener su característica de auto-reparación. Si hay una discrepancia entre el estado deseado y el real (por ejemplo, menos réplicas corriendo), Kubernetes tomará medidas para corregirlo.

Almacenamiento y Formato

• El formato utilizado para los archivos de configuración es YAML, que requiere una indentación precisa; cualquier error en la indentación hará que el archivo sea inválido.

• Es común almacenar estos archivos junto al código fuente del proyecto como parte del concepto "infraestructura como código", o en un repositorio Git dedicado solo para configuraciones.

Introducción a Minikube y kubectl

¿Qué es Minikube?

• Minikube es una herramienta open source diseñada para facilitar pruebas locales en entornos Kubernetes. Permite crear un clúster local con un solo nodo donde tanto los procesos maestros como los trabajadores corren juntos.

• Esto resulta útil cuando no se dispone de recursos suficientes (como memoria o CPU) para configurar un clúster completo en producción.

Interacción con Minikube

• Para interactuar con este clúster local creado por Minikube, se utiliza kubectl, una herramienta CLI que permite gestionar componentes dentro del clúster.

• El proceso maestro principal llamado API server actúa como punto central para todas las interacciones dentro del clúster. Cualquier acción debe ser comunicada a través del API server utilizando herramientas como kubectl.

Instalación y Configuración de Minikube

Introducción a Minikube y kubectl

• Minikube es una herramienta que permite crear un clúster de Kubernetes localmente, mientras que kubectl es la herramienta utilizada para interactuar con cualquier tipo de configuración de clúster de Kubernetes.

Proceso de Instalación

• La instalación de Minikube varía según el sistema operativo. Se recomienda consultar la documentación oficial para obtener instrucciones específicas.

• Para instalar Minikube en macOS, se puede utilizar Homebrew con el comando brew install minikube, lo que facilita la instalación.

Creación del Clúster

• Una vez instalado, se inicia el clúster ejecutando el comando minikube start. Es necesario tener un controlador (driver), como Docker o una máquina virtual, para ejecutar Minikube.

• Docker es el controlador preferido para todos los sistemas operativos. Al instalar Minikube, Docker ya viene incluido.

Configuración del Entorno

• Es importante entender que al usar Docker como driver, estamos ejecutando Minikube dentro de un contenedor Docker en nuestra máquina local.

• Si no tienes Docker instalado, puedes descargarlo desde Docker Hub e instalarlo fácilmente en tu sistema operativo.

Verificación del Clúster

• Después de iniciar el daemon de Docker, se puede volver a la terminal y ejecutar minikube start especificando Docker como driver. Este proceso puede tardar un poco al ser la primera ejecución.

• El comando minikube status permite verificar que todos los componentes del clúster están funcionando correctamente.

Interacción con kubectl

• Al instalar Minikube, también se instala automáticamente kubectl, por lo que no es necesario realizar una instalación adicional.

• Con el comando kubectl get nodes, se pueden visualizar los nodos en el clúster; normalmente habrá un nodo control plane y uno worker.

Despliegue de Aplicaciones en Kubernetes

Preparativos para Desplegar Aplicaciones

• A partir de este punto, las interacciones con el clúster se realizarán principalmente a través del comando kubectl.

Recursos Necesarios

• Se planea desplegar una base de datos MongoDB junto con una aplicación web que se conectará a esta base de datos utilizando configuraciones externas desde config maps y secretos.

Creación de Archivos de Configuración

• Se crearán cuatro archivos necesarios para la configuración:

• Un config map para el endpoint de MongoDB.

• Un secreto con las credenciales (usuario y contraseña).

Despliegue de una Aplicación Demo en Kubernetes

Creación del ConfigMap

• Se inicia la creación de un archivo llamado config.yml para definir un ConfigMap en Kubernetes, utilizando la documentación oficial como referencia.

• El ConfigMap se denomina "config" y contiene metadatos junto con pares clave-valor que representan configuraciones externas; en este caso, solo se define una clave llamada "url".

• El valor para la clave "url" será el servicio que se creará para la aplicación MongoDB, denominado simplemente "service".

Creación del Secret

• Se procede a crear un archivo secret.yaml que contendrá el nombre de usuario y contraseña para la aplicación MongoDB, cambiando el tipo a "opaque" para definir datos secretos.

• Los valores del secret deben ser codificados en base64; se utiliza el comando echo seguido de base64 para realizar esta codificación.

Configuración del Deployment y Servicio

• Se crea otro archivo YAML donde se definirá tanto el deployment como el servicio para MongoDB. Es común agrupar ambos en un solo archivo ya que todos los deployments requieren servicios.

• La configuración del deployment es más compleja que la de un ConfigMap o Secret; incluye una sección de metadatos y especificaciones específicas del deployment.

Plantilla del Pod

• La parte principal del deployment es la plantilla (template), que configura cómo debe ser creado el pod. Esta plantilla también tiene su propia sección de metadatos y especificaciones.

• En la especificación del pod, se definen los contenedores; generalmente hay un contenedor principal por pod. Aquí se establece qué imagen utilizará el contenedor, en este caso, una imagen de MongoDB.

Etiquetas y Selección

• Las etiquetas son pares clave-valor asignados a componentes como pods o deployments. Permiten identificar componentes específicos además de sus nombres.

• Las etiquetas son obligatorias para los pods pero opcionales para otros componentes. Sin embargo, es buena práctica establecerlas siempre.

• La selección mediante etiquetas permite a Kubernetes identificar qué pods pertenecen a qué deployments usando atributos como selector match labels. Esto asegura que las réplicas correctas sean gestionadas adecuadamente.

Configuración de MongoDB en Kubernetes

Creación del Despliegue y Réplicas

• Se establece la configuración inicial para el despliegue de MongoDB, definiendo el número de réplicas. En este caso, se opta por una sola réplica debido a que es una base de datos.

• Se menciona que para escalar bases de datos en Kubernetes, se debe utilizar un StatefulSet en lugar de un Deployment, aunque aquí se mantendrá la simplicidad con una única réplica.

Configuración del Servicio

• Se introduce la necesidad de agregar una configuración de servicio, separando las secciones YAML con tres guiones como parte de la sintaxis básica.

• La configuración del servicio es más sencilla que la del despliegue; se comienza cambiando el nombre a "service" y estableciendo atributos específicos como el selector.

Selección y Puertos

• El atributo selector permite al servicio identificar qué pods le pertenecen y hacia cuáles debe redirigir las solicitudes. Este selector debe coincidir con las etiquetas definidas en los pods.

• Se define cómo acceder al servicio dentro del clúster mediante su dirección IP y puerto. Es importante que el puerto objetivo coincida con el puerto del contenedor donde está accesible la aplicación.

Configuración para Aplicaciones Web

• Se copia toda la configuración anterior para crear un despliegue y servicio para una aplicación web llamada "webapp.yaml", ajustando valores según sea necesario.

• Para esta aplicación Node.js, se establece que inicia en el puerto 3000, lo cual requiere definir tanto el puerto del contenedor como el puerto objetivo en el servicio.

Variables de Entorno y Seguridad

• Al iniciar MongoDB, es crucial establecer variables como nombre de usuario y contraseña. Esto asegura que cuando arranque, genere automáticamente estas credenciales necesarias.

• Las variables ambientales pueden configurarse fácilmente utilizando un atributo específico dentro del contenedor. Aquí se hace referencia a secretos para obtener valores sensibles como usuario y contraseña.

Finalización de Configuración

Configuración de Variables de Entorno en Kubernetes

Creación de Variables de Entorno

• Se están configurando variables de entorno específicas para la aplicación web, comenzando con el nombre username.

• La segunda variable es user_pwd para la contraseña y la tercera es db_url, que representa el endpoint de la base de datos.

Uso de ConfigMap y Secret

• Los valores se obtienen desde un ConfigMap, utilizando una referencia similar a la del Secret, pero con config_map_key_ref.

• Esto permite mantener los archivos de configuración limpios al no tener valores codificados directamente en ellos.

Accesibilidad desde el Navegador

• Se necesita hacer accesible la aplicación web desde un navegador ajustando la configuración del servicio.

• El tipo por defecto es ClusterIP, pero se cambiará a NodePort para permitir acceso externo.

Configuración del NodePort

• El NodePort abrirá un puerto en los nodos Kubernetes donde será accesible la aplicación.

• El rango permitido para el NodePort está entre 30000 y 32767; cualquier valor dentro de este rango es válido.

Despliegue en Kubernetes

• Se crearán todos los componentes uno por uno en Kubernetes, comenzando por las configuraciones externas.

• Utilizando el comando kubectl apply -f, se crean primero el ConfigMap y el Secret necesarios antes del despliegue de MongoDB y la aplicación web.

Verificación de Componentes

• Después del despliegue, se utiliza kubectl get all para verificar todos los componentes creados en el clúster.

• Se observa que tanto MongoDB como la aplicación web tienen sus servicios correspondientes, siendo este último un servicio tipo NodePort.

Comandos Útiles en kubectl

• Para obtener más información sobre componentes específicos, se pueden usar comandos como kubectl get configmap o kubectl get secret.

• La documentación natural para kubectl puede ser consultada usando kubectl help, que lista todos los subcomandos disponibles.

Detalles Adicionales sobre Componentes

• Para ver detalles específicos sobre un componente, se usa el comando kubectl describe <tipo> <nombre>.

¿Cómo acceder a los registros y servicios en Kubernetes?

Acceso a los registros de la aplicación

• Para solucionar problemas o verificar el estado de las aplicaciones en un clúster, se pueden consultar los registros utilizando el comando kubectl logs, especificando el nombre del pod.

• Es posible transmitir los registros en tiempo real añadiendo la opción -f al comando anterior.

Validación del acceso a la aplicación desde el navegador

• Se configuró un servicio para acceder a la aplicación, y se puede obtener información sobre este usando el comando kubectl get svc.

• El servicio NodePort es accesible mediante la dirección IP del nodo del clúster. En este caso, se utiliza Minikube como nodo único.

Obtención de la dirección IP de Minikube

• Para encontrar la dirección IP de Minikube, se puede usar el comando minikube ip o kubectl get nodes, que proporciona detalles sobre el nodo.

• Utilizando opciones adicionales con comandos como get, se puede obtener más información relevante sobre servicios y pods.

Acceso a la aplicación web

• Una vez obtenida la dirección IP, se accede a la aplicación web en el puerto 3000. Se valida que está conectada correctamente a MongoDB realizando cambios y guardándolos.

Conclusiones sobre Kubernetes

• Se ha desplegado una aplicación con su base de datos en Kubernetes, lo cual representa una configuración común para muchas aplicaciones.

• Se ofrecen recursos adicionales para profundizar en Kubernetes: un curso completo para administradores de Kubernetes y un programa educativo integral en DevOps.