Contenerización – Módulo 3

Laboratorio de Tecnolgía y
Arquitectura de
Contenerización
 Ejercicios

- Ejercicio de laboratorio 3.1: Despliegue y optimización de la solución

- Ejercicio de laboratorio 3.2: Prerrequisitos de activación de la solución
- Ejercicio de laboratorio 3.3: Acceso externo y uso simultáneo
- Ejercicio de laboratorio 3.4: Escalabilidad y coordinación de la solución
- Ejercicio de laboratorio 3.5: Preprocesamiento de la solución y gestión de imágenes de
contenedor
- Ejercicio de laboratorio 3.6: Gestión de despliegues e imágenes de contenedor
- Ejercicio de laboratorio 3.7: Despliegue de contenedores con afinidad de host
- Ejercicio de laboratorio 3.8: Escalamiento horizontal de contenedores
Arquitectura de Contenerización

Ejercicio de
laboratorio 3.1:
Despliegue y
optimización de la
solución
1⃣ Reformulación clara del problema (qué está mal hoy)

• La Organización A dispone de una Solución de Procesamiento

de Pedidos compuesta por múltiples servicios, componentes y
bases de datos que colaboran de forma síncrona para registrar
pedidos y procesar pagos. Durante las pruebas, la solución
presenta problemas de despliegue, rendimiento, escalabilidad
y confiabilidad, lo que obliga a replantear su arquitectura de
contenerización.
 Problemas identificados en la Solución de
Procesamiento de Pedidos

1⃣ Despliegue y agrupación incorrecta 2⃣ Responsabilidades mezcladas

(logging)

Todos los programas deben ejecutarse en El Servicio de Transacciones:

contenedores separados, pero: Procesa pagos bajo demanda
Algunos requieren compartir IP Debe ejecutar tareas periódicas de
Otros requieren acceso a registro
almacenamiento compartido El logging accede a una Base de Datos
El despliegue actual no soporta externa
contenedores coordinados. Esto degrada el rendimiento o fuerza al
servicio a permanecer activo.
 Problemas identificados en la Solución de
Procesamiento de Pedidos

3⃣ Sobrecarga de infraestructura 4⃣ Fallas persistentes y efecto en cascada

Al desplegar instancias:

Los hosts se sobrecargan Cuando los servicios fallan:

rápidamente Permanecen activos en estado
El rendimiento y la confiabilidad degradado
disminuyen Esto provoca:
La redistribución manual: Excepciones en tiempo de ejecución
Es lenta Fallas en otros servicios dependientes
No escala No existe detección ni recuperación
No responde en tiempo real automática.
 Arquitectura de la solución

Pod A (IP compartida)

Container A: Order Service
Container B: Notification Component
Container C: Order Database

Pod B (IP compartida distinta)

Container D: Transaction Service
Container E: Logging Component (sidecar)
Container F: Authentication Component
Container G: Transaction Database

Fuera de pods
Logging Database: Base de datos compartida (no en contenedor)
External Payment Service: Servicio externo
Patrones aplicados

1. Contenedor Sidecar (Sidecar Container)

Aplicado en: Logging Component (Container E)
junto al Transaction Service (Container D)
Beneficios:
El Transaction Service se dedica exclusivamente
a su lógica de negocio principal
El Logging Component maneja las tareas de
registro de forma independiente
Ambos comparten el mismo ciclo de vida y
pueden acceder a recursos compartidos del pod
El sidecar puede acceder a la Logging Database
externa sin afectar el rendimiento del servicio
principal
Patrones aplicados
2. Asignación automatizada de pods (Automated
Pod Placement)
Propósito: Utilizar el orquestador de
contenedores (Kubernetes) para:
Asignar automáticamente nuevas instancias de
Pod A y Pod B a hosts disponibles
Considerar los requerimientos de
procesamiento de cada pod
Optimizar la distribución de carga en el clúster
Eliminar el proceso manual de horas que tenían
antes
Mecanismos involucrados:
Optimizador de despliegues: Analiza capacidad y
requerimientos
Orquestador de contenedores: Ejecuta las
decisiones de placement
 3. Contenedor
observador (Watcher
Container)

