Hoy hablaremos de algo que casi todos han escuchado, pero nadie puede explicar Kubernetes. Es confuso porque resuelve un problema que la mayoría no ve hasta que se topa con él. Todos saben que es importante, pero si preguntas qué hace, te mirarán con extrañeza. No es un reemplazo de Docker ni un sistema operativo en la nube, aunque la gente suele suponerlo. La confusión es lógica, pues Kubernetes resuelve un problema que desconoces hasta que lo enfrentas. Es una herramienta esencial cuando tienes más de un puñado de contenedores que administrar. Al final de este episodio entenderás qué es Kubernetes, cómo encaja con los contenedores y por qué Azure Kubernetes Service lo hace práctico para equipos que no quieren construir todo desde cero. Toma tu café y comencemos. El problema antes de los contenedores. Volvamos al problema. Imagina una empresa de software hace 10 años. Tienes algunas aplicaciones que ejecutar, así que compras servidores, instales sistemas operativos y despliegas todo manualmente.

Cada aplicación recibe su propia máquina y no puedes compartir recursos entre ellas. Si una app necesita mucha memoria y otra apenas usa algo, ambas reciben su propio servidor de todos modos. Desperdicio era enorme. Los servidores operaban quizás el 20% de su capacidad, pero no podías consolidarlos porque las aplicaciones pelearían por las dependencias. Terminabas con una sala llena de servidores, cada uno apenas trabajando, consumiendo energía y refrigeración y todos necesitando mantenimiento constante. Una app necesita Python 3.7, otra necesita Python 3.8. Una requiere una librería antigua, la otra más reciente. No puedes ejecutarlas en la misma máquina sin romper algo, así que compras más servidores y pagas por hardware que permanece inactivo. Las máquinas virtuales ayudaron un poco al permitir dividir un servidor físico en partes más pequeñas, cada una con su SEO, pero cada MV es pesada, usa espacio en disco y memoria y tarda minutos en iniciar.

Tenías que configurar cada una por separado, lo cual era mucho trabajo. Seguías administrando todos sus sistemas operativos, parchando, actualizando y asegurándolos. Los equipos necesitaban algo más ligero y portátil, una forma de empaquetar una aplicación con todo lo necesario para ejecutarse sin la sobrecarga de una máquina virtual completa y que pudiera moverse fácilmente entre máquinas. A eso sugieren los contenedores. ¿Qué son realmente los contenedores? Un contenedor es un paquete pequeño que incluye tu aplicación y todo lo que necesita para ejecutarse. Eso significa que el código, el tiempo de ejecución, las librerías y los archivos de configuración están agrupados en una sola medida. Piénsalo como un contenedor de carga para el software. Un contenedor de carga puede ir en un camión, un tren o un barco, y el contenedor en sí sigue siendo el mismo. ¿Su contenedor de software funciona de manera?

Lo construye una vez, funciona igual en su computadora portátil, su servidor de prueba y su entorno de producción. La diferencia clave entre los contenedores y las máquinas virtuales es su eficiencia. Una máquina virtual ejecuta su propio sistema operativo completo, por lo que cada VM tiene su propio núcleo, archivos de sistema y todo lo demás. Un contenedor comparte el sistema operativo del hub. Es solo un proceso con su propia visión aislada del mundo. Eso significa que los contenedores se inician en segundos, no en minutos. Usa menos memoria y puede incluir más de ellos en una sola máquina. Docker popularizó los contenedores al darles a los desarrolladores una forma sencilla de crearlos y ejecutarlos con un solo comando. De repente el problema de en mi máquina funciona comenzó a desaparecer. Si su aplicación se ejecuta en un contenedor en su computadora, se ejecutará de la misma manera en el servidor.

El entorno es consistente en todas partes. Pero los contenedores resuelven un problema y crean otro. Con un puñado de contenedores, la gestión manual funciona bien. Puede iniciarlos, detenerlos y hacer un seguimiento de ellos también. Pero ¿qué sucede cuando tiene cientos de ellos? Necesita decidir qué servidor ejecuta cada contenedor, reiniciar los fallidos, conectarlos entre sí y escalarlos cuando el tráfico aumenta. Ese es un nuevo desafío y es exactamente donde entra el juego Kubernetes. Pero es mejor que esta sea. Entonces ya tiene contenedores funcionando en paquetas o aplicación, se ejecuta de forma consistente en todas partes y todo va bien. Lo absorbe un tiempo. Con 10 o 20 contenedores puede gestionar las cosas manualmente. Sabe qué servidor ejecuta qué contenedor, puede reiniciar algo si falla y puede actualizar algunas cosas aquí y allá. Manejable. Pero su aplicación crece. Se pasa a los microservicios.

