Kubernetes y microservicios con autoescalado

Contenido del curso

No sé dónde empezar

Introducción al curso

Cómo entender la nube

Introducción a Cloud Computing / Nube

Conceptos de Cloud Computing / Nube

Multi-Nube

Modelos de servicio en Cloud Computing / Nube

20
IaaS, PaaS y SaaS explicados con pizza
06:29 min

Características de una arquitectura en Cloud Computing /Nube

Construyendo nuestra arquitectura

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0014:45

Kubernetes y microservicios con autoescalado

Curso de Introducción a la Nube

Clase 25 de 27

Clase 25 / 27

Recursos

Diseñar una arquitectura cloud basada en contenedores cambia las reglas del juego cuando tu aplicación necesita escalar a miles de usuarios. Aquí verás cómo evoluciona la arquitectura de Platzi Wallet hacia un orquestador de contenedores con Kubernetes, y qué retos aparecen cuando entran en juego los microservicios.

Cómo se estructura una arquitectura cloud basada en contenedores

La base sigue siendo la misma: usuarios, una capa de DNS con el dominio (en este caso platziwallet.com), una capa de CDN combinada con un WAF para seguridad, una API Gateway con autenticación y autorización, y un balanceador de aplicaciones [02:00]. Lo que cambia es lo que pasa después del balanceador.

El backend ya no corre en servidores tradicionales ni en serverless puro. Ahora vive dentro de un orquestador de contenedores, y aquí es donde entra Kubernetes, una de las aplicaciones estrella de la Cloud Native Computing Foundation [03:14]. Kubernetes se encarga de coordinar todos los contenedores que ejecutan los microservicios.

¿Qué es Kubernetes en una arquitectura cloud? Es un orquestador de contenedores open source que automatiza el despliegue, escalado y gestión de aplicaciones contenerizadas dentro de un clúster.

Qué microservicios viven dentro del clúster

Dentro de cada servidor del clúster corren contenedores pequeños, cada uno con un microservicio específico. En Platzi Wallet se identifican cinco [04:30]:

Pagos, para procesar transacciones de salida hacia comercios.
Cobros, para gestionar solicitudes de pago.
Saldo, para consultar el dinero disponible.
Cash in, equivalente a consignación o ingreso de dinero.
Cash out, equivalente a retiro de dinero.

Cada microservicio se replica en al menos dos zonas de disponibilidad porque la alta disponibilidad no es negociable en este tipo de arquitectura.

Por qué la escalabilidad en contenedores tiene dos dimensiones

Cuando tu servicio de contenedores está basado en servidores y no es serverless, debes pensar el autoescalado en dos niveles distintos al mismo tiempo. Y aquí viene lo interesante.

El primer nivel es la escalabilidad del servidor: si pasas de un usuario a 100 000 usuarios, el clúster debe crear nuevos servidores para soportar la carga [06:20]. El segundo nivel es la escalabilidad por microservicio, que funciona con una lógica completamente distinta.

Cómo funciona la concurrencia distinta entre microservicios

Piensa en este ejemplo concreto: un usuario hace cash in una sola vez por $100, pero con ese dinero realiza 25 pagos a Netflix, Amazon, Xbox y Uber [07:10]. La conclusión es directa: el microservicio de pagos tiene 25 veces más concurrencia que el de cash in en ese flujo.

Eso significa que no puedes escalar todos los microservicios por igual. Cada uno necesita reglas propias según su patrón de uso real.

¿Qué es una estrategia de placement en Kubernetes? Es la regla que define en qué servidor del clúster nace un nuevo contenedor cuando el sistema autoescala, por ejemplo en el servidor con menos RAM disponible o en otra zona de disponibilidad.

Cómo decides dónde nace un nuevo contenedor al escalar

Los cloud providers ofrecen estrategias de placement para determinar dónde se crea cada réplica nueva. Una opción común es lanzar el próximo contenedor en el servidor con menos RAM disponible, para aprovechar al máximo los recursos del clúster [08:40].

Pero esa regla tiene un costo. Si el microservicio de cobros sigue creciendo y siempre nace en el servidor más cargado de la misma zona, terminas con tres réplicas de cobros en una zona de disponibilidad y solo una en la otra. La alta disponibilidad se rompe.

La solución es combinar reglas: una basada en consumo de memoria y otra que fuerce el balanceo entre zonas. Así mantienes el aprovechamiento de recursos sin sacrificar disponibilidad.

Qué cambia con un servicio de contenedores serverless

Existe una alternativa donde el cloud provider se encarga de los servidores por ti. Tú solo te preocupas por el microservicio: cómo escala, cómo se despliega, qué hace [10:30]. No tienes que instalar agentes, ni dimensionar máquinas, ni pelear con el sistema operativo.

Esta opción serverless para contenedores libera el foco hacia lo que realmente aporta valor: el código del microservicio. Si quieres profundizar después en las diferencias técnicas de declaración de servicios, vale la pena, pero el enfoque conceptual es ese.

Qué piezas adicionales debes configurar siempre

Independientemente de si eliges contenedores con servidor o serverless, hay componentes que no puedes saltarte:

Estrategia de CI/CD para automatizar el despliegue de cada microservicio.
Repositorio de código con versionamiento de imágenes.
Pruebas automatizadas sobre la imagen del contenedor antes de promoverla.
Capa de base de datos y capas de almacenamiento conectadas al clúster.
Decisión sobre el storage: si usas el del servidor o uno externo y persistente.

¿Qué es CI/CD en arquitecturas con contenedores? Es la práctica de integración y entrega continua que automatiza la construcción, prueba y despliegue de imágenes de contenedor desde el repositorio hasta el clúster de producción.