Aplicado en:
Container A: Monitorea la salud del Order
Service
Container D: Monitorea la salud del Transaction
Service
Capacidades:
Monitoreo continuo de la salud de los servicios
Detección proactiva de fallas en tiempo de
ejecución
Terminación del servicio cuando se detecta una
falla (para que el orquestador lo reinicie)
Mejora la confiabilidad general de la solución
Requerimiento original Solución aplicada
IP compartida + filesystem
Pods con múltiples contenedores
compartido
Tareas de registro sin degradar Sidecar dedicado que accede a DB
rendimiento externa
Sobrecarga de hosts + traslado
Asignación automatizada de
manual lento
Contenedor observador + restart
Fallas por sobreutilización
automático
Arquitectura de Contenerización

Ejercicio de
laboratorio 3.2:
Prerrequisitos de
activación de la
solución
 Prerrequisitos de activación de la solución

Después de desplegar y probar una nueva versión de la Solución de Procesamiento de

Pedidos, los administradores identifican más requerimientos. Estos requieren cambios en
la lógica de solución que, de forma correspondiente, introducen los siguientes cambios en
el despliegue:

La lógica de solución requiere que se inicie la Base de Datos de Pedidos antes que el
Servicio de Pedidos, de manera que cuando el Servicio de Pedidos se active, pueda
acceder y cargar un conjunto de datos actual que necesita para el procesamiento de la
lógica de negocio.

El Componente de Autenticación proporciona el procesamiento de autenticación por parte

del Servicio de Transacciones, lo que significa que debe iniciarse antes que el Servicio de
Transacciones y que puede terminarse tan pronto como el Servicio de Transacciones esté
activo. Observe que estos dos cambios en el despliegue necesitan implementarse de
forma independiente el uno del otro.

¿Cómo se puede actualizar la arquitectura de la Solución de Procesamiento de Pedidos

para cumplir con todos los nuevos requerimientos enlistados? Utilice las siguientes
páginas para ilustrar y explicar la respuesta.
 Respuesta al Ejercicio3.2
Se puede aplicar el patrón Cadena de
contenedores para garantizar que el contenedor
que hospeda a la Base de Datos de Pedidos en el
Contenedor C se inicie antes que el Servicio de
Pedidos en el Contenedor A.

•
• La primera cadena de
contenedores, que establece la
secuencia de ejecución del
Contenedor C antes que el
Contenedor A, quedando el
Contenedor B fuera de la cadena.
• Se puede aplicar el patrón Cadena
de contenedores de nuevo para
garantizar que el contenedor que
hospeda al Componente de
Autenticación en el Contenedor F se
inicie antes que el Servicio de
Transacciones en el Contenedor D.
Arquitectura de Contenerización

Ejercicio de
laboratorio 3.3:
Acceso externo y
uso simultáneo
La Organización A tiene una Solución de Reportes Sobre
Demanda que un equipo de administradores internos utiliza
para generar periódicamente reportes de análisis de ventas
sobre demanda. La solución está compuesta por los siguientes
programas:
• Servicio de Reportes (en el Contenedor A)
• Componente de Acceso a Datos (en el Contenedor B)
• Componente de Conversión de Datos (en el Contenedor C)
• Componente de Creación de Reportes (en el Contenedor D)
Además, existen varias bases de datos internas accesibles
para el Componente de Acceso a Datos.
• Un administrador introduce criterios, como un rango de fechas y categorías de ventas de
productos, y envía una solicitud para generar un reporte.
• El Servicio de Reportes reenvía la solicitud y los criterios al Componente de Acceso a Datos,
que determina a qué fuentes de datos acceder y qué datos solicitar. Para realizar sus
funciones de acceso a datos, este componente se basa en un recurso de acceso a datos del
sistema proporcionado por el kernel del sistema operativo.
• Tras recopilar todos los datos solicitados, el Servicio de Reportes lo reenvía al Componente de
Conversión de Datos, que combina y consolida los datos en un conjunto de datos uniforme.
Para llevar a cabo el análisis sintáctico de los datos, este componente se basa en un recurso
de análisis sintáctico del sistema proporcionado por el kernel del sistema operativo.
• A continuación, el Servicio de Reportes reenvía este conjunto de datos al Componente de
Creación de Reportes, que lo formatea en un reporte presentable, listo para que el
administrador lo revise. Los criterios originales especificados por el administrador pueden
incluir solicitudes para que algunos de los datos del reporte se muestren en tablas o gráficas.
Para generar reportes con tablas o gráficas, este componente se apoya en un recurso gráfico
del sistema proporcionado por el kernel del sistema operativo.
 Problemas identificados – Solución de Reportes Sobre