Entonces en lugar de una gran aplicación, tiene 20 más pequeñas. Cada una necesita varias copias ejecutándose para la confiabilidad. Y ahora tiene 200 contenedores. La gestión manual ya no funciona. Necesita decidir qué servidor ejecuta cada contenedor, reiniciar los contenedores cuando fallan y conectarlos para que puedan comunicarse. También necesita escalar cuando el tráfico aumenta. Tal vez durante una venta o un lanzamiento de producto y reducir la escala cuando las cosas se calman. Y necesita implementar actualizaciones sin tiempo de inactividad. Lo que significa reemplazar los contenedores viejos por nuevos uno a la vez cuidadosamente, sin romper nada. Estos son problemas de orquestación. Y son exactamente lo que Kubernetes fue creado para resolver. Kubernetes es una plataforma de código abierto que automatiza el despliegue, el escalado y la gestión de aplicaciones en contenedores.

Piense en ello como el sistema operativo para su centro de datos. Al igual que Windows o Linux gestionan los recursos de una sola computadora, como la CPU, la memoria y el disco, Kubernetes gestiona los recursos de todos sus servidores. Trata a todas sus máquinas como un gran conjunto de potencia informática. Se le indica lo que desea ejecutar y el sistema determina dónde colocarlo, cómo mantener un funcionamiento y cómo conectarlo con el resto. Conceptos fundamentales. Pots, nodos y clúster. Veamos cómo funciona Kubernetes en la práctica. La unidad más pequeña en Kubernetes se llama POT. Un POT envuelve uno o más contenedores. Los contenedores dentro del mismo POT comparten almacenamiento y red, por lo que pueden comunicarse entre sí a través del localhost. Puede considerar un POT como una unidad única de despliegue. En Kubernetes no se despliegan contenedores directamente. Se despliegan POTs.

Los POTs no se ejecutan por sí solos, se ejecutan en Node. Un nodo es un servidor, físico o virtual, que forma parte de su clúster de Kubernetes. Cada nodo ejecuta el software necesario para los POTs, además de otras cosas que veremos en un momento. Un clúster es la colección de todos los nodos gestionados como un sistema unificado. En términos simples, un POT es su aplicación, un nodo es donde se ejecuta y el clúster es el entorno completo. Los POTs son efímeros. Pueden ser creados, destruidos o movidos en cualquier mundo. De sus partes dicen, si un nodo falla, Kubernetes mueve los POTs a otro diferente. Para escalar, crea nuevos POTs. Y cuando un POT falla, es reemplazado automáticamente. El sistema trata a los POTs como elementos temporales. Pero si los POTs aparecen y desaparecen, necesita una forma de congreso. En lugar de hablar con un POT directamente, se comunica con un servicio.

Un servicio proporciona una dirección de red estable que dirige el tráfico a los POTs correctos, incluso si estos cambian. Imagina un hotel. El número de teléfono del hotel es el servicio. Las habitaciones cambian de huéspedes constantemente, pero el número de teléfono sigue siendo el mismo. Usted llama a la recepción y ellos dirigen su llamada a la habitación correcta. Eso es exactamente lo que hace un servicio en Kubernetes. Le da una dirección fija que siempre apunta a los POTs que ejecutan actualmente su aplicación. El plano de control, el cerebro del clúster. Entonces, tiene POTs, nodos y un clúster. La pregunta es quién decide qué se ejecuta y dónde. Ese es el trabajo del plano de control. Cada clúster de Kubernetes tiene uno y es el cerebro de toda la operación. Aquí es donde se toman todas las decisiones. El plano de control se llama es Kubernetes. Primero es el servidor de API, que actúa como la puerta de entrada a tu clúster.