Ahora te toca a ti pensar tu propia arquitectura: qué orquestador vas a usar, qué microservicios vas a definir, cómo los vas a distribuir entre zonas y cómo vas a montar tu pipeline de CI/CD. Cuéntame en los comentarios qué microservicios identificaste para tu aplicación y qué estrategia de placement te hace más sentido.

Mario Alexander Vargas Celis

Hace 2 años

🏗️ Arquitectura Base con Contenedores 🚢

📌 ¿Qué es una Arquitectura con Contenedores?

Es un diseño donde las aplicaciones se ejecutan en contenedores ligeros (como Docker), en lugar de servidores físicos o máquinas virtuales tradicionales.

✅ Beneficios: ✔ Portabilidad: Se puede ejecutar en cualquier entorno (nube, on-premise, híbrido). ✔ Escalabilidad rápida: Se pueden agregar o quitar contenedores según la demanda. ✔ Eficiencia de recursos: Usa menos memoria y CPU que una VM. ✔ Facilidad de despliegue: Automatización con CI/CD.

🔧 Componentes Clave de una Arquitectura con Contenedores

1️⃣ Capa de Contenedores

Contienen la aplicación y sus dependencias.
Tecnologías: Docker, Podman, LXC.
Se ejecutan sobre un host con Linux o Windows.

2️⃣ Orquestador de Contenedores

Gestiona el escalado, despliegue y networking de los contenedores.
Ejemplo: Kubernetes (K8s), Docker Swarm, Amazon ECS, Azure AKS, Google GKE.

3️⃣ Registro de Contenedores

Almacena y distribuye imágenes de contenedores.
Ejemplo: Docker Hub, AWS ECR, Azure ACR, GitHub Packages.

4️⃣ Capa de Networking y Service Mesh

Permite la comunicación entre contenedores.
Ejemplo: CNI, Istio, Linkerd.

5️⃣ Capa de Balanceo de Carga y Gateway API

Dirige el tráfico a los contenedores adecuados.
Ejemplo: NGINX, Traefik, Envoy, API Gateway.

6️⃣ Base de Datos y Almacenamiento Persistente

Bases de datos en contenedores o externas.
Ejemplo: PostgreSQL, MySQL, MongoDB, Redis.
Almacenamiento: Ceph, NFS, EFS, Persistent Volumes en K8s.

7️⃣ CI/CD para Automatización

Pipelines de despliegue y actualización continua.
Ejemplo: GitHub Actions, GitLab CI/CD, ArgoCD, Jenkins.

8️⃣ Observabilidad (Monitoreo y Logging)

Monitoreo: Prometheus + Grafana, Datadog.
Logging: ELK Stack (Elasticsearch, Logstash, Kibana).
Trazabilidad: OpenTelemetry, Jaeger.

📐 Ejemplo de Arquitectura con Contenedores

🚀 Conclusión

Una arquitectura con contenedores permite crear sistemas escalables, portátiles y eficientes. Kubernetes y Docker son claves en esta estrategia.

Comentarios (21)21 comentarios

Gabriel Obregón

Hace 3 años

Diego Fernando Ramos Aguirre

Patricio Sánchez Fernández

Tulio Melo

Luis Reynaldo Marino

José Luis Puc Sarmiento

Alex Naupay

Marcelo Gaston Duarte

Carlos Andrés Zambrano Barrera

Profesor

Jhon Freddy Tavera Blandon

Julian David Alzate Cuervo

Juan Espinosa

Julian Obando

Hace un año

Erika Patricia Montoya

Javier Hugo Noto Enriquez

Carlos Alexander Castillo Salamanca

Elisa Zamarron Muñoz

Rudy Alexander Orozco de León

Marcos Sarmiento Loarte

Jose Luis Quintero Sánchez

Cristofer Vargas Morales

ANDRES ALFONSO MIRA MEJIA

Luis Carlos Parra Raffán

Johny Vallejo

Mauricio Leon

Introducción al curso

5 razones para usar la nube ahora

Aplicación de Billetera Virtual: Conceptos y Funcionalidades Básicas

Cómo entender la nube

Servidores y almacenamiento en la nube

Tipos de bases de datos en la nube

Microservicios, funciones y contenedores en la nube

On-premises vs nube: qué cambia al escalar

Introducción a Cloud Computing / Nube

Qué es cloud computing y cómo se cobra

Ventajas reales de migrar a la nube

Qué cambia al migrar una app a la nube

Infraestructura Global en la Nube: Regiones y Zonas de Disponibilidad

Nube privada, pública, híbrida y multinube

Conceptos de Cloud Computing / Nube

Qué es cloud native y por qué importa

Arquitectura cloud native de una app real

Ventajas y retos del modelo serverless

Componentes clave de una arquitectura serverless

Arquitectura serverless con API y funciones

Principales Proveedores de Servicios Cloud y Sus Ventajas

Multi-Nube

Tipos de lock-in en arquitectura cloud

Estrategias multinube para elegir tu proveedor

Modelos de servicio en Cloud Computing / Nube

IaaS, PaaS y SaaS explicados con pizza

Características de una arquitectura en Cloud Computing /Nube

Alta disponibilidad vs tolerancia a fallos en la nube

Escalabilidad vertical vs horizontal en la nube

Construyendo nuestra arquitectura

Diagramación de Arquitectura Agnóstica para Aplicaciones

Arquitectura de Servidores para Escalabilidad y Alta Disponibilidad

Kubernetes y microservicios con autoescalado

Arquitectura Serverless: Diseño y Escalabilidad de Funciones

Tu primer paso para elegir proveedor cloud

Kubernetes y microservicios con autoescalado