Arquitectura de Contenerización

Lección: Lección
1: Cómo
entender la
contenerización
Cómo entender la contenerización

La contenerización es una tecnología de virtualización utilizada

para desplegar y ejecutar aplicaciones y servicios sin la necesidad
de desplegar un servidor virtual para cada solución. Esta sección
introductoria cubre los fundamentos de la tecnología de
virtualización Relevante e introduce la contenerización, junto con
sus factores, beneficios y retos
Esta sección está organizada en las siguientes partes

• Breve historia de la contenerización

• Fundamentos de sistemas operativos y virtualización
• Diferencias entre virtualización y contenerización
• Factores tecnológicos y empresariales
• Ventajas y riesgos de implementar contenerización
Orígenes

• Años 70 (Unix): Surge como capacidad de separación e

asilamiento en entornos sandbox
• En Linux: Consolidación como virtualización a nivel de SO,
múltiples ambientes aislados
• Desafíos iniciales: Administración unificada, portabilidad
verdadera y escalabilidad eficiente
• Plataformas de Orquestación: Apache Mesos, Google Borg,
Facebook Tupperware - gestión de clústeres a escala
• Docker: Integra la contenerización en IT mainstream, impulsa
nuevas plataformas
• Ecosistema Moderno: Marathon, Kubernetes, Docker Swarm -
conmutación por error automática y escalabilidad
 Conceptos básicos del sistema
operativo

Un sistema operativo es Además, hospeda y Durante su instalación, El conjunto de Las aplicaciones también
un software instalado en soporta las operaciones también puede incluir programas del sistema pueden incluir su propio
una computadora que continuas de las aplicaciones de uso operativo que permiten tiempo de ejecución, que
provee programas, aplicaciones que se general para el la ejecución activa de las se ejecuta sobre el
herramientas, librerías y ejecutan sobre él. consumidor. aplicaciones se conoce ambiente de ejecución
recursos para como tiempo de provisto por el sistema
administrarla. ejecución. operativo.
Conceptos básicos de virtualización

La virtualización es una tecnología que El recurso más comúnmente virtualizado es

permite que un recurso de TI físico se divida el servidor físico, que ofrece un ambiente de
en múltiples imágenes virtuales, sistema operativo para hospedar
compartiendo su capacidad de aplicaciones, servicios y otros programas de
procesamiento entre varias soluciones. software
Servidor físico

• El recurso de TI físico virtualizado más comúnmente es el

servidor físico
• Un servidor físico proporciona un ambiente de sistema
operativo que puede hospedar aplicaciones, servicios y otros
programas de software
 Servidor virtual

Cada servidor virtual puede

La virtualización permite
Cada servidor virtual ofrece su brindar un entorno de sistema
abstraer el ambiente de sistema
propia copia del ambiente de operativo independiente para
operativo de un servidor físico
hospedaje del sistema operativo, diferentes aplicaciones o
en uno o más servidores
conocida como sistema servicios, sin que estos conozcan
virtuales que se ejecutan sobre
operativo invitado.​ cómo funciona el servidor físico
el mismo hardware.​
subyacente.​

El servidor físico puede escalarse Los administradores de

según la demanda agregada, servidores virtuales gestionan
mientras el administrador del solo sus ambientes virtuales, sin
servidor físico mantiene el acceso al servidor físico, lo que
control del hardware y su mejora el aislamiento y la
sistema operativo.​ independencia administrativa
 Hipervisor

• El componente que crea y ejecuta

múltiples servidores virtuales sobre un
servidor físico se llama hipervisor.​
• Los servidores virtuales ven el hardware
emulado por el hipervisor como si fuera
hardware real.​
• Cada servidor virtual tiene su propio
sistema operativo invitado, que debe
instalarse, administrarse y mantenerse
igual que en un servidor físico
 Tipos de Virtualización
Existen dos tipos de ambientes de virtualización según si el servidor físico
tiene o no sistema operativo instalado.​

En la virtualización Tipo 1, el servidor físico no tiene sistema operativo, solo el

hipervisor, que crea los servidores virtuales y sus sistemas operativos
virtualizados.​

En la virtualización Tipo 2, el servidor físico sí tiene un sistema operativo

instalado y además un hipervisor, que igualmente crea los servidores
virtuales y sus ambientes de sistemas operativos virtualizados
 Virtualización y contenerización
Concepto Principal
• Contenerización: Es una tecnología de virtualización que permite crear ambientes
de hospedaje virtuales llamados "contenedores".
• Propósito: Proporcionar un entorno virtual con recursos del sistema operativo (SO)
para hospedar software y recursos de TI.

Diferencia Clave: Servidor Virtual vs. Contenedor

• Servidor Virtual (VM): Proporciona una versión virtual del sistema operativo
completo.
• Contenedor: Proporciona solo el subconjunto de recursos del SO que el software
realmente necesita.

Ventajas del Contenedor

• Consume menos espacio.
• Funciona de manera más eficiente que un servidor virtual tradicional.
Modelos de Despliegue
de Contenedores

1. En Servidores Físicos (Bare Metal)

• La plataforma de contenerización
se instala sobre el SO del servidor
físico.
• Características: No requiere
servidores virtuales; abstrae solo
los recursos relevantes para la
aplicación
 Modelos de Despliegue de
Contenedores
En Servidores Virtuales (Virtualización) Los contenedores se despliegan dentro de
VMs por razones de seguridad y aislamiento. Existen dos tipos:
• Virtualización Tipo 1 (Entornos de Producción):
– El hipervisor corre directamente sobre el hardware.
– Es el estándar para producción debido a la mitigación de vulnerabilidades
de seguridad
 Modelos de Despliegue de
Contenedores
• Virtualización Tipo 2 (Desarrollo y Pruebas):
– El hipervisor corre sobre un SO anfitrión.
– Ideal para entornos de desarrollo o infraestructuras pequeñas que
necesitan el SO base para otros programas
Factores de negocio
Factores tecnológicos
Beneficios de utilizar la contenerización