Demanda

1⃣ Ciclo de vida ineficiente de componentes

2⃣ Retención temporal de datos para interacción

3⃣ Degradación de rendimiento por uso simultáneo

4⃣ Acceso externo no previsto originalmente

5⃣ Requerimientos de formatos específicos

6⃣ Riesgo de sobrecarga del Servicio de Reportes

1. Demanda de daemons (Daemon Demand)
Propósito: Garantizar recursos del sistema suficientes para cada contenedor
Beneficio: Evita falta de recursos y permite auto-escalado de pods según uso
simultáneo
Aplicado a: Todos los pods de la solución​

2. Contenedor embajador (Ambassador Container)

Componente: Container E - Componente Endpoint Externo
Función: Punto de contacto para programas de clientes externos
Ubicación: Dentro del Pod A junto al Reporting Service

3. Conexión segura de contenedores (Secure Container Connection)

Aplicado en: Container E (Contenedor embajador)
Función: Garantizar que mensajes de usuarios externos sean seguros (HTTPS)
Comportamiento: Rechaza automáticamente mensajes no seguros​
4. Contenedor adaptador (Adapter Container)
Componente: Container F - Componente de Conversión de Datos de
Salida
Función: Transformar datos del Reporting Service al formato requerido
por cada usuario externo
Propósito: Compatibilidad con formatos específicos de socios
5. Contenedores finitos (Finite Containers)
Aplicado a:
Containers B y C: Se terminan automáticamente al completar tareas de
recopilación de datos
Container D: Permanece activo 600 segundos (10 minutos) después de
entregar el reporte, luego se termina automáticamente
Propósito: Controlar tiempo de vida de contenedores según necesidad
 Implementación en
Categoría Patrón aplicado Ejercicio 3.3
Container E - Endpoint externo
Acceso y Adaptación Contenedor Embajador
con HTTPS

Container F - Conversión de
Acceso y Adaptación Contenedor Adaptador
formatos de salida

Pods B, C, D con tiempo de vida

Tareas/Trabajos Contenedores Finitos
controlado

Auto-escalado y gestión de
Orquestación Demanda de Daemons
recursos

Acceso controlado a recursos del

Infraestructura Gestión de Recursos sistema (data access, parser,
graphical)
Arquitectura de Contenerización

Ejercicio de
laboratorio 3.4:
Escalabilidad y
coordinación de la
solución
La Organización A tiene una Solución de Gestión de Equipos que
utiliza para llevar el control de la adquisición, asignación y
mantenimiento del equipo de construcción que alquila a muchos
clientes por distintos periodos.
La solución está compuesta por los siguientes programas:
• Servicio de Compras (en el Contenedor A)
• Servicio de Asignación de Equipos (en el Contenedor B)
• Servicio de Mantenimiento de Equipos (en el Contenedor C)
• Base de Datos de Inventario de Equipos (en el Contenedor D)
Imagen 1: Arquitectura original (antes del
escalamiento)

Estructura:​
Pod A: Container A - Purchasing Service
Pod B: Container B - Equipment Allocation Service
Pod C: Container C - Equipment Maintenance Service
Pod D: Container D - Equipment Inventory Database
Problema: Tres servicios con acceso directo de lectura/escritura a
una base de datos central
 Imagen 2: Arquitectura con escalamiento horizontal implementado

Estructura escalada:
Pods escalados horizontalmente:

Pod B (Equipment Allocation Service) - 3 instancias:

Container B1: Equipment Allocation Service (Instance 1)
Container B2: Equipment Allocation Service (Instance 2)
Container B3: Equipment Allocation Service (Instance 3)

Pod C (Equipment Maintenance Service) - 2 instancias:

Container C1: Equipment Maintenance Service (Instance 1)
Container C2: Equipment Maintenance Service (Instance 2)
Pods sin escalar:

Pod A (sin cambios):

Container A: Purchasing Service

Pod D (base de datos compartida):

Container D: Equipment Inventory Database
•
 Parte I – Elasticidad de contenedores (escalamiento
horizontal)

Qué muestra el diagrama

