Kubernetes & Helm Fundamentals

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 1 de 10. Durante años, Google gestionó su infraestructura global de búsqueda y correo electrónico usando un sistema muy secreto que llevaba el nombre de los villanos más temibles de Star Trek. Tuvieron que inventarlo porque la gestión de servidores que existía simplemente colapsaba a su escala. Hoy vamos a ver los orígenes, desde Borg hasta Kubernetes, y por qué las empresas modernas confían en él. Para entender por qué existe Kubernetes, tienes que fijarte en cómo evolucionó el deployment de aplicaciones. En la era del deployment tradicional, ejecutabas las aplicaciones en servidores físicos. No había forma de definir los límites de los recursos. Si una aplicación consumía casi toda la memoria, las demás aplicaciones de ese servidor físico sufrían las consecuencias. Podías comprar una máquina física distinta para cada app, pero eso acababa en hardware caro y desaprovechado. Luego llegó la era del deployment virtualizado. Ejecutabas múltiples Virtual Machines en la CPU de un único servidor físico. Las VMs aislaban las aplicaciones y daban cierto nivel de seguridad, pero cada VM seguía necesitando un sistema operativo completo y pesado. Finalmente, llegamos a la era del deployment de containers. Los containers son parecidos a las VMs, pero comparten el sistema operativo subyacente entre las aplicaciones. Como están desacoplados del hardware subyacente, son ligeros, arrancan rápido y son portables entre diferentes clouds y distribuciones de sistemas operativos. Pero los containers trajeron un nuevo problema. Si ejecutas una aplicación empresarial global, no tienes un solo container. Tienes miles. Si un container se cae, otro tiene que arrancar inmediatamente. Si hay picos de tráfico, necesitas levantar más containers y distribuir la carga de red de manera uniforme. No puedes gestionar eso a mano en cientos de máquinas. Google se enfrentó a este mismo problema mucho antes que el resto de la industria. Crearon un cluster manager interno de containers llamado Borg para automatizar la orquestación de cientos de miles de jobs. Cuando quedó claro que el resto del mundo del software necesitaba esta misma capacidad, los ingenieros de Google empezaron un proyecto open-source basado en las lecciones aprendidas con Borg. Le pusieron una referencia a Star Trek, llamándolo originalmente Proyecto Siete de Nueve, un guiño a un dron Borg que escapó del colectivo. Ese proyecto finalmente se lanzó como Kubernetes. El logo del timón que ves hoy tiene siete radios como un pequeño homenaje a ese nombre original del proyecto. Esta es la parte que importa. Kubernetes te da un framework para ejecutar sistemas distribuidos de forma resiliente. Se encarga del scaling y el failover de tu aplicación. Si un container falla, Kubernetes lo reemplaza. Si un nodo falla, reprograma los containers en nodos sanos. Gestiona el service discovery, lo que significa que un container se puede encontrar usando un nombre DNS o su propia dirección IP, y balancea la carga para que ningún container se sature. También gestiona la orquestación de storage, permitiéndote montar automáticamente storage local o proveedores cloud, y automatiza los rollouts y rollbacks. Tú describes el estado deseado de tus containers desplegados, y Kubernetes cambia el estado actual al estado deseado a un ritmo controlado. No escribes scripts para gestionar el estado del servidor; declaras lo que quieres, y el sistema hace que ocurra. La conclusión principal aquí es que Kubernetes no es solo un entorno de hosting, es un control loop que compara constantemente la realidad con tus expectativas y corrige la diferencia. Antes de terminar, si quieres ayudarnos a seguir haciendo estos episodios, busca DevStoriesEU en Patreon; agradecemos el apoyo. Eso es todo por este episodio. Gracias por escuchar, ¡y a seguir construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 2 de 10. Tienes docenas de servidores ejecutando cientos de contenedores. Cuando una máquina falla repentinamente, algo debe decidir adónde van esas cargas de trabajo huérfanas. Una orquesta sin director es solo ruido, y una flota de contenedores sin un cerebro centralizado es un caos inmanejable. Ese cerebro centralizado, junto con las máquinas que realizan el trabajo real, forman la arquitectura del clúster de Kubernetes. Un clúster de Kubernetes se divide en dos partes distintas. Tienes el Control Plane, que actúa como el cerebro, y tienes los Worker Nodes, que actúan como el músculo. El Control Plane toma todas las decisiones globales, como el scheduling de las cargas de trabajo, y detecta y responde a los eventos del clúster. Los Worker Nodes alojan tus aplicaciones y ejecutan las instrucciones enviadas por el Control Plane. Todo clúster debe tener al menos un Worker Node para ejecutar aplicaciones. Fíjate primero en el Control Plane. Su componente principal es el kube-apiserver. A veces, los oyentes escuchan API server y se imaginan un servidor web estándar gestionando requests HTTP para una aplicación. Pero esto no es así. El kube-apiserver es el sistema nervioso central de todo el clúster. Es el frontend del Control Plane. Absolutamente toda la comunicación, ya venga de un operador humano, de un Worker Node o de un componente interno, se enruta a través de este API server. Como el API server es totalmente stateless, el clúster necesita una memoria. Esa memoria es etcd. Se trata de un key-value store consistente y de alta disponibilidad que contiene todos los datos del clúster. Cada vez que se crea una configuración o cambia el estado del sistema, el registro real de ese cambio vive en etcd. El siguiente es el kube-scheduler. Cuando le pides al clúster que ejecute una nueva carga de trabajo en un contenedor, esa carga de trabajo al principio no tiene ninguna máquina asignada. El scheduler detecta esta carga de trabajo sin asignar. Evalúa los requisitos de recursos, las limitaciones de hardware y las reglas de las políticas, y luego asigna la carga de trabajo al Worker Node más adecuado. Por último, tienes el kube-controller-manager. Este componente ejecuta bucles continuos en segundo plano llamados controllers. Estos controllers observan constantemente el estado actual del clúster a través del API server y trabajan activamente para llevar ese estado actual hacia tu estado deseado. Si un Worker Node se cae, el controller manager detecta que falta la máquina y lanza la respuesta para reemplazar las cargas de trabajo perdidas. Eso cubre el cerebro. Ahora fíjate en los Worker Nodes que ejecutan las tareas. Los componentes del nodo se ejecutan en cada una de las máquinas worker para mantener el entorno de runtime. El componente más crítico aquí es el kubelet. Se trata de un agente que se ejecuta en cada nodo y se comunica directamente con el Control Plane. El kubelet recibe instrucciones del API server y se asegura de que los contenedores requeridos estén realmente ejecutándose y healthy en su máquina específica. El kubelet no arranca los contenedores por sí mismo. Delega esa tarea al Container Runtime. El runtime es el software real, como containerd, responsable de hacer pull de las imágenes de contenedor desde un registry y arrancar los procesos en el sistema operativo. Por último, está el kube-proxy. Este es un proxy de red que se ejecuta en cada nodo. Mantiene las reglas de red locales que permiten que la comunicación de red llegue a tus contenedores desde dentro o fuera del clúster. Aquí está la clave. El Control Plane dicta lo que debe suceder, pero nunca ejecuta el código de la aplicación. Los Worker Nodes ejecutan el código de la aplicación, pero dependen completamente del Control Plane para saber qué ejecutar. Esta estricta separación entre la toma de decisiones y la ejecución es lo que permite a Kubernetes escalar horizontalmente y recuperarse automáticamente de fallos de hardware. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 3 de 10. Creas un contenedor, lo pruebas localmente y se lo entregas a Kubernetes para que lo ejecute. Pero Kubernetes se niega rotundamente a gestionar tu contenedor directamente. En su lugar, exige que primero lo encapsules en una abstracción completamente diferente. Vamos a desmitificar los Pods, la unidad de trabajo real en este ecosistema. Si los contenedores son las ballenas solitarias del mundo tradicional de la contenerización, los Pods son los grupos cohesionados en los que nadan juntos. Un Pod es el objeto deployable más pequeño y básico que puedes crear y gestionar en Kubernetes. Representa una única instancia de un proceso en ejecución en tu cluster. Quizás te preguntes por qué Kubernetes introduce esta capa adicional en lugar de gestionar los contenedores directamente. La respuesta está en la abstracción y el contexto compartido. Kubernetes necesita una forma uniforme de gestionar el networking, el storage y el scheduling, independientemente del container runtime subyacente que utilices. Al encapsular contenedores en un Pod, Kubernetes trata el Pod como un host lógico. La clave está en lo siguiente: un Pod no solo encapsula un único contenedor, sino que establece un entorno de ejecución compartido. Si bien un Pod suele contener un solo contenedor, puede albergar varios que necesitan trabajar estrechamente. Cuando varios contenedores se ubican dentro del mismo Pod, se garantiza que se les haga scheduling en la misma máquina física o virtual. Más importante aún, estos contenedores comparten el mismo network namespace. Cada contenedor dentro de un Pod comparte una única dirección IP y un único port space. Dado que existen en el mismo contexto de red, pueden comunicarse entre sí simplemente usando localhost. No hacen falta DNS lookups internos ni un service routing complejo solo para que dos procesos locales hablen entre sí. Si el contenedor A hace bind al puerto 8000, el contenedor B en el mismo Pod puede acceder a él en localhost puerto 8000. Este contexto compartido se extiende al storage. Puedes definir volúmenes de storage compartidos a nivel de Pod. Una vez definidos, cualquier contenedor dentro de ese Pod puede hacer mount de esos volúmenes compartidos en su propio file system. Esto permite que contenedores tightly coupled lean y escriban los mismos archivos sin problemas. Imagina un contenedor de servidor web principal. Su función es servir tráfico HTTP, pero también escribe raw access logs en un directorio local. Quieres enviar esos logs a un sistema de monitorización central, pero no quieres inflar la imagen de tu servidor web con logging agents y archivos de configuración. En su lugar, creas un segundo contenedor, una utilidad de logging ligera. Haces deploy tanto del servidor web como del contenedor de logging dentro del mismo Pod. El servidor web escribe sus logs en un volumen de storage compartido. El contenedor de logging, actuando como un sidecar, hace mount de ese mismo volumen, lee los log files entrantes y los envía por stream a tu sistema de monitorización. Funcionan como una unidad integrada, compartiendo recursos sin mezclar sus responsabilidades individuales. Al decidir si dos contenedores pertenecen al mismo Pod, pregúntate si inherentemente necesitan acabar en la misma máquina y compartir un lifecycle idéntico. Si no necesitan absolutamente hacer deploy, arrancar y morir juntos, pertenecen a Pods separados. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 4 de 10. Estás durmiendo. A las tres de la mañana, un memory leak tumba tu servidor principal de aplicaciones. En una configuración tradicional, salta una alerta y te despiertas para reiniciar el proceso manualmente. En Kubernetes, el sistema hace el turno de noche por ti. Este es el poder de gestionar el estado con Deployments. Un Deployment proporciona actualizaciones declarativas para tus aplicaciones. En lugar de escribir scripts que le indiquen al sistema paso a paso cómo ejecutar tu software, describes exactamente cómo debería ser la imagen final. Le pasas este estado deseado al controlador del Deployment, y este cambia el estado real para que coincida a un ritmo controlado. Para entender cómo lo hace, necesitas conocer la jerarquía. Rara vez creas Pods individuales directamente. En su lugar, creas un Deployment. Luego, el Deployment crea un objeto secundario llamado ReplicaSet. El ReplicaSet es el mecanismo estrictamente responsable de garantizar que se esté ejecutando el número exacto de réplicas de Pods especificado en todo momento. Si un nodo del servidor falla, o un Pod crashea por ese memory leak, el ReplicaSet detecta que los números han caído por debajo de tu estado deseado. Inmediatamente levanta un nuevo Pod para reemplazar el perdido. Ese es tu mecanismo de self-healing. Tú nunca intervienes. La misma lógica se aplica al scaling. Si hay un pico de tráfico, actualizas tu fichero de Deployment para pedir cinco réplicas en lugar de tres. El controlador ve la discrepancia entre tu petición y la realidad, y le dice al ReplicaSet que lance dos Pods más. Este enfoque declarativo es crucial durante las actualizaciones de la aplicación. Supongamos que tienes tres Pods ejecutando una imagen de Nginx en la versión 1.14. Necesitas actualizar a la versión 1.16 sin perder nada de tráfico de usuarios. Simplemente actualizas la versión de la imagen en la configuración de tu Deployment. El Deployment no termina todos tus Pods antiguos de golpe. En su lugar, crea un ReplicaSet totalmente nuevo específicamente para la versión 1.16. Luego, empieza un rolling update. Arranca un nuevo Pod en el nuevo ReplicaSet. Una vez que ese nuevo Pod está healthy, hace un scale down del ReplicaSet antiguo terminando un Pod de la versión 1.14. Repite este proceso cuidadoso y escalonado hasta que los tres Pods antiguos han desaparecido y hay tres Pods nuevos ejecutándose. La transición es completamente fluida. Ahora bien, ¿qué pasa si la actualización falla? Aquí está la clave. Como el controlador del Deployment orquesta estos ReplicaSets, te da una red de seguridad integrada. Si accidentalmente escribes el nombre de la imagen como Nginx 1.16-typo, los nuevos Pods crashearán al arrancar. El Deployment detecta el fallo y detiene el rollout inmediatamente. Deja tus Pods antiguos restantes en ejecución para que tu aplicación siga online. Una vez que detectas el error, puedes lanzar un comando de rollback. El Deployment simplemente hace un scale up del ReplicaSet antiguo que funciona bien, y un scale down a cero del que falla. La verdadera fortaleza de un Deployment no es solo levantar contenedores, sino su bucle continuo e implacable de comparar lo que has pedido con lo que realmente existe, y forzar a la realidad a coincidir. Me gustaría tomarme un momento para agradecerte que nos escuches; nos ayuda muchísimo. ¡Que tengas un buen día!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 5 de 10. Los Pods son mortales. Fallan, hacen scale down, sufren un eviction y, cuando son reemplazados, obtienen una dirección IP completamente nueva. Si tienes una aplicación intentando comunicarse con ellos, estás disparando constantemente a un objetivo en movimiento. Los Services de Kubernetes resuelven exactamente este problema. Piensa en una aplicación web típica. Tienes un deployment de frontend y una base de datos de backend. Si tu Pod de base de datos se reinicia, el control plane del clúster levanta un nuevo Pod para reemplazarlo. A este nuevo Pod se le asigna una dirección IP completamente diferente en la red del clúster. Si tu frontend estaba configurado para comunicarse directamente con la IP antigua, la conexión se cae y tu aplicación deja de funcionar. No puedes depender de las IPs individuales de los Pods para nada permanente. Un Service de Kubernetes es una abstracción que proporciona una identidad de red estable y duradera para un grupo dinámico de Pods. Cuando creas un Service, se le asigna una dirección IP que nunca cambiará mientras el Service exista. Tu aplicación de frontend no necesita controlar exactamente qué Pods de base de datos están vivos en un segundo determinado. Simplemente envía tráfico a la IP del Service. Además, el clúster asigna un nombre DNS estable al Service. El código de tu frontend puede simplemente conectarse a un hostname sencillo, y el clúster lo resuelve automáticamente a la dirección IP correcta. En segundo plano, el Service actúa como un load balancer interno. Depende de un componente llamado kube-proxy que se ejecuta en cada nodo para implementar las reglas de routing reales. Cuando el tráfico llega al Service, se reenvía a uno de los Pods sanos que lo respaldan. Para vincular un Service a los Pods correctos, usas labels y selectors. Puedes configurar el Service con un selector que busque el label que indica una aplicación de base de datos. El Service vigila constantemente el clúster. Si un Pod de base de datos muere, su IP se elimina del pool activo. Cuando el Pod de reemplazo arranca, se añade su nueva IP. La aplicación de frontend no se entera en absoluto de que la topología de red subyacente acaba de cambiar. Hay varias formas de exponer un Service, dependiendo de dónde se origine el tráfico. El tipo por defecto es ClusterIP. Un Service de tipo ClusterIP obtiene una dirección IP interna accesible solo desde dentro del clúster. Esta es la opción correcta para tu base de datos de backend, manteniéndola aislada de forma segura del mundo exterior. Pero tu frontend necesita recibir tráfico de usuarios externos. Para esto, cambias el tipo de Service a LoadBalancer. Cuando creas un Service de tipo LoadBalancer, Kubernetes se comunica con tu proveedor de cloud para aprovisionar un load balancer externo estándar. El tráfico externo de internet llega a ese recurso en el cloud, que reenvía la conexión hacia tu clúster, pasándola a través del Service y finalmente a tus Pods de frontend. Aquí está la clave. Los Services desacoplan la identidad direccionable de tu aplicación de los workloads físicos que realmente ejecutan la lógica. Dejas de hacer routing a instancias específicas y frágiles, y empiezas a hacer routing a un concepto resiliente y persistente. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 6 de 10. Quieres hacer deploy de una sola aplicación, pero terminas gestionando cientos de líneas de YAML estático entre deployments, services e ingresses. Cuando necesitas hacer push de esa misma aplicación a un entorno de staging, copias esos archivos a un nuevo directorio y buscas y reemplazas manualmente los image tags y los hostnames. Es un proceso frágil, muy repetitivo e imposible de mantener a medida que crece tu infraestructura. Este es exactamente el problema que Helm viene a solucionar. Helm es el package manager para Kubernetes. Puedes pensar en él como apt, yum o Homebrew, pero diseñado específicamente para los recursos de Kubernetes. En lugar de tratar tu aplicación como una colección dispersa de manifests YAML independientes, Helm los agrupa en una única unidad coherente. Este formato de empaquetado se llama Chart. Un Chart es esencialmente un directorio que contiene archivos que describen un conjunto relacionado de recursos de Kubernetes. Contiene todas las definiciones que tu aplicación necesita para ejecutarse. El mecanismo principal que hace útil a un Chart es el templating. Los manifests raw de Kubernetes son completamente estáticos. Un Helm Chart, por el contrario, reemplaza los detalles de infraestructura hardcoded con template variables. En lugar de escribir un replica count específico, un image tag fijo para el contenedor, o una environment variable distinta directamente en un archivo de deployment, defines placeholders. A la hora de hacer deploy, Helm fusiona estos templates con un archivo independiente que contiene tus valores específicos. Esta arquitectura significa que solo tienes que mantener un único Chart para tu aplicación. Simplemente le pasas diferentes parámetros de configuración dependiendo de si estás haciendo deploy en local, en staging o en producción. Cuando coges un Chart, lo combinas con tus valores de configuración específicos y haces deploy en un cluster de Kubernetes, creas lo que Helm llama una Release. Aquí es donde la cosa se pone interesante. Un Chart es simplemente el blueprint genérico. Una Release es la instancia real a la que has hecho deploy y que se está ejecutando en tu cluster. Gracias a esta estricta separación entre el blueprint y la instancia, puedes instalar exactamente el mismo Chart varias veces en el mismo cluster. Si necesitas tres instancias separadas de un caching server, no duplicas el YAML. Instalas el caching chart tres veces. Helm hace seguimiento de cada instalación como una Release distinta, con su propio nombre único, sus propios valores de configuración y su propio ciclo de vida aislado. Helm también hace seguimiento del estado y el historial de estas Releases dentro del cluster. Cuando actualizas una aplicación proporcionando un nuevo image tag o modificando una configuración, Helm evalúa las diferencias y crea una nueva revision de esa Release específica. Aplica solo los cambios necesarios a los recursos subyacentes de Kubernetes. Si una actualización falla o una aplicación empieza a comportarse de forma errática, le ordenas a Helm que haga roll back a una revision anterior. Helm sabe exactamente qué recursos de Kubernetes pertenecen a qué versión de tu aplicación, gestionando la creación, modificación y eliminación de esos recursos como una sola operación. El cambio fundamental con Helm es la abstracción. Dejas de gestionar archivos de texto independientes que representan pods, services y volumes desconectados, y comienzas a hacer deploy, configurar y actualizar aplicaciones completas. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 7 de 10. Necesitas actualizar la contraseña de una base de datos, pero las credenciales están hardcoded en quince archivos YAML diferentes. Si te dejas un archivo, falla todo el deployment. Hacer hardcoding de la configuración directamente en la estructura de tu deployment es frágil. La solución es entender la anatomía de un Helm chart. Un Helm chart es un paquete estandarizado que contiene todas las definiciones de recursos necesarias para ejecutar una aplicación, herramienta o servicio dentro de un cluster de Kubernetes. Todo el sistema se basa en una filosofía fundamental: una estricta separación entre la definición estructural y la configuración específica del entorno. Defines la forma de tu deployment una sola vez, e inyectas los detalles específicos cuando llega el momento de hacer el deploy. Cuando miras dentro de un Helm chart, encuentras una estructura de directorios específica. La carpeta principal siempre lleva el nombre del propio chart. Dentro de esta carpeta, tres componentes principales impulsan el sistema de empaquetado. El primero es un archivo llamado Chart punto yaml. Este es el centro de metadatos. Le dice a Helm exactamente qué es el paquete. Contiene la versión de la API para el estándar del chart, el nombre del chart, una descripción y los números de versión. Y lo que es crucial, rastrea tanto la versión del propio chart como la app version, que es la versión del software real al que se le hace el deploy. También puedes encontrar un directorio charts justo al lado, que contiene cualquier subchart del que dependa tu aplicación, pero el archivo de metadatos es el identificador principal. El segundo componente principal es el directorio templates. Aquí es donde vive la definición estructural. Dentro, colocas tus archivos manifest estándar de Kubernetes, como deployments y services. Sin embargo, en lugar de escribir YAML estático, estos archivos contienen lógica de templates de Go. En lugar de hacer hardcoding de una cantidad de replicas de tres, o pegar una contraseña de base de datos específica, escribes una directiva de template. Esa directiva le dice a Helm que busque el valor requerido dinámicamente durante el deployment. El tercer componente responde a esas búsquedas dinámicas. Es un archivo llamado values punto yaml, situado en la raíz del directorio del chart junto al archivo de metadatos. Este archivo contiene los ajustes de configuración por defecto. Cuando un template pide un repositorio de imágenes, un número de puerto o una contraseña, el archivo values proporciona la respuesta base. Aquí está la clave. Los templates dictan la arquitectura de tu aplicación, mientras que los values dictan cómo se comporta esa arquitectura en un entorno específico. Cuando ejecutas un comando install, Helm coge los templates en crudo, los fusiona con el archivo values, y renderiza manifests de Kubernetes finales y válidos. Luego envía esos manifests renderizados a la API de Kubernetes. Esta separación es lo que hace que los charts sean altamente reutilizables. Imagina un escenario en el que tienes que hacer el deploy de exactamente la misma aplicación tanto en un entorno de staging como en un entorno de producción. No copias ni alteras el chart. Usas exactamente la misma estructura de directorios y exactamente los mismos templates. Para el deployment de staging, le pasas a Helm un archivo values personalizado durante el comando install. Este archivo sobrescribe los valores por defecto, especificando una replica de pod, una URL de base de datos de test local, y logging a nivel de debug. Cuando haces el deploy a producción, pasas un archivo values completamente diferente. Este archivo de producción especifica diez replicas, una URL de base de datos gestionada y restricciones de recursos estrictas. Helm fusiona el conjunto único de templates con los respectivos archivos values personalizados, produciendo dos perfiles de deployment completamente diferentes. El poder de un Helm chart no reside en el YAML que contiene, sino en los límites que crea. Bloquea la arquitectura de la infraestructura en los templates, mientras mantiene los detalles operativos totalmente fluidos en los values. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 8 de 10. El hecho de que puedas hacer un template de cada línea de un manifest de Kubernetes no significa que debas hacerlo. Cuando intentas que cada campo sea configurable, terminas con un chart que nadie puede leer, y mucho menos mantener. Este episodio trata sobre las buenas prácticas de los charts de Helm, las reglas que evitan que tus configuraciones colapsen por su propio peso. La mayor trampa al crear charts es el over-templating. Muchos desarrolladores tratan los templates de Helm como un simple script de reemplazo de texto. Esto es un error común. Helm ejecuta un template engine de Go para generar YAML estructurado y válido. Si metes una variable en un archivo sin gestionar cuidadosamente la indentación y los tipos de datos, el YAML generado se romperá por completo. Por ello, solo deberías hacer templates de los valores que realmente cambian entre entornos. Piensa en image tags, replicas, resource limits o ingress rules. Deja los campos estructurales principales hardcodeados. Si un usuario nunca necesita cambiar un security context o un volume mount específico, no lo expongas como una variable. El archivo values punto yaml actúa como la API pública de tu chart. Al organizar este archivo, debes equilibrar la estructura con la usabilidad. La recomendación oficial es mantener la jerarquía lo más plana posible. Aunque debes agrupar los parámetros relacionados, evita el nesting profundo. Piensa en el usuario que pasa overrides a través de la línea de comandos. Obligarle a escribir una ruta separada por puntos de cinco niveles de profundidad solo para cambiar un número de puerto genera una fricción innecesaria. Si tienes una configuración de servidor web, coloca las propiedades bajo una única key de server, pero mantén las propiedades internas planas. Al nombrar estas variables, utiliza siempre camel case. Empieza con una letra minúscula y pon en mayúscula la primera letra de cada palabra subsiguiente. No utilices guiones ni guiones bajos en tu archivo de values. Podrías crear una variable llamada externalPort, en lugar de external guion port. El uso consistente de camel case evita errores de parsing durante el renderizado de templates y se ajusta a los estándares del ecosistema de Kubernetes. Además, mantén una estricta coherencia de tipos. Si un parámetro es un integer en Kubernetes, como un número de puerto, déjalo como integer en tu archivo de values. No lo encierres entre comillas ni lo conviertas en un string. Esta coherencia se aplica directamente a cómo asignas labels a los recursos que genera tu chart. Cada objeto necesita labels estándar. Las buenas prácticas de Helm dictan usar los app labels oficiales de Kubernetes. Específicamente, usa el prefijo app punto kubernetes punto io. El label name debe corresponder al nombre del chart, mientras que el label instance debe corresponder al release name. También incluyes el label version, y señalas que el recurso es gestionado por Helm. Aplicar estos labels exactos a cada deployment, pod, service y config map garantiza que las herramientas de monitorización externas y los service meshes puedan descubrir y agrupar automáticamente los componentes de tu aplicación sin configuración manual. Aquí está la clave. El mejor chart de Helm no es el que tiene más opciones de configuración. Es el que requiere menos overrides para ejecutarse correctamente out of the box. Si quieres ayudar a que el programa continúe, busca DevStoriesEU en Patreon; agradecemos mucho tu apoyo. Gracias por dedicarme unos minutos. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 9 de 10. Crear un clúster desde cero es un gran ejercicio de aprendizaje, pero cuando escalas a cientos de microservicios, no quieres gestionar el control plane tú mismo. Quieres que el cloud provider haga el trabajo pesado para que tus ingenieros puedan centrarse en hacer deploy de código. Así es exactamente una implementación empresarial de Kubernetes y Helm en Azure. En una arquitectura estándar de Kubernetes, tienes un control plane tomando decisiones globales y worker nodes ejecutándolas. Mantener ese control plane en alta disponibilidad es muy complicado. Un cliente empresarial que hace deploy en Azure suele usar Azure Kubernetes Service, o AKS. AKS abstrae el control plane. Azure gestiona el API server, el scheduler y el key-value data store. Tu equipo de operaciones solo es responsable de los worker nodes que realmente ejecutan tus aplicaciones. Entonces, ¿cómo llega una aplicación desde la máquina de un desarrollador hasta esos worker nodes? Aquí es donde Helm entra en el workflow. Una aplicación empresarial rara vez consta de un solo container. Normalmente es una colección de microservicios, cada uno con sus propios deployments, servicios y configuraciones. En lugar de gestionar decenas de archivos YAML estáticos, los desarrolladores empaquetan estos recursos en un Helm chart. Un chart actúa como un único blueprint versionado para un microservicio. Como Helm utiliza templates, los desarrolladores pueden escribir la lógica estructural una sola vez e inyectar diferentes valores de configuración dependiendo de si hacen deploy en un clúster de desarrollo, staging o producción. Antes de que se ejecute nada, el código de la aplicación se compila en container images. Se hace push de estas imágenes a una ubicación de almacenamiento segura, como un container registry. Los propios Helm charts también se pueden empaquetar y subir a un registry, lo que permite a los equipos empresariales tratar sus definiciones de infraestructura exactamente igual que su código de aplicación compilado. Aquí está la clave. Cuando una release pipeline lanza un deployment, Helm evalúa sus templates con los valores específicos del entorno y envía los manifests finales al API server de AKS. El control plane de AKS lee este estado deseado y empieza a hacer scheduling de Pods en tus worker nodes. Los nodos se conectan al container registry, se autentican de forma segura, hacen pull de las versiones específicas de la imagen y levantan los containers. Kubernetes monitoriza constantemente este estado. Si un worker node falla, el control plane inmediatamente hace reschedule de sus Pods en nodos sanos para mantener el replica count definido en el Helm chart. Una vez que los Pods están en ejecución, necesitan recibir tráfico. Un Helm chart suele incluir una definición de servicio para exponer la aplicación. Cuando se hace deploy de esto en AKS, Kubernetes habla directamente con la infraestructura subyacente de Azure. Si el servicio solicita un punto de entrada público, AKS aprovisiona automáticamente un Azure Load Balancer. Este load balancer recibe el tráfico externo entrante y lo enruta de forma segura hacia el clúster, distribuyéndolo entre los Pods sanos. Tus desarrolladores nunca tuvieron que tocar el portal de Azure ni escribir reglas de enrutamiento cloud específicas. Simplemente definieron un servicio estándar de Kubernetes en su Helm chart, y la plataforma gestionada se encargó del aprovisionamiento de la red física. El verdadero poder de esta arquitectura empresarial es la limpia separación de responsabilidades. Helm estandariza cómo se define la aplicación en todos los entornos, el registry protege los artefactos versionados, y la plataforma cloud gestionada asegura que la infraestructura subyacente se mantenga viva para ejecutarla. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Fundamentos de Kubernetes y Helm, episodio 10 de 10. Tienes la teoría y las herramientas. Pero cuando te quedas mirando un terminal vacío, la brecha entre la enorme infraestructura cloud y tu portátil parece increíblemente grande. Cerrar esa brecha es precisamente el objetivo de empezar con Minikube. Un clúster de Kubernetes en producción consta de varias máquinas que actúan como control planes y worker nodes. Aprovisionar eso en la nube cuesta dinero, lleva tiempo y requiere una configuración de red compleja. Para un desarrollador individual o un equipo pequeño que diseña una arquitectura desde cero, necesitas un entorno local que se comporte exactamente igual que producción, pero sin el overhead. Minikube es una implementación ligera de Kubernetes que crea una máquina virtual o un contenedor directamente en tu portátil. Dentro de ese entorno aislado, hace un deploy de un clúster simple single-node. Normalmente, Kubernetes separa el control plane, que gestiona el estado del clúster, de los worker nodes, que ejecutan los contenedores de tu aplicación. Minikube los combina. Tu máquina local ejecuta un nodo que gestiona tanto la lógica de administración como los workloads reales de la aplicación. No está diseñado para soportar tráfico de producción. Su única función es que puedas probar la orquestación de contenedores de forma segura. La clave está en lo siguiente. La interfaz que usas para interactuar con Minikube es idéntica a la que usas para un clúster cloud enorme. Usas la herramienta de línea de comandos llamada kubectl. Cuando ejecutas un comando kubectl, se comunica directamente con el control plane de Minikube a través de su API. No tienes que aprender ninguna sintaxis especial para el desarrollo local. El workflow coincide perfectamente con el tutorial oficial de conceptos básicos de Kubernetes. Inicias el clúster con un simple comando start. Minikube aprovisiona el entorno y configura automáticamente kubectl para que apunte a tu nueva instancia local. A partir de ahí, usas kubectl para crear un deployment. Le dices al control plane que haga pull de una imagen de contenedor específica y la ejecute. Una vez hecho el deploy, tu aplicación se está ejecutando dentro de un pod en ese único nodo. Sin embargo, está aislada de la red de tu host. Para acceder a ella desde el navegador de tu portátil, debes exponerla creando un service. Un service enruta el tráfico desde un puerto específico de tu máquina local hacia el puerto correcto del pod que se está ejecutando dentro de Minikube. A partir de aquí, puedes practicar todas las funciones principales de Kubernetes. Puedes escalar tu aplicación diciéndole a kubectl que aumente el replica count. Minikube levantará pods adicionales junto al primero. Puedes practicar rolling updates cambiando la versión de la imagen del contenedor en tu deployment. Minikube terminará los pods antiguos de forma graceful e iniciará otros nuevos, simulando un zero-downtime deployment. Como Minikube expone una API estándar de Kubernetes, tu tooling externo se integra a la perfección. Helm funciona de inmediato. Puedes instalar bases de datos complejas, ingress controllers o message queues usando Helm charts exactamente igual que lo harías en un entorno live. Minikube incluso incluye addons integrados, como un web dashboard local, que te permite inspeccionar visualmente el estado de tu clúster, leer logs y monitorizar el uso de recursos. El verdadero poder de un clúster local reside en la paridad. Cuando escribes una configuración de deployment o un Helm chart que se ejecuta correctamente en Minikube, ya has escrito la configuración exacta que se ejecutará en la nube. Dedica tiempo a explorar la documentación oficial de Kubernetes y prueba estos comandos de forma práctica. Si tienes sugerencias sobre temas que deberíamos tratar en nuestra próxima serie, visita devstories dot eu y cuéntanos. Eso es todo por hoy. Gracias por escuchar, ve a crear algo genial.