Optimización de soluciones: los

Mayor escalabilidad: su ligereza
contenedores minimizan la huella de
permite crear y escalar instancias
CPU, memoria y almacenamiento,
rápidamente frente a picos de
usando solo los recursos que la
demanda.​
aplicación necesita.​

Mayor resiliencia: la orquestación Mayor velocidad de despliegue: los

puede recrear contenedores contenedores se construyen y
automáticamente ante fallos, despliegan más rápido que las VMs,
aumentando la disponibilidad del acelerando DevOps e integración
servicio. continua.​

Soporte de versiones: las imágenes de Mayor portabilidad: el mismo

contenedor facilitan versionar código contenedor puede ejecutarse en
y dependencias, comparar cambios y distintos servidores o nubes sin
hacer rollbacks.​ cambios en el software interno
 RIESGO

Falta de aislamiento del sistema operativo Mayor superficie de ataque: el

host: varios contenedores comparten el administrador del contenedor puede llegar
mismo OS; si el host falla o es al kernel compartido, lo que introduce una
comprometido, todos los contenedores se vulnerabilidad si no se usan capas extra
ven afectados.​ como VMs o controles estrictos.​

Mayor carga administrativa: cada

Aumento de la complejidad: agregar contenedor suele empaquetar una versión
contenerización introduce nuevas capas, específica de la solución, requiriendo
diseño adicional, posible impacto en mantenimiento continuo de imágenes y
rendimiento y una curva de aprendizaje más versiones a medida que el software
alta para equipos e infraestructura.​ evoluciona.
Arquitectura de Contenerización

Lección 2:
Términos y
conceptos
fundamentales
Objetivos de la lección
Esta sección cubre los siguientes términos y
conceptos fundamentales:
•Contenedores
•Imágenes de contenedor
•Motores de contenerización
•Pods
•Hosts
•Clústeres de hosts
•Redes de host y redes superpuestas
Los contenedoresy las imágenes de contenedorse
exploran con mayor detalle en las seccionesCómo
entender loscontenedoresyCómo entender las
imágenes de contenedorsubsecuentes.
 ¿Qué es un contenedor?

• Un contenedor es un ambiente de hospedaje virtualizado optimizado para

ofrecer solo los recursos del sistema operativo que requieren los programas
que aloja.​
En diagramas arquitectónicos suele representarse con un símbolo específico,
ya que sus características y rasgos se analizan en detalle en secciones
posteriores dedicadas a comprender los contenedores.
 • Una imagen de contenedor es como una plantilla predefinida
Imágenes de usada para crear contenedores desplegados.
• Definir y usar imágenes es parte central del funcionamiento
contenedor de las plataformas de contenerización y se detalla más en
secciones posteriores del curso.
Motores de contenerización

Un motor de contenerización es el componente que crea contenedores a

partir de imágenes de contenedor predefinidas, ejecutándose sobre el
sistema operativo de un servidor físico o virtual.​

Abstrae los recursos necesarios para cada contenedor específico y

constituye el núcleo de la plataforma de contenerización.​

Se organiza en dos planos: un plano de administración (GUI y CLI para que

administradores configuren y gestionen) y un plano de control (funciones
automáticas que ejecutan las órdenes y políticas definidas).​

Un mismo motor de contenerización puede crear y gestionar múltiples

contenedores en el mismo host.
Motores de contenerización
Pods

• Un pod es un tipo especial de contenedor de sistema que

puede hospedar uno o varios contenedores que comparten
ciertos recursos.
•
Dentro de un pod, los contenedores comparten
almacenamiento, red y la misma configuración de ejecución, lo
que permite que funcionen como una unidad lógica
Hosts

• Un host es el entorno (servidor o nodo) donde se despliega un

contenedor.​
• El host aporta el sistema operativo del cual el contenedor
abstrae los recursos necesarios para ejecutar sus programas.​
• En un mismo host se pueden ejecutar múltiples contenedores,
con o sin pods, según soporte del motor de contenerización.​
• Los hosts suelen ser servidores físicos, pero también pueden
ser servidores virtuales; cuando un contenedor corre en un
servidor virtual, se considera virtualización anidada.
 Clústeres de hosts

Varios hosts pueden agruparse en un clúster En un clúster, los hosts (físicos o virtuales) se
para formar un pool de recursos de cómputo conocen como nodos y pueden combinarse
con mayor capacidad disponible.​ en distintos tipos de clúste
 TIPOS DE CLUSTER

1 2 3
Clúster de carga balanceada: Clúster de alta disponibilidad Clúster de escalamiento:
distribuye las cargas de (HA): usa redundancia y soporta escalamiento vertical
trabajo entre nodos, conmutación por error y horizontal, muy usado por
normalmente mediante un automática para mantener el plataformas de
balanceador de carga, servicio ante fallos de nodos.​ contenerización para
manteniendo administración rendimiento y resiliencia
centralizada.​
Redes de host y redes superpuestas

• Cada host tiene su propio motor de contenerización, encargado

de crear imágenes y desplegar/ejecutar contenedores en ese
host.​
• Los contenedores de un mismo host se comunican por una red
de host local, mientras que contenedores en distintos hosts lo
hacen mediante una red superpuesta; ambas forman las redes
de contenedores.​
• Las redes de contenedores se configuran para dar
escalabilidad, resiliencia y limitar qué programas pueden
acceder a recursos externos a la red de contenedores.
Arquitectura de Contenerización

Lección 3:
Cómo
entender los
contenedores
 Objetivos de la lección

• Un contenedor puede alojar cualquier tipo de programa de software, pero se

usa sobre todo para hospedar aplicaciones o servicios que forman parte de
una solución de automatización más grande.​
•
En este contexto, se distingue entre programas diseñados como aplicaciones
completas y programas diseñados como servicios, que suelen empaquetarse
en contenedores para componer soluciones distribuidas
Aplicaciones contenerizadas vs. servicios
contenerizados