El Servicio de Asignación de Equipos (Contenedor B):
Se ejecuta en múltiples instancias
Distribuidas dentro del Pod B
El Servicio de Mantenimiento de Equipos (Contenedor C):
También se ejecuta en múltiples instancias
Dentro del Pod C

Patrón aplicado
Elasticidad de contenedores

Qué resuelve
Soporta picos de uso simultáneo
Permite crecer horizontalmente sin rediseñar los servicios
Mejora la capacidad de procesamiento
 Elección del nodo líder
Qué se ve en el diagrama

Parte II – En cada conjunto de instancias escaladas:

Una instancia está marcada como líder
Coordinación Un líder para Asignación de Equipos

para evitar Un líder para Mantenimiento de Equipos

Solo las instancias líderes:
conflictos de Ejecutan operaciones críticas

datos Realizan escrituras coordinadas en la Base de

Datos de Inventario de Equipos
Patrón aplicado
Elección del nodo líder
Qué resuelve
Evita conflictos de escritura simultánea
Coordina el acceso a la base de datos compartida
Previene excepciones en tiempo de ejecución
Mantiene la base de datos estable aun con múltiples
instancias
 Contenedor programado
Qué muestra el diagrama
El Logging Component:
Vive en el Contenedor E
Está separado de los servicios principales
Componente Tiene un ícono de reloj → ejecución programada
Escribe de forma independiente en:
de Registro Archivos del sistema
independiente Base de datos de inventario (para eventos/errores)
Patrón aplicado
Contenedor programado
Qué resuelve
Desacopla el logging de la lógica de negocio
Permite ejecución periódica o controlada
Reduce impacto en rendimiento
Mejora trazabilidad y monitoreo
•
Patrón Implementación Elemento visual
Elasticidad de Múltiples instancias de Pods 3 instancias de Pod B, 2 de
contenedores ByC Pod C
Instance 2 de Pod B es líder,
Elección del nodo líder Marcado como "leader" p
Instance 1 de Pod C es líder
Container E ejecuta tareas
Contenedor programado Icono de reloj en Pod ​
de registro periódicamente
Arquitectura de Contenerización

Ejercicio de laboratorio
3.5: Preprocesamiento
de la solución y gestión
de imágenes de
contenedor
 Problema central identificado

El Servicio de Procesamiento de Analítica de Datos:

Ejecuta una tarea de preprocesamiento costosa
Consume muchos recursos cada vez que se instancia
Este preprocesamiento se convirtió en un cuello de botella de rendimiento.
Se requiere:
Un Componente de Preprocesamiento separado
Que:
Se ejecute antes del servicio principal
Permanezca activo 30 segundos
Luego pueda terminarse
Este es un problema de orden de activación y ciclo de vida temporal, no
solo de código.
Para resolver el problema descrito, se aplican dos patrones de diseño en la
arquitectura de contenedores:
Patrón Contenedor init (Init Container): Se utiliza para garantizar que el
Componente de Preprocesamiento de Datos, alojado en el Contenedor C,
complete su tarea de preparación de datos antes de que se active el Servicio de
Procesamiento de Analítica de Datos.
Patrón Contenedor programado (Scheduled Container): Este patrón se aplica al
Contenedor C para mantenerlo activo durante un período específico de 30
segundos después de que haya finalizado su tarea y antes de que sea terminado.
Problema original Solución aplicada Beneficio
Preprocesamiento Servicio principal se
Contenedor init separado
consume recursos del enfoca solo en
(Container C)
servicio principal procesamiento

Preprocesamiento se
Cuello de botella en cada Mejora significativa de
realiza una vez antes de
invocación rendimiento
iniciar

Servicio necesita
Container C permanece Disponibilidad temporal
consultar datos
activo 30 segundos para consultas
preprocesados
Arquitectura de Contenerización

Ejercicio de laboratorio
3.6: Gestión de
despliegues e
imágenes de
contenedor
 Resumen de la Situación y el Problema

Situación Actual:
La organización despliega un Componente de Preprocesamiento de Datos a través de un ciclo de vida que incluye
servidores de desarrollo, preproducción (staging) y producción. Múltiples actores, incluyendo varios administradores
y un desarrollador, están involucrados en la gestión y actualización de este componente.

