Tema 42: Docker y Kubernetes: contenedores y orquestación de servicios

Contenedores: concepto y virtualización a nivel de sistema operativo

Un contenedor es una unidad estándar de software que empaqueta el código de una aplicación junto con todas sus dependencias (bibliotecas, binarios, ficheros de configuración y entorno de ejecución) de forma que la aplicación se ejecute de manera rápida y fiable en cualquier entorno. Los contenedores son la expresión práctica de la llamada virtualización a nivel de sistema operativo (OS-level virtualization): en lugar de virtualizar el hardware completo, se aíslan procesos que comparten el mismo núcleo (kernel) del sistema operativo anfitrión, empleando mecanismos del propio kernel como namespaces (aislamiento) y cgroups (control de recursos) en Linux.

Esta aproximación contrasta con la virtualización tradicional basada en máquinas virtuales (VM), donde un hipervisor emula hardware y cada VM incluye su propio sistema operativo invitado completo. Al no arrastrar un sistema operativo por cada instancia, el contenedor es mucho más ligero.

Docker

Docker es la plataforma de contenedores más extendida. Es una herramienta de virtualización a nivel de sistema operativo que permite empaquetar y distribuir aplicaciones junto con todas sus dependencias en contenedores. Su objetivo principal es facilitar el despliegue de aplicaciones en contenedores de software, estandarizando el modo en que una aplicación se construye, se distribuye y se ejecuta.

Docker introduce una capa de abstracción entre la aplicación y la infraestructura subyacente. El propósito de esa abstracción es aumentar la portabilidad de las aplicaciones: una imagen de contenedor se ejecuta igual en el portátil del desarrollador, en un servidor de pruebas o en la nube, sin las diferencias de entorno que producen el clásico problema de "en mi máquina funciona".

Ventajas frente a la virtualización tradicional

La principal ventaja de Docker frente a la virtualización tradicional es la eficiencia en el uso de los recursos del sistema. Como los contenedores comparten el kernel del anfitrión y no replican un sistema operativo completo por instancia:

• Consumen menos memoria y CPU que las máquinas virtuales equivalentes.

• Arrancan en segundos (o milisegundos), frente a los minutos de una VM.

• Ocupan menos espacio en disco, al reutilizar capas de imagen comunes.

• Permiten una densidad mucho mayor (más aplicaciones por servidor físico).

Ecosistema de contenerización

Docker no es la única tecnología de contenedores. Entre las tecnologías relacionadas con la contenerización y la gestión de contenedores destacan Docker, containerd y Podman:

• Docker: plataforma completa (CLI, motor y formato de imagen) que popularizó los contenedores.

• containerd: runtime de contenedores de bajo nivel, proyecto de la CNCF, encargado de gestionar el ciclo de vida completo del contenedor (imágenes, ejecución, almacenamiento, red). Es el motor que utiliza internamente Docker y también Kubernetes.

• Podman: motor de contenedores sin demonio (daemonless) y con soporte rootless, compatible con la Open Container Initiative (OCI) y con una interfaz de comandos muy similar a la de Docker.

Todos estos motores se apoyan en los estándares de la OCI (Open Container Initiative), que definen las especificaciones de imagen, de ejecución (runtime) y de distribución, garantizando la interoperabilidad y la portabilidad de las imágenes entre distintas herramientas.

El comando docker run

El comando docker run es la instrucción fundamental de Docker: crea e inicia un nuevo contenedor, descargando la imagen si es necesario, y ejecuta en el contenedor un comando especificado. Formalmente, docker run crea una capa de contenedor escribible sobre la imagen indicada y a continuación la arranca; equivale a encadenar las operaciones de creación (docker create) y de arranque (docker start) del contenedor.

Su sintaxis básica es:

Si la imagen indicada no está disponible localmente, Docker la descarga automáticamente desde el registro (por defecto Docker Hub) antes de crear el contenedor. Es el comando con más opciones de todo Docker, permitiendo configurar red, volúmenes de almacenamiento, variables de entorno, límites de recursos y parámetros de seguridad.

Contenedores en el sistema: Vanilla OS y Apx

La filosofía de contenedores también se aplica al propio sistema operativo. Vanilla OS es una distribución Linux inmutable que gestiona la implementación (instalación) de software mediante contenedores controlados por Apx para reducir conflictos y peligros para el sistema.

Apx es el gestor de paquetes por defecto de Vanilla OS: actúa como envoltorio (wrapper) sobre varios gestores de paquetes e instala el software dentro de uno o más contenedores gestionados, sin alterar el sistema de ficheros raíz. De este modo, el sistema base permanece limpio e inmutable y se minimiza el riesgo de rotura por paquetes incompatibles, mal construidos o en conflicto, a la vez que las aplicaciones contenerizadas siguen pudiendo usar los mismos controladores, servidor gráfico y recursos del sistema. Apx utiliza motores de contenedores como Podman (recomendado) o Docker por debajo.

Fuentes

• Docker Docs — docker container run (CLI reference): https://docs.docker.com/reference/cli/docker/container/run/

• Docker Docs — Running containers: https://docs.docker.com/engine/containers/run/

• Podman — What is Podman? (documentación oficial): https://docs.podman.io/

• containers/Podman — repositorio oficial (OCI, daemonless): https://github.com/containers/podman

• Vanilla OS Documentation — Apx (introducción y funcionamiento): https://docs.vanillaos.org/docs/en/apx

• Vanilla-OS/apx — repositorio oficial: https://github.com/Vanilla-OS/apx

• Open Container Initiative (OCI) — especificaciones de imagen, runtime y distribución: https://opencontainers.org/

Orquestación y microservicios

Qué es la arquitectura de microservicios