• Una aplicación contenerizada suele ser una solución completa

o un componente dentro de una solución distribuida; puede
exponer o no una API.​
Un servicio contenerizado se caracteriza por exponer siempre
una API para ser invocado por otros programas consumidores.​
Las mismas arquitecturas y escenarios de procesamiento en
contenedores aplican tanto a aplicaciones como a servicios, e
incluso a otros programas como bases de datos
Analogía principal: Un restaurante vs. una máquina expendedora

Servicio contenerizado = Restaurante

• Tiene un menú público → API publicada
• Está diseñado para que muchos clientes hagan pedidos
• Cada cliente no sabe cómo se cocina, solo qué pedir y qué
recibe
• Está optimizado para mucho tráfico y uso constante
En software:
• Un servicio expone una API
• Es invocado por uno o muchos consumidores
• Vive bien en entornos distribuidos y de alto rendimiento
 Aplicación contenerizada = Cocina completa en una casa

• Puede funcionar sola, sin clientes externos

• Puede ser parte de una casa más grande (una solución)
• Puede tener interfaz (pantalla) o no
• Puede no exponer API… hasta que la necesita
En software:
• Una aplicación puede ser:
– Independiente (standalone)
– Un componente dentro de una solución mayor
• Puede tener API o no
• Puede necesitar una API solo para hablar con el contenedor
Hospedaje de contenedores

• Un solo contenedor puede hospedar un solo programa de

software, y múltiples contenedores pueden coexistir en el
mismo ambiente de forma aislada y segura.​
• Un contenedor también puede hospedar varios programas
relacionados o diferentes, y los contenedores se generan
dinámicamente a partir de imágenes de contenedor
predefinidas
• .
 Agrupación de contenedores
en pods
• Un pod agrupa contenedores
relacionados que comparten IP y
pueden comunicarse fácilmente.
• Dentro del pod, los contenedores
pueden interactuar y compartir
almacenamiento, manteniendo
aislamiento lógico.
• Los pods facilitan la orquestación y
escalado, siendo requeridos en
muchas plataformas aunque tengan
un solo contenedor.
• Al ejecutarse en servidores virtuales,
la virtualización puede causar latencia,
afectando el rendimiento en
aplicaciones sensibles.
 Instancias y clústeres de
contenedores
• Se pueden crear
varias instancias (réplicas) de un
mismo contenedor con el mismo
programa para atender múltiples
consumidores en paralelo.
• Un clúster de contenedores es un
pool de instancias precargadas en
memoria, listas para usarse, que
puede crearse manual o
automáticamente.
• Estos clústeres se usan para alto
rendimiento y permiten
autoescalamiento, ajustando
dinámicamente el número de
contenedores según la demanda
Gestión de paquetes de contenedor

• La gestión de paquetes de contenedor agrupa una aplicación y

todas sus dependencias en una unidad portable (paquete)
basada en una imagen de contenedor, desplegable en
cualquier plataforma compatible.
• Las herramientas de gestión de paquetes (por ejemplo,
gestores tipo Helm) ofrecen CLI para crear, etiquetar, versionar
y enviar imágenes a registros, usando plantillas/archivos de
configuración para definir contenido y dependencia
Orquestación de contenedores

El proceso de automatizar el despliegue, escalamiento y gestión

de las aplicaciones contenerizadas en un ambiente de
computación distribuido se conoce como orquestación de
contenedores.

Conlleva el uso de una plataforma de orquestación de

[Link] plataforma de orquestación de contenedores
realiza una amplia gama de operaciones en un ambiente de
computación distribuido. Estas son algunas de las operaciones
clave realizadas por una plataforma de orquestacion
Orquestación de contenedores

• Despliegue de contenedores: distribuye contenedores en

múltiples nodos del clúster, asegurando configuración y red
correctas.​
• Balanceo de carga: reparte el tráfico entre contenedores de la
misma app para alta disponibilidad y escalabilidad.​
• Escalabilidad automática: ajusta el número de contenedores
según la demanda para optimizar costos y recursos.​
• Monitoreo de salud: supervisa contenedores y reinicia o
reemplaza automáticamente los que fallan.​
Orquestación de contenedores

• .
• Descubrimiento de servicios: mantiene un registro de servicios
para que las apps se encuentren y se comuniquen entre sí.
• Orquestación de almacenamiento: gestiona el almacenamiento
persistente, asegurando guardado y lectura correctos de datos.
• Orquestación de redes: asigna IP única a cada contenedor y
enruta el tráfico entre ellos.
• Gestión de configuración: aplica y propaga cambios de
configuración a contenedores en ejecución de forma
automatizada
 Componentes de una plataforma de
orquestación

• Tiempo de ejecución de contenedores: ejecuta y gestiona los contenedores

en cada nodo del clúster.
• Servidor de API: expone un punto central para interactuar con la plataforma,
recibe peticiones de clientes y coordina al resto de componentes.
• Programador (scheduler): decide en qué nodo desplegar cada contenedor
según recursos disponibles y balance de carga.
• Gestor de controladores: administra controladores que automatizan
escalado, replicación y chequeos de salud del ciclo de vida de las apps.
• Almacén distribuido clave-valor: guarda configuración, datos de
descubrimiento de servicios y otros metadatos del clúster.
• Red (networking): provee la infraestructura de red para comunicación entre
contenedores, incluyendo enrutamiento y balanceo.
• Almacenamiento: gestiona el almacenamiento persistente, acceso a
volúmenes compartidos e integridad de los datos
Pasos básicos en la orquestación

• Crear imagen de contenedor con el código de la aplicación y

