B4-T3: VIRTUALIZACIÓN Y ARQUITECTURA DE CONTENEDORES
Tema de alta densidad técnica. Docker y Kubernetes son los protagonistas absolutos de los últimos exámenes TAI. No basta con saber qué es un contenedor: preguntan instrucciones concretas de Dockerfile, diferencias entre CMD y ENTRYPOINT, puertos por defecto, objetos de Kubernetes. Los microservicios aparecen como patrones (Circuit Breaker, Saga, API Gateway). La virtualización clásica sigue cayendo pero con menos peso.
1. VIRTUALIZACIÓN
1.1 Concepto y tipos de virtualización
La virtualización permite ejecutar múltiples sistemas operativos o entornos aislados sobre un mismo hardware físico. El software que gestiona esta abstracción se denomina hipervisor (hypervisor) o Monitor de Máquina Virtual (VMM).
| Tipo | Descripción | Ejemplo |
|---|
| Virtualización completa | El hipervisor emula el hardware completo; el SO guest no necesita modificarse | VMware, VirtualBox, Hyper-V |
| Paravirtualización | El SO guest se modifica para comunicarse directamente con el hipervisor (hypercalls) | Xen (modo PV) |
| Virtualización asistida por HW | Extensiones del procesador (Intel VT-x, AMD-V) permiten virtualización completa eficiente | KVM, Hyper-V, Xen (modo HVM) |
| Virtualización de SO (contenedores) | Aislamiento a nivel de proceso, comparten el kernel del host | Docker, LXC, Podman |
| Virtualización de aplicaciones | Empaquetan una aplicación con sus dependencias sin instalarla en el SO | App-V, ThinApp |
| Virtualización de escritorio (VDI) | Escritorios virtuales ejecutados en un servidor central, accedidos remotamente | Citrix Virtual Desktops, VMware Horizon |
1.2 Hipervisores: Tipo 1 vs Tipo 2
| Característica | Tipo 1 (bare-metal) | Tipo 2 (hosted) |
|---|
| Se ejecuta sobre | Hardware directamente | Un sistema operativo host |
| Rendimiento | Superior (acceso directo al HW) | Inferior (capa adicional del SO host) |
| Uso típico | Servidores, centros de datos, producción | Desarrollo, pruebas, uso personal |
| Ejemplos | VMware ESXi, Microsoft Hyper-V, Citrix XenServer, KVM, Proxmox VE | VirtualBox (Oracle), VMware Workstation, Parallels, QEMU (sin KVM) |
OJO examen: KVM es Tipo 1 aunque se integre en el kernel Linux. Convierte el propio kernel en hipervisor. Hyper-V también actúa como Tipo 1 incluso en Windows Desktop (se interpone entre el HW y Windows).
1.3 Extensiones de hardware para virtualización
| Tecnología | Fabricante | Función |
|---|
| Intel VT-x | Intel | Virtualización de CPU — modo root/non-root para aislar hipervisor y VMs |
| AMD-V (SVM) | AMD | Equivalente AMD de VT-x |
| Intel VT-d | Intel | Virtualización de E/S — permite asignar dispositivos físicos directamente a VMs (passthrough) |
| AMD-Vi (IOMMU) | AMD | Equivalente AMD de VT-d |
| EPT (Extended Page Tables) | Intel | Traduce direcciones de memoria VM→física sin intervención del hipervisor |
| RVI/NPT (Rapid Virtualization Indexing) | AMD | Equivalente AMD de EPT |
| SR-IOV | PCI-SIG | Permite compartir un dispositivo PCIe (ej. NIC) entre múltiples VMs con acceso directo |
1.4 Formatos de disco virtual
| Formato | Plataforma | Características |
|---|
| VMDK | VMware | Soporta thin/thick provisioning, snapshots, split en múltiples archivos |
| VHD / VHDX | Microsoft Hyper-V | VHD: máx 2 TB. VHDX: máx 64 TB, resiliente a fallos de energía, bloques de 4 KB |
| QCOW2 | QEMU/KVM | Copy-on-write, snapshots internos, compresión, cifrado (AES), thin provisioning nativo |
| VDI | VirtualBox | Formato nativo de VirtualBox, soporta snapshots y dynamic allocation |
| OVF / OVA | Estándar abierto (DMTF) | OVF: directorio con descriptor XML + discos. OVA: OVF empaquetado en un solo archivo TAR. Portabilidad entre plataformas |
| RAW | Universal | Imagen sin formato, máximo rendimiento, sin snapshots ni compresión |
2. CLOUD COMPUTING
2.1 Definición NIST y características esenciales
Según la definición del NIST SP 800-145, cloud computing ofrece acceso ubicuo y bajo demanda a un pool compartido de recursos informáticos configurables. Las 5 características esenciales son:
| Característica | Descripción |
|---|
| Autoservicio bajo demanda | El usuario aprovisiona recursos (CPU, almacenamiento) sin intervención humana del proveedor |
| Acceso amplio a la red | Disponible a través de la red mediante mecanismos estándar (HTTP, API REST) |
| Pool de recursos compartido | Recursos asignados dinámicamente a múltiples consumidores (multi-tenant) |
| Elasticidad rápida | Escalado automático hacia arriba o abajo según la demanda |
| Servicio medido | Monitorización, control y facturación según uso real (pay-per-use) |
2.2 Modelos de servicio
| Modelo | Qué gestiona el proveedor | Qué gestiona el cliente | Ejemplos |
|---|
| IaaS (Infrastructure as a Service) | HW, red, almacenamiento, virtualización | SO, middleware, runtime, apps, datos | AWS EC2, Azure VMs, Google Compute Engine |
| PaaS (Platform as a Service) | Todo lo anterior + SO, middleware, runtime | Aplicaciones y datos | Azure App Service, Google App Engine, Heroku, AWS Elastic Beanstalk |
| SaaS (Software as a Service) | Todo — el usuario solo consume la aplicación | Configuración y datos propios | Microsoft 365, Google Workspace, Salesforce |
| FaaS (Function as a Service) | Todo + escalado automático por función | Solo el código de las funciones | AWS Lambda, Azure Functions, Google Cloud Functions |
| CaaS (Container as a Service) | Orquestación de contenedores | Imágenes de contenedor y configuración | AWS ECS/EKS, Azure AKS, Google GKE |
2.3 Modelos de despliegue
| Modelo | Descripción |
|---|
| Nube pública | Infraestructura del proveedor, compartida entre múltiples organizaciones |
| Nube privada | Infraestructura exclusiva de una organización (on-premise o gestionada por tercero) |
| Nube híbrida | Combinación de pública + privada, con orquestación entre ambas |
| Nube comunitaria | Compartida por organizaciones con intereses comunes (ej. sector sanitario, administración) |
2.4 Principales proveedores y servicios
| Servicio | AWS | Azure | Google Cloud |
|---|
| Cómputo (VMs) | EC2 | Virtual Machines | Compute Engine |
| Contenedores (Kubernetes) | EKS | AKS | GKE |
| Serverless | Lambda | Functions | Cloud Functions |
| Almacenamiento objetos | S3 | Blob Storage | Cloud Storage |
| BBDD relacional | RDS | SQL Database | Cloud SQL |
| BBDD NoSQL | DynamoDB | Cosmos DB | Firestore/Bigtable |
| CDN | CloudFront | Front Door/CDN | Cloud CDN |
| DNS | Route 53 | DNS Zones | Cloud DNS |
| Identidad | IAM | Entra ID (ex AD) | Cloud IAM |
| Monitorización | CloudWatch | Monitor | Cloud Monitoring |
2.5 OpenStack — Componentes principales
OpenStack es la plataforma de nube privada IaaS de código abierto más extendida. Cada componente tiene un nombre en clave:
| Componente | Nombre clave | Función |
|---|
| Cómputo | Nova | Gestión de instancias de VM (equivalente a EC2) |
| Red | Neutron | Networking: redes virtuales, subredes, routers, firewalls |
| Almacenamiento de bloques | Cinder | Volúmenes persistentes para VMs (equivalente a EBS) |
| Almacenamiento de objetos | Swift | Almacenamiento de objetos distribuido (equivalente a S3) |
| Imágenes | Glance | Registro y descubrimiento de imágenes de VM |
| Identidad | Keystone | Autenticación y autorización centralizada |
| Dashboard | Horizon | Interfaz web de administración |
| Orquestación | Heat | Plantillas de infraestructura como código (IaC) |
| Telemetría | Ceilometer | Recolección de métricas y eventos de uso |
| Bare Metal | Ironic | Aprovisionamiento de servidores físicos |
2.6 Nube SARA
La Nube SARA es la infraestructura de nube de la Administración General del Estado (AGE) española, gestionada por la SGAD. Opera sobre la Red SARA y ofrece servicios IaaS y PaaS a las Administraciones Públicas. Certificada según el ENS (categoría ALTA). Tecnología basada en OpenStack y VMware.
3. CONTENEDORES — DOCKER
CLAVE EXAMEN: Docker es el tema más preguntado de este bloque. Esperan que sepas instrucciones de Dockerfile, diferencias CMD vs ENTRYPOINT, comandos docker, el concepto de capas y registros de imágenes. Preguntado en 2019, 2022 y 2024.
3.1 Contenedores vs Máquinas Virtuales
| Característica | Contenedor | Máquina Virtual |
|---|
| Aislamiento | A nivel de proceso (namespaces + cgroups) | A nivel de hardware (hipervisor) |
| Kernel | Comparte el kernel del host | Cada VM tiene su propio kernel |
| Tamaño | Megabytes (imagen base Alpine: ~5 MB) | Gigabytes (SO completo) |
| Arranque | Segundos | Minutos |
| Overhead | Mínimo (comparte kernel) | Significativo (SO completo + hipervisor) |
| Portabilidad | Muy alta (OCI estándar) | Media (depende del formato de disco/hipervisor) |
| Densidad | Cientos por host | Decenas por host |
| Seguridad | Menor aislamiento (kernel compartido) | Mayor aislamiento (HW virtualizado) |
3.2 Tecnologías del kernel Linux para contenedores
| Tecnología | Función |
|---|
| Namespaces | Aíslan la visibilidad: PID (procesos), NET (red), MNT (sistema de ficheros), UTS (hostname), IPC (comunicación entre procesos), USER (usuarios) |
| cgroups (Control Groups) | Limitan y controlan el uso de recursos: CPU, memoria, disco, red |
| Union filesystem | Sistema de archivos por capas (OverlayFS, AUFS): cada capa es de solo lectura excepto la superior (read-write) |
| seccomp | Filtra las llamadas al sistema (syscalls) que un proceso puede hacer |
| capabilities | Descompone los privilegios de root en unidades granulares (CAP_NET_ADMIN, CAP_SYS_PTRACE...) |
3.3 Arquitectura Docker
| Componente | Descripción |
|---|
Docker daemon (dockerd) | Proceso servidor que gestiona imágenes, contenedores, redes y volúmenes. Escucha en socket Unix (/var/run/docker.sock) o TCP |
Docker CLI (docker) | Cliente que envía comandos al daemon vía API REST |
| containerd | Runtime de alto nivel: gestiona ciclo de vida de contenedores, descarga imágenes, gestiona almacenamiento |
| runc | Runtime de bajo nivel OCI: crea y ejecuta contenedores usando namespaces y cgroups del kernel |
| Docker Registry | Almacén de imágenes. Docker Hub (público por defecto), registros privados (Harbor, GitLab Registry, AWS ECR, Azure ACR) |
3.4 Imágenes y capas
Una imagen Docker es una plantilla de solo lectura compuesta por capas apiladas. Cada instrucción del Dockerfile que modifica el filesystem crea una nueva capa. Las capas se comparten entre imágenes (caché), ahorrando espacio y acelerando builds.
| Concepto | Descripción |
|---|
| Capa (layer) | Cada instrucción RUN, COPY, ADD genera una nueva capa de solo lectura |
| Capa R/W | Al ejecutar un contenedor se añade una capa superior de lectura-escritura (efímera) |
| Tag | Etiqueta de versión (ej. nginx:1.25-alpine). latest es el tag por defecto |
| Digest | Hash SHA256 que identifica unívocamente una imagen (inmutable) |
| Multi-stage build | Múltiples FROM en un Dockerfile; se copia solo lo necesario de etapas previas, reduciendo tamaño final |
| Imagen base | scratch (vacía), alpine (~5 MB), debian-slim (~80 MB), ubuntu (~75 MB) |
3.5 Dockerfile — Instrucciones
CLAVE EXAMEN: Preguntan la diferencia CMD vs ENTRYPOINT, qué hace EXPOSE, diferencia COPY vs ADD, y el orden óptimo para aprovechar la caché de capas.
| Instrucción | Función | Ejemplo |
|---|
| FROM | Imagen base (obligatoria, primera instrucción) | FROM python:3.12-slim |
| RUN | Ejecuta un comando durante el build (crea nueva capa) | RUN apt-get update && apt-get install -y curl |
| COPY | Copia archivos del contexto de build a la imagen | COPY ./app /usr/src/app |
| ADD | Como COPY pero además descomprime .tar y acepta URLs | ADD archive.tar.gz /opt/ |
| WORKDIR | Establece el directorio de trabajo para instrucciones siguientes | WORKDIR /usr/src/app |
| ENV | Define variables de entorno persistentes en la imagen | ENV NODE_ENV=production |
| ARG | Variable solo disponible durante el build (no persiste) | ARG VERSION=1.0 |
| EXPOSE | Documenta el puerto que usa el contenedor (NO lo publica, es metadata) | EXPOSE 8080 |
| CMD | Comando por defecto al ejecutar el contenedor. Se puede sobreescribir con docker run ... [cmd] | CMD ["python", "app.py"] |
| ENTRYPOINT | Punto de entrada fijo. Los argumentos de docker run se pasan como parámetros adicionales | ENTRYPOINT ["nginx", "-g", "daemon off;"] |
| VOLUME | Declara un punto de montaje para datos persistentes | VOLUME /var/lib/mysql |
| USER | Establece el usuario (y grupo) para ejecutar el contenedor | USER appuser:appgroup |
| HEALTHCHECK | Define un comando para verificar la salud del contenedor | HEALTHCHECK CMD curl -f http://localhost/ |
| LABEL | Añade metadatos clave=valor a la imagen | LABEL version="2.0" maintainer="admin" |
CMD vs ENTRYPOINT: Si defines ENTRYPOINT + CMD, CMD actúa como argumentos por defecto del ENTRYPOINT. Ejemplo: ENTRYPOINT ["python"] + CMD ["app.py"] → ejecuta python app.py. Si haces docker run img test.py → ejecuta python test.py (CMD sobreescrito).
3.6 Comandos Docker esenciales
| Comando | Función |
|---|
docker build -t nombre:tag . | Construye una imagen desde un Dockerfile en el directorio actual |
docker run -d -p 8080:80 --name mi_web nginx | Ejecuta un contenedor en segundo plano mapeando puertos host:contenedor |
docker ps | Lista contenedores en ejecución (-a incluye parados) |
docker images | Lista imágenes locales |
docker exec -it contenedor bash | Ejecuta un comando interactivo dentro de un contenedor en ejecución |
docker logs contenedor | Muestra la salida estándar/error del contenedor |
docker stop / start / restart | Controla el ciclo de vida del contenedor |
docker rm contenedor | Elimina un contenedor parado (-f fuerza) |
docker rmi imagen | Elimina una imagen local |
docker pull imagen:tag | Descarga imagen de un registro |
docker push imagen:tag | Sube imagen a un registro |
docker volume create / ls / rm | Gestión de volúmenes persistentes |
docker network create / ls | Gestión de redes Docker |
docker inspect contenedor | Muestra información detallada en JSON del contenedor o imagen |
docker system prune | Elimina contenedores parados, redes no usadas, imágenes colgantes y caché de build |
docker tag imagen nueva_imagen:tag | Crea un alias (tag) para una imagen existente |
3.7 Redes en Docker
| Driver | Descripción | Caso de uso |
|---|
| bridge | Red privada interna por defecto. Contenedores se comunican entre sí por IP o nombre (en redes custom) | Contenedores en un solo host |
| host | El contenedor usa directamente la red del host (sin aislamiento de red) | Máximo rendimiento de red |
| none | Sin conectividad de red | Procesamiento offline, seguridad |
| overlay | Red que conecta contenedores en múltiples hosts (requiere Docker Swarm o similar) | Clusters multi-host |
| macvlan | Asigna dirección MAC real al contenedor, aparece como dispositivo físico en la red | Aplicaciones legacy que necesitan IP en la LAN |
3.8 Docker Compose
Docker Compose permite definir y ejecutar aplicaciones multi-contenedor mediante un archivo declarativo docker-compose.yml (o compose.yaml).
| Sección | Descripción |
|---|
| services | Define cada contenedor (imagen, build, ports, volumes, environment, depends_on, networks) |
| volumes | Declara volúmenes con nombre para datos persistentes |
| networks | Define redes personalizadas |
| configs / secrets | Gestión de configuración y secretos |
| Comando Compose | Función |
|---|
docker compose up -d | Inicia todos los servicios en segundo plano |
docker compose down | Para y elimina contenedores, redes (añadir -v elimina volúmenes) |
docker compose ps | Lista el estado de los servicios |
docker compose logs -f servicio | Muestra logs en tiempo real de un servicio |
docker compose build | Reconstruye las imágenes de los servicios |
docker compose exec servicio bash | Abre shell en un servicio en ejecución |
3.9 OCI y alternativas a Docker
La Open Container Initiative (OCI), bajo la Linux Foundation, define los estándares abiertos para contenedores:
| Estándar OCI | Qué define |
|---|
| Runtime Specification | Cómo ejecutar un contenedor (configuración, ciclo de vida, hooks). Implementación de referencia: runc |
| Image Specification | Formato de las imágenes de contenedor (manifiesto, capas, configuración) |
| Distribution Specification | API HTTP para distribuir imágenes (push/pull a registros) |
| Alternativa | Descripción |
|---|
| Podman | Compatible con Docker CLI pero sin daemon (daemonless). Puede ejecutar contenedores rootless. Desarrollado por Red Hat |
| Buildah | Herramienta para construir imágenes OCI sin necesitar un daemon |
| Skopeo | Copia e inspecciona imágenes entre registros sin descargarlas completamente |
| CRI-O | Runtime de contenedores ligero diseñado específicamente para Kubernetes (implementa CRI) |
| LXC/LXD | Contenedores de sistema (parecidos a VMs ligeras), ejecutan un init completo. LXD es la interfaz de gestión |
4. KUBERNETES (K8s)
CLAVE EXAMEN: Kubernetes aparece en los exámenes TAI desde 2022. Preguntan la arquitectura (qué hace cada componente del control plane), los objetos principales (Pod, Deployment, Service, ConfigMap), y comandos kubectl básicos.
4.1 Arquitectura de Kubernetes
Kubernetes (K8s) es un orquestador de contenedores de código abierto, originalmente desarrollado por Google y ahora mantenido por la CNCF (Cloud Native Computing Foundation). Su arquitectura se divide en Control Plane (nodos master) y Data Plane (nodos worker).
| Control Plane (Master) |
|---|
| Componente | Función |
|---|
| kube-apiserver | API REST central de K8s. Toda comunicación pasa por aquí. Valida y procesa peticiones. Puerto 6443 |
| etcd | Base de datos clave-valor distribuida que almacena TODO el estado del cluster. Puerto 2379-2380 |
| kube-scheduler | Decide en qué nodo worker se ejecuta cada nuevo pod (basándose en recursos, afinidad, tolerations) |
| kube-controller-manager | Ejecuta los controladores (loops de reconciliación): ReplicaSet, Node, Endpoint, ServiceAccount |
| cloud-controller-manager | Integra con APIs del proveedor cloud (balanceadores, volúmenes, nodos) |
| Data Plane (Worker Nodes) |
|---|
| Componente | Función |
|---|
| kubelet | Agente en cada nodo worker. Recibe instrucciones del API server y gestiona los pods/contenedores del nodo |
| kube-proxy | Gestiona las reglas de red (iptables/IPVS) para enrutar tráfico a los pods. Implementa el concepto de Service |
| Container Runtime | Ejecuta los contenedores. Debe implementar la CRI (Container Runtime Interface): containerd, CRI-O |
4.2 Objetos principales de Kubernetes
| Objeto | Descripción |
|---|
| Pod | Unidad mínima desplegable. Contiene uno o más contenedores que comparten red (IP) y almacenamiento. Los contenedores del mismo pod se comunican por localhost |
| ReplicaSet | Asegura que un número determinado de réplicas de un pod estén ejecutándose en todo momento |
| Deployment | Gestiona ReplicaSets con actualizaciones declarativas (rolling update, rollback). Es el objeto más usado para desplegar aplicaciones |
| StatefulSet | Como Deployment pero para aplicaciones con estado: identidad de red estable, almacenamiento persistente ordenado (ej. bases de datos) |
| DaemonSet | Asegura que un pod se ejecute en CADA nodo del cluster (ej. agentes de monitorización, log collectors) |
| Job / CronJob | Job: ejecuta tareas hasta completarse. CronJob: las programa periódicamente (sintaxis cron) |
| Service | Abstracción de red que expone un conjunto de pods. IP virtual estable + DNS interno. Tipos: ClusterIP, NodePort, LoadBalancer, ExternalName |
| Ingress | Reglas HTTP/HTTPS de enrutamiento: host/path → Service. Requiere un Ingress Controller (NGINX, Traefik, HAProxy) |
| ConfigMap | Almacena configuración como pares clave-valor. Se inyecta como variables de entorno o archivos montados |
| Secret | Como ConfigMap pero para datos sensibles (contraseñas, tokens). Codificado en Base64 (NO cifrado por defecto) |
| PersistentVolume (PV) | Recurso de almacenamiento aprovisionado por el administrador o dinámicamente |
| PersistentVolumeClaim (PVC) | Solicitud de almacenamiento por parte de un pod. Se enlaza (bind) a un PV |
| Namespace | Partición lógica del cluster para aislar recursos. Namespaces por defecto: default, kube-system, kube-public, kube-node-lease |
| NetworkPolicy | Reglas de firewall a nivel de pod: controlan tráfico ingress/egress |
| HPA (HorizontalPodAutoscaler) | Escala automáticamente el número de pods según métricas (CPU, memoria, custom) |
4.3 Tipos de Service
| Tipo | Descripción | Acceso |
|---|
| ClusterIP | IP virtual interna al cluster (por defecto) | Solo desde dentro del cluster |
| NodePort | Expone el servicio en un puerto estático (30000-32767) en cada nodo | Desde fuera via nodo:puerto |
| LoadBalancer | Aprovisiona un balanceador del proveedor cloud | IP pública externa |
| ExternalName | Mapea un servicio a un nombre DNS externo (CNAME) | Redirección DNS |
4.4 kubectl — Comandos esenciales
| Comando | Función |
|---|
kubectl get pods/svc/deploy/nodes | Lista recursos (-o wide para más detalle, -n namespace para filtrar) |
kubectl describe pod nombre | Información detallada y eventos de un recurso |
kubectl apply -f manifiesto.yaml | Aplica configuración declarativa (crea o actualiza recursos) |
kubectl delete -f manifiesto.yaml | Elimina los recursos definidos en el manifiesto |
kubectl logs pod [-c contenedor] | Muestra logs de un pod (-f para seguir en tiempo real) |
kubectl exec -it pod -- bash | Abre shell interactivo en un pod |
kubectl scale deploy nombre --replicas=5 | Escala un deployment a 5 réplicas |
kubectl rollout status/undo deploy nombre | Verifica estado de un despliegue o hace rollback |
kubectl port-forward pod 8080:80 | Reenvía un puerto local al pod (desarrollo/debug) |
kubectl top pods/nodes | Muestra consumo de CPU y memoria (requiere metrics-server) |
kubectl create namespace nombre | Crea un namespace |
kubectl config use-context nombre | Cambia el contexto activo (cluster + usuario + namespace) |
4.5 Kubernetes como servicio (KaaS)
| Servicio | Proveedor | Notas |
|---|
| EKS (Elastic Kubernetes Service) | AWS | Control plane gestionado. Nodos: EC2 o Fargate (serverless) |
| AKS (Azure Kubernetes Service) | Microsoft | Control plane gratuito. Integración con Azure AD y Azure Monitor |
| GKE (Google Kubernetes Engine) | Google | El más maduro (Google creó K8s). Modo Autopilot (totalmente gestionado) |
| OpenShift | Red Hat | Distribución empresarial de K8s con herramientas adicionales (Source-to-Image, Routes, OperatorHub) |
| Rancher | SUSE | Plataforma de gestión multi-cluster K8s |
| k3s | SUSE/Rancher | K8s ligero para edge/IoT, binario único de ~70 MB |
| Minikube | Kubernetes SIG | K8s local para desarrollo/aprendizaje (un solo nodo) |
5. MICROSERVICIOS
5.1 Concepto: Monolito vs Microservicios
| Aspecto | Monolito | Microservicios |
|---|
| Estructura | Un único proceso/artefacto desplegable | Múltiples servicios independientes, cada uno con su propio proceso |
| Base de datos | Compartida (una BBDD para toda la app) | Database-per-service (cada servicio con su propia BBDD) |
| Despliegue | Todo junto — un cambio requiere redesplegar todo | Independiente — cada servicio se despliega por separado |
| Escalado | Vertical (más HW) o replicar todo | Horizontal y granular (escalar solo el servicio que necesita más recursos) |
| Tecnología | Stack único | Políglota — cada servicio puede usar lenguaje/framework/BBDD diferente |
| Complejidad | Código complejo, operaciones simples | Código simple por servicio, operaciones complejas (red, observabilidad) |
| Fallo | Un fallo puede tumbar toda la aplicación | Fallo aislado al servicio (si hay resiliencia) |
5.2 Comunicación entre microservicios
| Tipo | Patrón | Tecnología | Características |
|---|
| Síncrona | REST (HTTP/JSON) | HTTP 1.1/2 | Simple, universal, con latencia y acoplamiento temporal |
| gRPC | HTTP/2 + Protocol Buffers | Binario, tipado, streaming bidireccional, muy eficiente. Puerto 50051 |
| Asíncrona | Message Queue | RabbitMQ (AMQP, puerto 5672), ActiveMQ | Productor → Cola → Consumidor. Desacoplamiento temporal |
| Event Streaming | Apache Kafka (puerto 9092) | Log distribuido, alto throughput, retención configurable. Ideal para event sourcing |
| Pub/Sub | Redis Pub/Sub, NATS, AWS SNS+SQS | Publicador → Topic → Suscriptores (1:N) |
5.3 Patrones de microservicios
| Patrón | Descripción |
|---|
| API Gateway | Punto de entrada único que enruta peticiones a los microservicios internos. Gestiona autenticación, rate limiting, transformación. Ej: Kong, AWS API Gateway, Spring Cloud Gateway |
| Service Discovery | Registro dinámico de servicios para que se encuentren entre sí sin hardcodear IPs. Server-side: Consul, Eureka, etcd. Client-side: el cliente consulta el registro y elige |
| Service Mesh | Capa de infraestructura con proxies sidecar que gestionan comunicación entre servicios (mTLS, retry, tracing). Ej: Istio (sidecar: Envoy), Linkerd |
| Circuit Breaker | Evita llamadas repetidas a un servicio caído. Estados: CLOSED (normal) → OPEN (fallo, corta llamadas) → HALF-OPEN (prueba). Ej: Resilience4j, Hystrix (deprecated) |
| Bulkhead | Aísla recursos entre servicios para que el fallo de uno no agote los recursos de otros (pools separados) |
| Retry con backoff exponencial | Reintenta peticiones fallidas con tiempos crecientes (1s, 2s, 4s...) + jitter aleatorio para evitar thundering herd |
| Sidecar | Contenedor auxiliar que se despliega junto al servicio principal en el mismo pod, proporcionando funcionalidad cross-cutting (logging, proxy, config) |
| BFF (Backend for Frontend) | Un API Gateway específico para cada tipo de cliente (web, móvil, IoT), adaptando las respuestas |
| Strangler Fig | Patrón de migración gradual: se van reemplazando partes del monolito por microservicios, redirigiendo tráfico progresivamente |
5.4 Patrones de datos
| Patrón | Descripción |
|---|
| Database-per-Service | Cada microservicio tiene su propia BBDD, garantizando autonomía. Otros servicios acceden a datos solo vía API |
| Saga | Transacciones distribuidas sin 2PC: secuencia de transacciones locales con compensaciones si alguna falla. Dos enfoques: coreografía (eventos) o orquestación (coordinador central) |
| CQRS (Command Query Responsibility Segregation) | Separa el modelo de escritura (Command) del de lectura (Query). Permite optimizar cada uno independientemente |
| Event Sourcing | En lugar de guardar el estado actual, se almacenan todos los eventos que lo produjeron. El estado se reconstruye reproduciendo eventos |
| Outbox Pattern | Escribe eventos en una tabla "outbox" de la misma transacción local. Un proceso aparte los publica al broker, garantizando consistencia |
5.5 Observabilidad (los 3 pilares)
| Pilar | Qué mide | Herramientas |
|---|
| Logs | Registro de eventos (texto estructurado) | ELK Stack (Elasticsearch + Logstash + Kibana), Fluentd, Loki (Grafana) |
| Métricas | Datos numéricos agregados en series temporales (CPU, latencia, errores) | Prometheus (recolección pull, puerto 9090) + Grafana (visualización, puerto 3000) |
| Trazas distribuidas | Seguimiento de una petición a través de múltiples servicios | Jaeger, Zipkin, OpenTelemetry (estándar unificado CNCF) |
5.6 Frameworks y herramientas para microservicios
| Herramienta | Lenguaje/Plataforma | Uso |
|---|
| Spring Boot + Spring Cloud | Java | Framework dominante para microservicios Java (gateway, config, discovery, resilience) |
| Quarkus | Java | Framework Java nativo en la nube (GraalVM), arranque ultrarrápido |
| .NET (ASP.NET Core) | C# | Microservicios con middleware integrado, health checks, config distribuida |
| Go (Gin, Echo) | Go | Servicios ligeros con alto rendimiento y baja huella de memoria |
| Node.js (Express, Fastify, NestJS) | JavaScript/TS | Microservicios ligeros, event-driven, ideal para I/O intensivo |
6. CI/CD Y DESPLIEGUE DE CONTENEDORES
6.1 Pipeline CI/CD típico
| Fase | Descripción | Herramientas |
|---|
| Source | Commit al repositorio dispara el pipeline | Git, GitHub, GitLab, Bitbucket |
| Build | Compilación del código + construcción de imagen Docker | Maven, Gradle, npm, docker build, Kaniko |
| Test | Tests unitarios, integración, seguridad (SAST/DAST) | JUnit, Jest, SonarQube, Trivy |
| Registry | Push de la imagen al registro de contenedores | Docker Hub, Harbor, ECR, ACR, GCR |
| Deploy | Despliegue al entorno (dev/staging/prod) | kubectl apply, Helm, ArgoCD, Flux |
| Monitor | Observabilidad post-despliegue | Prometheus, Grafana, Datadog, ELK |
6.2 Estrategias de despliegue
| Estrategia | Descripción | Riesgo |
|---|
| Rolling Update | Reemplaza pods gradualmente (por defecto en K8s Deployments) | Bajo — siempre hay pods activos |
| Blue/Green | Dos entornos idénticos; se cambia el tráfico del blue (actual) al green (nuevo) de golpe | Bajo — rollback inmediato |
| Canary | Se envía un % pequeño de tráfico a la nueva versión; si va bien, se escala al 100% | Muy bajo — afecta a pocos usuarios |
| Recreate | Se para todo y se despliega la nueva versión (downtime) | Alto — hay interrupción |
| A/B Testing | Diferentes versiones para diferentes usuarios (basado en headers, cookies, geolocalización) | Bajo — controlado por reglas |
6.3 GitOps
GitOps es un paradigma donde Git es la fuente única de verdad para la configuración de infraestructura y aplicaciones. Un operador (ej. ArgoCD, Flux) observa el repositorio y sincroniza automáticamente el estado del cluster con lo declarado en Git.
| Herramienta | Descripción |
|---|
| Helm | Gestor de paquetes de Kubernetes. Los charts son plantillas parametrizadas de manifiestos YAML (values.yaml). Repositorio central: Artifact Hub |
| ArgoCD | Operador GitOps para K8s: monitoriza un repo Git y aplica cambios automáticamente al cluster. UI web incluida |
| Flux | Operador GitOps alternativo (CNCF graduated). Más ligero, sin UI nativa |
| Kustomize | Personalización de manifiestos YAML sin templates (integrado en kubectl) |
| Terraform | IaC para aprovisionar infraestructura cloud (no específico de K8s pero complementario) |
FUENTES PÚBLICAS
Este resumen ha sido elaborado íntegramente a partir de fuentes de dominio público. No se ha utilizado material con copyright de terceros ni material de preparadores.
| Fuente | Tipo | Referencia |
|---|
| Documentación de Docker | Documentación oficial | docs.docker.com |
| Documentación de Kubernetes | Documentación oficial | kubernetes.io/docs (Apache 2.0) |
| KVM documentation | Documentación oficial | linux-kvm.org |
| OCI — Open Container Initiative | Estándar | opencontainers.org |