La arquitectura de microservicios es un estilo de diseño de software en el que las aplicaciones se descomponen en pequeños servicios independientes que se comunican entre sí mediante API (habitualmente REST/HTTP, gRPC o mensajería asíncrona). Cada uno de estos servicios es autónomo, se despliega por separado y es responsable de una tarea específica o de una capacidad de negocio concreta. Se opone al modelo monolítico, donde toda la funcionalidad reside en un único artefacto desplegable.

Una característica común es, por tanto, que cada servicio es responsable de una tarea específica, con su propio ciclo de vida, su base de datos (patrón database per service) y, con frecuencia, tecnologías heterogéneas.

Ventajas

• Escalabilidad independiente: cada servicio se escala según su demanda sin replicar toda la aplicación.

• Mayor tolerancia a fallos en comparación con la arquitectura monolítica: el fallo de un microservicio puede aislarse (mediante circuit breakers, timeouts, bulkheads) sin derribar el sistema completo.

• Despliegue continuo y ciclos de entrega más cortos por servicio.

• Autonomía tecnológica de los equipos.

Inconvenientes y dificultades

Los microservicios no son una solución ideal para resolver todos los problemas de escalabilidad (afirmación falsa clásica): introducen coste y complejidad que no siempre compensan. Entre las principales dificultades y desventajas destaca la mayor complejidad en el proceso de desarrollo: sistemas distribuidos, comunicación por red, consistencia eventual, observabilidad, gestión de configuración, seguridad entre servicios y necesidad de una robusta automatización (CI/CD y contenedores).

Buenas prácticas de diseño

• Dividir los servicios en función de la lógica de negocio y de las entidades de negocio que manejan (alineados con los bounded contexts del Domain-Driven Design), buscando alta cohesión y bajo acoplamiento. La descomposición por capacidad/entidad de negocio evita servicios anémicos o excesivamente acoplados.

• Diseñar servicios pequeños y autónomos, con contratos de API bien definidos y versionados.

• Automatizar despliegue y pruebas; instrumentar logging, métricas y trazas distribuidas.

Composición: coreografía y orquestación

Las funcionalidades se implementan mediante la composición de varios microservicios. Existen dos estrategias para gestionar esa composición:

• Orquestación: un componente central (el orquestador) coordina y dirige explícitamente las llamadas a los distintos servicios, controlando el flujo del proceso de negocio.

• Coreografía: no hay coordinador central; cada servicio reacciona a eventos publicados por otros (típicamente sobre un bus de eventos), colaborando de forma descentralizada.

Ambas son las dos aproximaciones habituales al patrón Saga para transacciones distribuidas: coreografía y orquestación.

Patrones de infraestructura: gateway y balanceo de carga

• API Gateway: es un componente que actúa como intermediario entre los clientes y los servicios. Ofrece un único punto de entrada y centraliza responsabilidades transversales: enrutamiento, autenticación y autorización, rate limiting, agregación de respuestas, terminación TLS y traducción de protocolos. Evita que el cliente conozca la topología interna de servicios.

• Balanceo de carga (load balancing): es un proceso que permite distribuir la carga de trabajo entre los diferentes servicios (o entre las réplicas de un mismo servicio), mejorando el rendimiento, la disponibilidad y la tolerancia a fallos.

Orquestación de contenedores: Kubernetes

Kubernetes (K8s) es la plataforma de referencia para orquestar contenedores. Fue creado originalmente por Google (inspirado en su sistema interno Borg) y donado en 2015 a la Cloud Native Computing Foundation (CNCF). Su objetivo principal es automatizar el despliegue —así como el escalado y la gestión— de aplicaciones en contenedores.

Plano de control (Control Plane)

El plano de control gobierna el estado del clúster. Sus componentes principales son:

Por tanto, el componente del plano de control responsable de decidir en qué nodo debe ejecutarse un Pod basándose en los recursos disponibles es el kube-scheduler.

Componentes de nodo

En cada nodo worker se ejecutan: el kubelet (agente que garantiza que los Pods y sus contenedores están en ejecución), el kube-proxy (mantiene las reglas de red que implementan los Services) y el runtime de contenedores (containerd, CRI-O, etc.).

Objetos básicos de Kubernetes

Los objetos básicos de Kubernetes son Pod, Service, Volume y Namespace:

• Pod: unidad de despliegue más pequeña; agrupa uno o varios contenedores que comparten red y almacenamiento.

• Service: abstracción que expone un conjunto de Pods bajo una dirección estable y balancea el tráfico entre ellos.

• Volume: mecanismo de almacenamiento asociado a los Pods.

• Namespace: partición lógica del clúster para aislar recursos.

Sobre ellos se construyen objetos de nivel superior (controllers) como Deployment, ReplicaSet, StatefulSet, DaemonSet o Job.

Estructura de un objeto: el campo metadata

Todo objeto de Kubernetes se describe con cuatro campos requeridos: apiVersion, kind, metadata y spec. El campo en el que hay que incluir los valores que permiten identificar unívocamente al objeto es metadata, que contiene entre otros el name, el UID (identificador único asignado por el sistema) y el namespace. Además, spec describe el estado deseado y status (gestionado por el sistema) el estado actual.

Fuentes

• Kubernetes — Components (plano de control y nodos): https://kubernetes.io/docs/concepts/overview/components/

• Kubernetes — Understanding Kubernetes Objects (campos requeridos y metadata): https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/

• Kubernetes — kube-scheduler: https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/

• CNCF / Kubernetes — historia y origen (Google/Borg): https://kubernetes.io/blog/

• Microsoft Learn — Microservices architecture / API Gateway pattern: https://learn.microsoft.com/azure/architecture/microservices/

• Microsoft Learn — Saga pattern (orquestación y coreografía): https://learn.microsoft.com/azure/architecture/reference-architectures/saga/saga