sus dependencias.​
• Enviar la imagen a un registro de contenedores centralizado.​
• Definir el despliegue: réplicas, configuración de red y
requerimientos de almacenamiento en la plataforma de
orquestación.​
• Desplegar la aplicación en múltiples nodos del clúster,
asegurando la cantidad deseada de réplicas y accesibilidad.​
• Monitorear y gestionar: salud, escalado automático,
actualizaciones y parches sin downtime, con logging y métricas.​
• Gestionar múltiples aplicaciones contenerizadas en paralelo,
respetando los requerimientos específicos de cada una
 Diferencias entre gestión de paquetes y
orquestación

• Gestión de paquetes de contenedor y orquestación cumplen roles

complementarios pero diferentes en el ciclo de vida de apps contenerizadas.
• Función: la gestión de paquetes se centra en manejar imágenes de contenedor y
sus dependencias; la orquestación automatiza despliegue, escalado y operación
de las aplicaciones que usan esas imágenes.
• Alcance: gestión de paquetes trabaja sobre la imagen individual; la orquestación
abarca la aplicación completa en el clúster (pods, servicios, red, storage).
• Nivel de abstracción: gestión de paquetes opera a bajo nivel (definir qué lleva la
imagen); orquestación ofrece una vista de alto nivel de cómo, dónde y cuántas
instancias se ejecutan.
• Conjunto de herramientas: gestión de paquetes aporta utilidades para
empaquetar, versionar y distribuir imágenes; la orquestación añade APIs y
herramientas para gestionar contenedores en ejecución, redes, almacenamiento
y otros recursos de infraestructura.
 REDES DE CONTENEDORES

• Las redes de contenedores permiten la comunicación entre contenedores y

soportan su disponibilidad, escalabilidad y resiliencia; suelen ser redes
virtuales gestionadas y cifradas de forma independiente.​
• Hay dos tipos principales: redes de host (con contenedores en el mismo host)
y redes superpuestas (con contenedores en hosts distintos, conectados a
través de varios motores de contenerización).​
• El alcance de una red de contenedores normalmente coincide con el de una
solución; varias soluciones implican múltiples redes, pero un mismo
contenedor reutilizable puede pertenecer a varias redes.​
• Por defecto, la red suele limitar la comunicación a la solución contenerizada,
pero puede configurarse para permitir acceso a recursos externos no
contenerizados, como bases de datos legacy.​
• Cada contenedor recibe una o más direcciones IP (una por red); si varios
contenedores comparten un pod, comparten IP y se diferencian por puertos
 Contenedor enriquecido
• Un contenedor enriquecido es un contenedor al que el
motor de contenerización añade capacidades avanzadas,
más allá de ejecutar el proceso básico.​
• Estas capacidades pueden incluir: limitar recursos (CPU,
memoria) del contenedor, recopilar registros de uso, definir
políticas de reinicio, gestionar volúmenes compartidos
entre contenedores y host, y exponer funciones de
monitoreo de salud.​
• Algunos motores también permiten que el contenedor
actúe como proxy para solicitudes hacia los servicios que
hospeda, facilitando composición de servicios y control
adicional del tráfico.
 Otras características
• Un contenedor puede desplegar junto a la aplicación
principal varios programas de soporte, como bases de
datos, utilitarios o monitores.
• Es posible limitar los recursos de infraestructura que
consume cada contenedor (CPU, memoria, etc.).
• Se puede restringir la visibilidad de programas y
recursos externos a los que el contenedor y sus
aplicaciones pueden acceder, mejorando la seguridad.
• Los programas hospedados suelen compartir el
mismo ciclo de vida del contenedor: inician, se
detienen, se pausan y se reanudan en sincronía con él.
Arquitectura de Contenerización

Lección 4:
Cómo entender
las imágenes de
contenedor
Objetivos de la lección

• Las imágenes de contenedor son una parte central de las

plataformas de contenerización. Ellas forman la base de la
creación continua de contenedores. El procesamiento de las
imágenes de contenedor es una de las principales
responsabilidades del motor de contenerización
 ¿Qué es una imagen de contenedor?

Hay dos tipos principales de imágenes de contenedor, cada una con un rol distinto en la cadena de
construcción:
• Imágenes base de contenedor:
– Actúan como plantillas parciales sobre las que se construyen imágenes personalizadas
(por ejemplo, una imagen base con solo SO + runtime).
– Se publican en un registro para que otros equipos o proyectos las reutilicen como punto
de partida.
• Imágenes de contenedor personalizadas:
– Se crean a partir de una imagen base añadiendo la aplicación específica, configuración y
dependencias necesarias.
– Sirven directamente para crear contenedores desplegados y, a su vez, pueden reutilizarse
como nuevas imágenes base para futuros builds.
 Inmutabilidad de las imágenes

• La imagen de contenedor es inmutable: una vez creada no se

modifica, ni se parchea ni se actualiza directamente.
Si se necesita un cambio, se ajusta el archivo de creación (Dockerfile
u otro) y se genera una nueva versión de la imagen, con su propio
identificador y contenedor asociado.
•
La inmutabilidad aplica al contenido definido en la imagen; ciertos
parámetros del contenedor en ejecución sí pueden cambiarse vía
herramientas administrativas sin reconstruir la imagen.
Cada imagen recibe una clave o digest único que permite identificar
con precisión la versión almacenada en registros o en el runtime de
contenerización.
Abstracción de las imágenes de contenedor

• Una imagen base de contenedor generalmente proporcionará

un subconjunto de las funciones que ofrece el sistema
operativo host subyacente. Esto se conoce comoabstracción
del sistema operativoo, simplemente, abstracción. Sin
embargo,no todas las partes del sistema operativo son
abstraídas por la imagen decontenedor, como se explica con
mayor detalle en las dos subsecciones siguientes
Abstracción del kernel del sistema operativo

• El kernel es el núcleo del sistema operativo y concentra las