El Problema Principal:
La gestión de las imágenes de contenedor es caótica y genera confusión. El problema tiene dos vertientes:
[Link] de Versiones: Diferentes administradores registran versiones distintas de la misma imagen base sin
coordinación (ej. V1, V2, V3), lo que lleva al desarrollador a usar una versión que luego es sustituida por otro
administrador.
[Link] Manuales (Mutabilidad): En la etapa de preproducción, un administrador modifica manualmente el
entorno de ejecución de la aplicación para "afinarlo", en lugar de actualizar la imagen de contenedor.

Resultado:
Estas prácticas rompen la inmutabilidad de los contenedores, causando inconsistencias entre los entornos. Lo que
funcionó en desarrollo o preproducción (debido a ajustes manuales) falla al llegar al servidor de producción debido a
errores en tiempo de ejecución.
 Situación observada

Múltiples administradores registran distintas versiones

Modifican imágenes y tiempos de ejecución
Promueven imágenes manualmente entre ambientes
No existe control centralizado
Problemas concretos
1⃣ Versiones divergentes de la imagen base
2⃣ Imágenes personalizadas inconsistente
3⃣ Cambios no controlados en tiempo de ejecución
4⃣ Errores tardíos en producción
Problema original Solución aplicada Beneficio

Integridad de imagen: solo

Versiones divergentes Fuente única de verdad
imágenes verificadas

Misma imagen en todos los

Imágenes inconsistentes Registry centralizado
ambientes
Runtime no puede
Cambios no controlados Inmutabilidad del runtime
modificarse

Errores tardíos Pipeline reproducible Comportamiento predecible

Arquitectura de Contenerización

Ejercicio de
laboratorio 3.7:
Despliegue de
contenedores con
afinidad de host
 Una Solución de Gestión de Clientes compuesta por:

Servicios (Cliente, Contacto, Reportes Históricos, Ventas)

Componentes de soporte (Procesamiento por Lotes, Notificaciones, Cálculo de Comisiones,

Políticas)

Múltiples bases de datos (RH, Central, Ventas, Auditoría)

Todos los programas:

Están contenedorizados
Se despliegan como contenedores independientes
La solución interactúa de forma intensiva entre:
Servicios componentes
Servicios bases de datos
Reglas de afinidad y antiafinidad

Reglas de afinidad (deben estar juntos):

A + B (mismo host)
C + E (mismo host)
A + F (mismo host)
D + G (mismo host)
B + H (mismo host)
D + I (mismo host)
D + K (mismo host)
C + L (mismo host)
Reglas de antiafinidad (deben estar
separados):
C ≠ A, B
D ≠ A, B, J
J ≠ todos (aislado completamente)
 Solucion

Host Contenedores Total Razón de agrupación

Servicios de contacto con
Host A A, B, F, H 4 clientes y componentes
relacionados
Servicios de reportes
Host B C, E, L 3
históricos y auditoría

Servicios de ventas con bases

Host C D, G, I, K 4
de datos relacionadas

Base de datos central aislada

Host D J 1
por cumplimiento
Arquitectura de Contenerización

Ejercicio de
laboratorio 3.8:
Escalamiento
horizontal de
contenedores
 Ejercicio de laboratorio 3.8: Escalamiento
horizontal de contenedores

• Una vez desplegada y activa la Solución de Gestión de Clientes, accede a ella

mucho personal de oficina desde diferentes ubicaciones. El volumen de
acceso es mayor que el esperado, y pronto la solución cae en limitaciones de
capacidad que le obligan a rechazar solicitudes del personal de oficina
mientras está ocupada procesando solicitudes recibidas anteriormente.

• Utilice las siguientes páginas para ilustrar y explicar la manera en que la

solución se puede mejorar aún más para soportar los nuevos requerimientos
de uso, sin tener que infringir ninguna de las reglas de afinidad y antiafinidad
existentes.
•

•
 Contenedores Instancias
Host Razón
escalados totales

Container A (Customer Alto acceso de

Host A 3 réplicas
Service) personal de oficina

Container C (Historical Consultas de

Host B 3 réplicas
Reporting Service) reportes frecuentes

Acceso desde
Container D (Sales Staff
Host C 3 réplicas múltiples
Service)
ubicaciones

Container J (Central No escala - debe

Host D 1 instancia
Database) permanecer aislado