Cada comando que envías a Kubernetes, ya sea desde la línea de comandos, un panel o un script automatizado, pasa por el servidor de API. Autentica tu solicitud. Verifica si tienes permiso para hacer lo que pides y luego al lugar correcto. Nada ocurre en Kubernetes sin antes pasar por el servidor de API. El siguiente es el programador que decide qué nodo ejecuta cada POT. Cuando dice, quiero esta aplicación en ejecución, el programador busca en todos los nodos disponibles, verifica los recursos como CPU, memoria y espacio en disco y elige el mejor para el trabajo. Es como un gerente de hotel asignando habitaciones según lo que cada huésped necesita. Un huésped con mucho equipaje obtiene una habitación más grande, mientras que una aplicación ligera obtiene un nodo más pequeño con capacidad sobrante. Luego está el gestor de controladores. Este componente vigila el clúster y se asegura de que el estado real coincida con lo que declaraste.

Dijiste que quieres tres copias de tu aplicación web ejecutándose. El gestor de controladores verifica que realmente haya tres copias en ejecución. Si una falla, lo nota e inicia un reemplazo. Si alguien elimina accidentalmente un POT, crea uno nuevo. Es el componente que mantiene tu clúster honesto. Y finalmente, está etcd, que es la base de datos del clúster. Almacena todo como que se está ejecutando, donde se ejecute y como está configurado. Es la fuente de verdad para todo el clúster. Si el servidor de API es la puerta de entrada, entonces etcd es el archivador en la oficina trasera donde se guardan todos los registros. La belleza de este diseño es que describe lo que quieres y Kubernetes descubre cómo hacerlo realidad. No le dices cómo hacer las cosas, le dices cómo debería haberse el resultado final. Ese es el modelo declarativo y es la idea central detrás de todo lo que hace Kubernetes.

Cargas de trabajo, despliegue, servicios y escalado. Entonces, hablemos de cómo ejecuta realmente las aplicaciones en Kubernetes. No crearás POTS directamente. En su lugar, utilizarás un objeto de nivel superior llamado despliegue. Piensa en un despliegue como un gerente que le dice a Kubernetes cuántas copias de tu POT deben ejecutarse, qué imagen de contenedor usar y cómo actualizarlas cuando sale una nueva versión. Es la forma estándar de ejecutar aplicaciones sin esta. Cuando actualizas un despliegue, digamos que envías una nueva versión de tu aplicación, Kubernetes realiza una actualización progresiva. Reemplaza los POTS uno por uno asegurándose de que siempre haya al menos una copia en ejecución. Eso significa que no hay tiempo de inactividad ni interrupciones repentinas para sus usos. Y si algo sale mal con la nueva versión, puede volver a la anterior con un solo comando. Esa es una red de seguridad.

Pero sus POTS aún deben ser accesibles. Ahí es donde entran los servicios. Un servicio proporciona una dirección de red estable que enruta el tráfico a los POTS correctos. También puede exponer esos POTS a otras partes de su aplicación o al mundo exterior. Un servicio puede ser interno, accesible solo dentro del clúster o externo, con una IP pública que los usuarios pueden alcanzar desde Internet. Ahora, esto es lo importante sobre el escalado. Kubernetes puede aumentar o reducir automáticamente su aplicación según la demanda. Usted establece un objetivo, digamos 70% de uso de CPU, y Kubernetes añade POTS cuando el uso supera su umbral y los elimina cuando baja. Su aplicación escala durante un pico de tráfico y se reduce cuando las cosas se calman. No se requiere intervención manual, pero todo este poder conlleva complejidad. Ejecutar su propio clúster de Kubernetes significa que es responsable de plano de control, actualizaciones, parches de seguridad y copias de seguridad.

Necesita conocimientos profundos para manejar fallos de nodos, configuración de red y escalado del clúster. Muchos equipos pasan más tiempo gestionando el clúster que creando aplicaciones. Y ahí es donde entra Kubernetes Administra. Kubernetes autogestionó frente a Administra. ¿Hablemos de la realidad de ejecutar Kubernetes usted mismo? Cuando configura su propio clúster es responsable de todo el plano de control, actualizaciones, parches de seguridad y copias de seguridad de ETCD. Si el servidor de API se cae es su problema. Si se descubre una vulnerabilidad de seguridad en la versión que usa, debe parchearla. Si ETCD se corrompe, debe restaurarlo desde una copia de seguridad. Todo esto requiere conocimientos profundos. Debe entender cómo fallan los nodos, cómo funciona la red a nivel de clúster y cómo escalar sin romper nada. Esto es lo que sorprende a muchos equipos. Muchas organizaciones pasan más tiempo gestionando su clúster de Kubernetes que creando las aplicaciones que se ejecutan en él.