funciones esenciales: acceso a CPU, memoria, dispositivos de
E/S, almacenamiento, drivers, sistemas de archivos y energía.
• Las imágenes de contenedor no incluyen el kernel; este vive en
el motor de contenerización, que actúa como intermediario y
expone sus funciones a los contenedores.
• Al compartir el kernel del host, las imágenes son más ligeras y
los motores pueden trabajar con kernels de distintos sistemas
operativos, mejorando la portabilidad de los contenedores
entre ambientes.
Abstracción del sistema operativo más allá del
kernel

• La imagen de contenedor sí abstrae partes del sistema

operativo que están fuera del kernel, como librerías,
compiladores, herramientas del sistema y utilidades
administrativas.
• Estos componentes incluyen librerías de sistema, plataformas
de cifrado, monitoreo, archivos de configuración, editores,
herramientas para administradores y programas de
localización.
• Al empaquetar este subconjunto del sistema operativo, la
imagen crea un ambiente de ejecución personalizado y
optimizado, que sigue siendo portátil porque estos recursos
viajan junto con el contenedor a cualquier host compatible.
 Proceso de creación de imágenes
personalizadas

Un archivo de creación de contenedores es un archivo de configuración (legible

por humanos y máquinas) que define qué incluye una imagen de contenedor
personalizada.
En este archivo se especifica:
• La imagen base que se usará como punto de partida.
• Los recursos adicionales del sistema operativo (librerías, herramientas, etc.)
que se agregarán a la imagen.
• Las redes de contenedores en las que deberá participar el contenedor
resultante al desplegarse.
• La sintaxis y formato del archivo dependen del motor de contenerización
utilizado, aunque el propósito es siempre el mismo: describir cómo construir
la imagen personalizada.
 Capas de la imagen de contenedor

Una imagen de contenedor se construye en varias capas, cada una generada por una instrucción
del archivo de creación.
En las capas se almacenan datos como archivos y carpetas, configuración, bases de datos,
ejecutables, código de la aplicación y componentes del sistema operativo necesarios para
ejecutarla.

Todas las capas, excepto la última, son de solo lectura y se combinan mediante un sistema de
archivos de unión, lo que permite reutilizar capas comunes entre muchas imágenes y reduce
espacio.

Una imagen base está formada por sus propias capas; cuando se crea una imagen personalizada,
la imagen base completa pasa a ser la capa inferior y encima se agregan nuevas capas, por
ejemplo la del programa de software hospedado.

Debido a la inmutabilidad de las imágenes, cualquier cambio en una capa exige generar una nueva
versión de la imagen de contenedor.
Cómo se crean las imágenes de contenedor
personalizadas

• El motor de contenerización toma el archivo de creación y la

imagen base para construir una imagen de contenedor
personalizada y, a partir de ella, generar y desplegar el
contenedor real.
• Esa imagen personalizada suele guardarse en el
almacenamiento interno del motor para crear rápidamente
nuevas instancias (escalado y resiliencia), aunque también
puede publicarse en el registro si se quiere reutilizar como
nueva imagen base
Arquitectura de Contenerización

Lección 5:
Mecanismos de
contenerización
 Objetivos de la lección

Los mecanismos de contenerización son artefactos tecnológicos estándar que se

usan para diseñar y operar entornos con contenedores.
Incluyen, entre otros:
• Motor de contenerización, imágenes de contenedor y registro de imágenes,
que cubren construcción, almacenamiento y provisión de imágenes.
• Clúster de contenedores, orquestador, optimizador de
despliegues y programador de contenedores, que gestionan ejecución,
ubicación y escalado.
• Paquetes, depósito de paquetes y gestor de paquetes de contenedor, que
agrupan apps con dependencias y facilitan su distribución y versionado.
 Motor de
contenerización

• Un motor de
contenerización es el
componente central de la
plataforma de
contenedores que se instala
sobre el sistema operativo
del host.
•
Su función principal es
procesar archivos de
creación e imágenes de
contenedor para generar
imágenes personalizadas y
desplegar los contenedores
correspondientes.
 Imagen de
contenedor

Una imagen de contenedor es

una plantilla predefinida que el
motor de contenerización utiliza
para crear contenedores reales
con todo el software y
dependencias necesarias.

Actúa como modelo inmutable a

partir del cual se instancian uno
o varios contenedores idénticos
en tiempo de despliegue.
 Registro de
imágenes

Las dos frases están correctas y

claras para usar en una slide:
• Una imagen de
contenedor es una plantilla
predefinida que el motor de
contenerización utiliza para
crear contenedores reales
con todo el software y
dependencias necesarias.
• Actúa como
modelo inmutable a partir
del cual se instancian uno o
varios contenedores
idénticos en tiempo de
despliegue.
 Clúster de
contenedores

• Un clúster de
contenedores es un
conjunto de instancias
de contenedores ya
preactivadas que
forman un pool listo
para usarse.
•
Su objetivo es permitir
el aprovisionamiento
rápido de nuevas
instancias de
contenedores cuando
aumenta la demanda,
mejorando rendimiento
y respuesta.
 Paquete

• Un paquete es un archivo
de despliegue de
contenedores que define la
lógica de flujo de trabajo
para poner en marcha un
conjunto de contenedores
relacionados.
•
Los contenidos de un
paquete pueden incluir la
lógica de despliegue de
todos los contenedores
necesarios para una
solución distribuida
completa, coordinando su
orden, dependencias y
configuración.
•
 Depósito de
paquetes

• Un depósito de paquetes es
un dispositivo o repositorio
de almacenamiento
diseñado específicamente
para guardar paquetes de
despliegue de
contenedores.

Como cada paquete puede

abarcar una solución completa,
estos depósitos se utilizan para
la gestión de versiones de
soluciones, permitiendo
almacenar, organizar y recuperar
distintas versiones de los
paquetes.
 Orquestador de
contenedores

• Un orquestador de contenedores es
un mecanismo capaz de realizar
tareas avanzadas y coordinadas de
gestión, despliegue y configuración
de contenedores sobre un clúster
de hosts.
•
Proporciona una forma de
administrar aplicaciones
contenerizadas ocultando la
infraestructura subyacente y
exponiendo al usuario un único
clúster virtual, asegurando que los
contenedores se desplieguen en los
hosts correctos, se escalen según la
demanda, se reemplacen cuando
fallan y se conecten a los servicios
de red apropiados.
•
.
 Optimizador de
despliegues

• Un optimizador de
despliegues es un mecanismo
que monitorea los distintos
hosts disponibles para
determinar cuál es el más
adecuado para alojar un pod
recién generado y sus
contenedores.​

• Una vez identificado el host

óptimo, comunica esa
decisión al orquestador de
contenedores, que se encarga
de desplegar el pod y sus
contenedores en esa
ubicación específica dentro
del clúster.
Programador de
contenedores

• Un programador de
contenedores es un
mecanismo que coordina y
ejecuta lotes de tareas que
deben realizarse antes de que
un contenedor se active o
como apoyo a sus
operaciones en tiempo de
ejecución.
•
Puede ejecutar varios
procesos por lotes en paralelo
o de forma secuencial y,
además, orquestar esta lógica
siguiendo un cronograma de
• tareas predefinido, similar a
un sistema de jobs
planificados.
Gestor de paquetes de contenedor
• Un gestor de paquetes de contenedor es el mecanismo
que ejecuta la lógica de flujo de trabajo de despliegue
definida en el paquete (archivo de despliegue de
contenedores) y coordina el despliegue de los
contenedores hacia los hosts mediante el orquestador
de contenedores.
• Este gestor obtiene el archivo de despliegue desde
el depósito de paquetes, recibe del optimizador de
despliegues las indicaciones sobre qué host usar, y
aplica la secuencia definida en el paquete (qué
contenedor va en qué host/pod y en qué orden) para
desplegar todos los contenedores de una solución
completa.
Ejemplo 1: aplicar
un “paquete”
YAML completo
bash
• # Desplegar todos los recursos
definidos en un archivo (paquete)

• kubectl apply -f paquete-

[Link]

• paquete-
[Link] podría incluir
varios Deployments, Services,
ConfigMaps, etc., que representan
la solución completa
Arquitectura de Contenerización

Lección 6: Patrones
de múltiples
contenedores
Objetivos de la lección

En esta lección se introducen patrones de múltiples contenedores donde,

además del contenedor principal con la lógica de negocio, se añaden
contenedores secundarios de utilidad dentro de la misma solución.

Los tres patrones básicos que se mencionan son:

• Contenedor sidecar: añade capacidades auxiliares (por ejemplo, logging,
proxy local, sincronización) sin modificar la aplicación principal.
• Contenedor adaptador: encapsula lógica de conversión o adaptación (por
ejemplo, transformar protocolos o formatos) para que la aplicación
principal no tenga que hacerlo.
• Contenedor embajador: actúa como representante/proxy hacia sistemas
externos o remotos, gestionando conexiones, retries o routing en nombre
del contenedor principal
 Un contenedor sidecar permite sacar de la aplicación principal toda la
lógica de utilidad (logging, métricas, sincronización, proxy, etc.) para
que esta se concentre solo en la lógica de negocio.
Problema
• Cuando la aplicación procesa a la vez lógica de negocio y lógica
de utilidad, aumenta la complejidad del código y del
mantenimiento.
• Esto puede afectar la confiabilidad, el rendimiento y la capacidad
de escalar de forma limpia la parte de negocio.

Contenedor Solución con sidecar

sidecar
• Se crea un componente secundario (sidecar) y se despliega en un
contenedor separado, habitualmente dentro del mismo pod que
la aplicación principal.
• El sidecar asume la lógica de utilidad, mientras que la aplicación
se mantiene enfocada en el dominio de negocio; según el caso,
la aplicación puede comunicarse o no con el sidecar.
• Mecanismos implicados
• El motor de contenerización se encarga de ejecutar tanto el
contenedor de la aplicación como el contenedor sidecar.
• La imagen de contenedor define el contenido de cada
contenedor (aplicación principal y sidecar), permitiendo
versionar y desplegar ambos de forma reproducible.
•
 Un contenedor adaptador permite que la aplicación principal no tenga que
implementar lógica de conversión de datos específica para cada consumidor
externo, manteniéndose enfocada solo en su lógica de negocio.
Problema
• Si la aplicación contiene tanto la lógica de negocio como la lógica de
conversión de datos para distintas aplicaciones externas, el código se
vuelve más complejo y difícil de mantener.
• Además, la aplicación queda acoplada a múltiples consumidores;
cualquier cambio en ellos obliga a modificar la aplicación principal.

Contenedor
Solución con contenedor adaptador
• Se crea un componente secundario contenerizado
llamado adaptador que absorbe toda la lógica de conversión necesaria

adaptador
(formatos, protocolos, estructuras de datos).
• Este adaptador se despliega en un contenedor separado, normalmente
en el mismo pod que la aplicación, y puede haber un adaptador
distinto para cada aplicación consumidora que requiera una
representación diferente de los datos.
• Mecanismos implicados
• El motor de contenerización ejecuta tanto el contenedor de la
aplicación como el del adaptador dentro del mismo entorno.
• Cada uno se construye a partir de su propia imagen de contenedor, lo
que permite versionar y desplegar la lógica de negocio y la lógica de
conversión de forma independiente.
• Lección: Lección 6: Patrones de múltiples contenedores
• Contenido básico: desarrolla este punto con ejemplos y diagramas.
 Contenedor embajador

Un contenedor embajador extrae de la aplicación toda la lógica necesaria para comunicarse con aplicaciones externas
específicas (protocolos, mensajería, seguridad, etc.), de modo que la app se concentre solo en la lógica de negocio.
Problema
• La aplicación mezcla lógica de negocio con lógica de comunicación externa (APIs, autenticación, protocolos, timeouts,
retries), aumentando complejidad y riesgo de errores.
• Queda fuertemente acoplada a varios sistemas externos, por lo que cualquier cambio en sus APIs obliga a tocar la
aplicación principal.