Están constantemente luchando con actualizaciones, resolviendo problemas de red y lidiando con fallos de nodos. El clúster se convierte en un trabajo de tiempo. Esa no es la razón por la que adopto Kubernetes en primer lugar. Aquí es donde entran los servicios de Kubernetes Administra. Servicios como Azure Kubernetes Service o AKS se encargan del plano de control por usted. Azure gestiona el servidor de API, ETCD, el programador y el administrador de controladores. No tiene que preocuparse por parchearlos o mantenerlos en funcionamiento. Solo pagas por los nodos de trabajo, las máquinas virtuales que realmente ejecutan tus cargas de trabajo. El plano de control es si es gratuito. Esto cambia la ecuación drásticamente. En lugar de dedicar tiempo al mantenimiento del clúster, tu equipo puede enfocarse en lo que realmente importa, las aplicaciones que están creando. Para la mayoría de los equipos, especialmente los que están empezando, Kubernetes Administrado es la opción correcta.

Obtienes todo el poder de Kubernetes sin la carga operativa. AKS Kubernetes Simplificado en Azure. Entonces, ¿qué es exactamente AKS? Es el servicio administrado de Kubernetes de Azure que te ofrece un clúster completo sin tener que construirlo desde cero. El plano de control es gratuito, como mencionamos, así que solo pagas por las máquinas virtuales que ejecutan tus cargas de trabajo. Esto significa que puedes empezar poco a poco, pagar muy poco y escalar a medida que tus necesidades creen. Azure se encarga de todo el trabajo pesado. Las actualizaciones, los parches y el monitoreo de salud del plano de control están todos cubiertos. No necesitas un equipo dedicado de expertos en Kubernetes solo para mantener todo funcionando. Y como AKS es parte del ecosistema de Azure, se integra con herramientas que probablemente ya estás usando. Azure Active Directory para autenticación, Azure Monitor para registros y métricas y Azure Policy para gobernanza.

Todo funciona juntos desde el primer momento, sin necesidad de añadir pieza por separado. Configurar tuberías de CICDI con GitHub Actions o Azure DevOps toma solo unos minutos. Envías un cambio a tu repositorio y automáticamente construye una nueva imagen de contenedor. La envía a Azure Container Registry y actualiza tu despliegue en AKS. Sin pasos manuales y necesidad de usar SSH en los servidores. Todo está automatizado. Para principiantes, existe el modo automático de AKS diseñado para equipos que no quieren tomar cada decisión sobre la configuración del clúster. Proporciona valores predeterminados listos para usar en escalado, redes, seguridad y actualizaciones. No tienes que convertirte en un experto en Kubernetes para empezar. Solo describe tu aplicación y AKS se encarga del resto. Un comando te da un clúster, un archivo de manifiesto pone tu aplicación en marcha. Las habilidades que aprendes en AKS se transfieren a cualquier entorno de Kubernetes porque, en esencia, es Kubernetes estándar.

No estás aprendiendo un sistema propietario, estás aprendiendo el estándar real mientras Azure maneja la complejidad operativa. Entonces, ahora tienes una visión general. Los contenedores empaquetan tus aplicaciones para que se ejecuten de forma consistente. En todas partes, si Kubernetes orquesta sus contenedores a gran escala, manejando el despliegue, el escalado y la recuperación automáticamente. AKS hace que esa orquestación sea manejable al encargarse del pleno de control y al integrarse con las herramientas de Azure que ya conoces. Punto principal es este. Kubernetes no es solo para grandes compañías tecnológicas con equipos de ingeniería masivos. Con servicios administrados como AKS es accesible para cualquier equipo. Tu tarea para esta semana es sencilla. Crea una cuenta gratuita de Azure, inicia un clúster de AKS y despliega una aplicación simple. Toma solo unos minutos y verás lo mucho que ha avanzado la plataforma.

Ni se va a profundizar más. El próximo episodio trata sobre cómo crear tu primera imagen de contenedor y enviarla a Azure Container Registry. Suscríbete en tu plataforma de podcast favorita y comparte esto con alguien que apenas comienza su camino en Kubernetes. ¡Suscríbete al canal!