Solución con contenedor embajador

• Se introduce un componente secundario contenerizado llamado embajador que encapsula toda la lógica de
comunicación hacia una aplicación externa concreta.
• El embajador se despliega en un contenedor separado, normalmente en el mismo pod, y puede haber un embajador
distinto por cada aplicación externa con requisitos de comunicación diferentes.
• Mecanismos implicados
• El motor de contenerización ejecuta tanto el contenedor de la aplicación como el contenedor embajador dentro del
mismo entorno.
• Cada uno se define mediante su propia imagen de contenedor, permitiendo versionar y evolucionar la lógica de
negocio y la lógica de comunicaciones de forma independiente.
•
 Uso conjunto de los patrones

Los patrones de múltiples contenedores (sidecar, adaptador y embajador) se

pueden combinar libremente alrededor de una misma aplicación, según las
utilidades y necesidades de integración que tenga.

Uso combinado de los patrones

• Una misma aplicación puede desplegarse en un pod junto con uno o varios
contenedores secundarios: sidecar para utilidades internas (logging,
métricas), adaptador para conversión de datos y embajador para
comunicaciones externas.
• Según la naturaleza de la lógica de negocio, se pueden activar solo algunos
de estos patrones o todos a la vez, logrando que la aplicación principal quede
enfocada exclusivamente en su lógica de negocio mientras los contenedores
secundarios asumen responsabilidades de soporte.
Arquitectura de Contenerización

Lección 7:
Tecnologías de
contenerización
comunes
Objetivos de la lección

• Docker y Kubernetes son las dos tecnologías de código abierto

más usadas hoy para implementar en la práctica los conceptos
de contenerización vistos (imágenes, contenedores, pods,
orquestación, etc.)
 Docker: el motor pionero
Docker es un motor de contenerización muy
popular que introdujo el modelo de empaquetar
aplicaciones y sus dependencias en
contenedores ligeros y portables, facilitando
despliegue y reproducibilidad.​

Visión arquitectónica de Docker

• Una solución Docker suele describirse en
cuatro áreas: Servidor Docker, Cliente
Docker, Registro Docker y Objetos
Docker (imágenes, contenedores,
volúmenes, redes, etc.).​

• Esta estructura permite construir,

almacenar, distribuir y ejecutar
contenedores de forma estandarizada tanto
en desarrollo como en producción.
 Servidor Docker
• Un servidor Docker (host Docker) es la máquina física o virtual
donde se ejecuta el motor de contenerización Docker, normalmente
sobre sistemas operativos Linux o Windows en arquitecturas como
x86-64 o ARM.

En una solución de contenerización, el servidor Docker:

• Ejecuta el daemon Docker (el motor) que programa, inicia, reinicia y
detiene contenedores, además de gestionar la interacción entre
ellos.
• Hospeda los contenedores y las aplicaciones que corren dentro de
esos contenedores; una solución puede usar uno o varios
servidores Docker.
• Almacena localmente las imágenes usadas por esos contenedores,
permitiendo que múltiples contenedores compartan la misma
imagen base sin duplicarla
Arquitectura de Docker

Un cliente Docker es el componente que usan personas y otros

programas para enviar órdenes al servidor Docker (host donde corre el
daemon).

• Existen dos tipos principales de cliente: una API REST y la CLI (docker)
que se usa en terminal para crear, listar, ejecutar o eliminar
contenedores e imágenes.

• El cliente se comunica siempre con el daemon Docker, que controla el

acceso a los contenedores; puede ejecutarse en Windows, Linux o
Mac, aunque el motor esté en otra máquina.
•
Arquitectura de Docker
 Registro Docker

• Un registro Docker es un repositorio donde se almacenan imágenes Docker

para que los hosts Docker puedan descargarlas y usarlas al desplegar
contenedores.
• Puede guardar muchas imágenes y múltiples versiones de cada una, lo que
permite elegir qué versión usar en cada despliegue; el ejemplo público más
conocido es Docker Hub, y también pueden existir registros privados dentro
de una organización.
• La interacción básica con un registro se realiza con tres comandos: docker
push para subir una imagen, docker pull para descargarla al host y docker
run para crear y arrancar un contenedor a partir de esa imagen
Registro Docker
 OBJETOS DOCKER
En Docker, los objetos Docker son los componentes lógicos que usa la plataforma para
construir, ejecutar y gestionar contenedores en un host.
Contenedor Docker Imágenes Docker Servicios

Es la instancia en ejecución de Son plantillas de solo lectura Incluyen componentes

una imagen de contenedor y es almacenadas en un registro y internos que permiten ejecutar
donde se hospeda la se usan para crear la solución, como el daemon
aplicación. contenedores; por ejemplo, de Docker (motor de
Se puede iniciar, detener, una imagen base de Linux contenerización) y el modo
eliminar o programar para que puede servir para muchos swarm como orquestador de
se ejecute en momentos contenedores distintos. contenedores.
específicos según las Los contenedores pueden Muchos de estos servicios son
necesidades de la solución añadir capas de cambios internos al motor y no se
encima de la imagen base para exponen directamente al
su propia configuración, pero usuario, pero son críticos para
no modifican nunca la imagen programar, gestionar y
base original coordinar contenedores.
 OBJETOS DOCKER
Namespaces Grupos de control (cgroups) Sistema de archivos de
unión (UnionFS)

Proporcionan aislamiento Definen cuántos recursos del Permite crear capas de

entre contenedores que host (CPU, memoria, etc.) lectura y escritura ligeras
comparten el mismo host, puede usar un contenedor, sobre una imagen base de
separando procesos, redes limitando y garantizando el solo lectura, construyendo el
y otros recursos de uso de recursos. sistema de archivos final del
sistema. Gracias a estos controles, contenedor.
Este aislamiento permite varios contenedores pueden De esta forma, múltiples
ejecutar múltiples convivir sin que uno contenedores pueden
contenedores en un mismo consuma en exceso los compartir la misma imagen
servidor de forma segura, recursos del host. base, añadiendo solo sus
evitando interferencias diferencias en capas
entre ellos. superiores
Orquestación con Docker Swarm

Docker Swarm es un orquestador de contenedores que permite crear un

clúster de hosts Docker (swarm) para distribuir carga y mejorar la alta
disponibilidad de las aplicaciones.​

En este modelo:
• El servicio swarm gestiona el clúster y actúa como gestor de clústeres,
permitiendo desplegar múltiples instancias del mismo contenedor en
hosts distintos para que, si un host cae, la aplicación siga disponible.​
• Este enfoque puede usarse tanto en centros de datos privados como
en nubes públicas que ofrecen contenedores como servicio (AWS,
Azure, Google Cloud), donde varios hosts Docker se agrupan y
administran como una única plataforma lógica
Kubernetes: el orquestador empresarial

• Kubernetes, o K8s, es un orquestador de contenedores de código abierto

diseñado para ejecutar aplicaciones contenerizadas a gran escala en
clústeres formados por múltiples hosts.​
Extiende lo que ofrece un motor como Docker al añadir una arquitectura de
nivel empresarial con programación avanzada, autoescalado, alta
disponibilidad y gestión declarativa del estado deseado, lo que lo hace
especialmente adecuado para aplicaciones complejas y sistemas distribuidos
de gran tamaño
 Nodo Kubernetes

Un nodo Kubernetes es el host (físico o virtual) dentro de un clúster Kubernetes

donde realmente se ejecutan los pods y sus contenedores; es, en la práctica, el
equivalente al host Docker en una arquitectura basada solo en Docker.
Cada nodo Kubernetes incluye tres componentes clave:

– kubelet: agente que verifica y asegura que los contenedores definidos

en los pods del nodo estén creados, en ejecución y en el estado
deseado.
– kube-proxy: servicio que gestiona reglas de red en el nodo para permitir
la comunicación interna entre pods y la comunicación externa
hacia/desde el clúster.
– Tiempo de ejecución de contenedores: el motor que ejecuta los
contenedores (por ejemplo, Docker o un runtime compatible con la
interfaz de tiempo de ejecución de contenedor de Kubernetes).
 Kubelet
• Es un agente que corre en cada
nodo y se encarga de que los
contenedores definidos en los pods
del nodo estén creados, arrancados
y funcionando según la
especificación enviada por el plano
de control.
• Supervisa continuamente el estado
de los pods del nodo y reporta al
clúster, reiniciando contenedores
cuando sea necesario para
mantener el estado deseado.
 Kube-proxy

• Es un servicio de red que corre también en cada nodo y actúa como proxy y
balanceador de tráfico para los servicios de Kubernetes.
• Mantiene y aplica reglas de red (por ejemplo, iptables o IPVS) que permiten que los
pods se comuniquen entre sí dentro del clúster y también con el exterior, según la
configuración definida por los administradores.
 Tiempo de ejecución del contenedor

• Es el motor de contenerización que realmente crea y ejecuta los contenedores (por

ejemplo, Docker o runtimes compatibles con la interfaz de tiempo de ejecución de
contenedor, CRI).
• Kubernetes puede usar distintos runtimes, pero todos se integran con el plano de control
mediante la CRI para que los pods se creen, arranquen y gestionen de forma uniforme en
todos los nodos.
 Pod de Kubernetes

• Un pod de Kubernetes es la unidad lógica mínima de despliegue en

Kubernetes y agrupa uno o varios contenedores que siempre se ejecutan
juntos en el mismo nodo.
• Dentro de un pod:
• Los contenedores comparten el mismo namespace de red (IP, puertos) y
pueden compartir volúmenes de almacenamiento, lo que facilita su
comunicación y coordinación.
• También comparten configuración y especificaciones de ejecución (variables
de entorno, límites de recursos, políticas de reinicio), de modo que el pod se
trata como una única entidad a la hora de programarlo y gestionarlo en el
clúster
 KUBERNET Y SWARM

A diferencia del swarm de Docker, el

clúster Kubernetes incorpora un plano
En Kubernetes, un clúster es el
de control más completo (API,
conjunto de nodos que trabajan
scheduler, controladores, etc.) y una
coordinados para ejecutar pods y
arquitectura pensada específicamente
contenedores de forma escalable y
para aplicaciones empresariales y
altamente disponible.
distribuidas de gran escala, no solo
para agrupar hosts.
Plano de control de Kubernetes

• El plano de control de Kubernetes es la parte del clúster que toma

todas las decisiones globales (dónde correr pods, estado deseado,
etc.) y expone la API con la que tú interactúas.​

Qué hace el plano de control

• Centraliza la gestión del clúster: creación de pods, programación en
nodos, detección de fallos, reconciliación del estado deseado vs.
estado real.​
• Suele ejecutarse en uno o varios nodos separados de los nodos de
trabajo, para que un fallo de un worker no afecte la capacidad de
controlar el clúster
 Componentes principales

• API de Kubernetes / kube-apiserver: expone la API REST de Kubernetes para

que kubectl, controladores y otros clientes creen, lean, actualicen y eliminen
objetos del clúster.​
• etcd: almacén clave-valor donde se guarda el estado y la configuración del
clúster (manifiestos, objetos, metadatos), no los datos de las aplicaciones.​
• kube-scheduler: decide en qué nodo se programan los nuevos pods,
revisando recursos disponibles, afinidades, restricciones, etc.​
• kube-controller-manager: agrupa distintos controladores (replicaset, node,
endpoint, etc.) que vigilan el estado y actúan para mantener el estado
deseado.​
• cloud-controller-manager: integra el clúster con la nube (AWS, Azure, GCP,
etc.), gestionando load balancers, IPs, volúmenes, y otros recursos del
proveedor cuando Kubernetes corre sobre una nube pública.​