En este tema daremos nuestros primeros pasos en Kubernetes (a menudo abreviado como K8s), el orquestador de contenedores más utilizado del mundo. Aunque Docker resuelve magníficamente la construcción y ejecución de contenedores en una máquina, gestionar aplicaciones distribuidas, resilientes y a gran escala requiere una capa adicional. Kubernetes proporciona esa capa: un sistema declarativo y automatizado para desplegar, escalar y operar aplicaciones en contenedores sobre clústeres de servidores. Comprender sus fundamentos es esencial para cualquier profesional que vaya a trabajar con contenedores en producción.

• Entender qué problemas resuelve Kubernetes frente a usar Docker en solitario.
• Conocer la arquitectura de Kubernetes: control plane y nodos.
• Identificar los objetos básicos: Pod, ReplicaSet, Deployment y Service.
• Comprender la relación entre las imágenes Docker y Kubernetes.
• Familiarizarte con los comandos básicos de kubectl.

Con Docker puedes construir imágenes y ejecutar contenedores, e incluso coordinar varios con Docker Compose. Sin embargo, cuando llevas una aplicación a producción surgen necesidades que Docker por sí solo no cubre:

• Auto-reparación: si un contenedor falla, ¿quién lo reinicia automáticamente?
• Escalado dinámico: ¿cómo aumentas las réplicas según la carga, en varios servidores a la vez?
• Balanceo de carga: ¿cómo repartes el tráfico entre muchas instancias?
• Despliegues sin cortes: ¿cómo actualizas la versión sin dejar de servir peticiones?
• Gestión declarativa: ¿cómo describes el estado deseado y dejas que el sistema lo mantenga?

Kubernetes responde a todas estas preguntas. Su filosofía es declarativa: tú describes el estado que deseas (por ejemplo, "quiero 5 réplicas de esta aplicación") y Kubernetes trabaja continuamente para que la realidad coincida con esa descripción.

Un clúster de Kubernetes se divide en dos grandes partes: el control plane (plano de control) y los nodos de trabajo (worker nodes).

El control plane es el cerebro del clúster. Toma decisiones globales y mantiene el estado deseado. Sus componentes principales son:

• kube-apiserver: la puerta de entrada al clúster; todas las órdenes (incluidas las de kubectl) pasan por aquí.
• etcd: base de datos clave-valor que almacena todo el estado del clúster.
• kube-scheduler: decide en qué nodo se ejecuta cada Pod.
• kube-controller-manager: ejecuta los controladores que vigilan el estado y lo corrigen (por ejemplo, recrear Pods caídos).

Los nodos son las máquinas donde realmente se ejecutan las aplicaciones. Cada nodo contiene:

• kubelet: agente que se comunica con el control plane y se asegura de que los contenedores definidos en los Pods estén en ejecución.
• kube-proxy: gestiona las reglas de red para que los Services funcionen.
• Runtime de contenedores: el motor que ejecuta los contenedores (por ejemplo, containerd).

Kubernetes gestiona la aplicación mediante "objetos" declarativos. Estos son los fundamentales:

El Pod es la pieza más pequeña que Kubernetes despliega. Lo habitual es que contenga un solo contenedor, pero puede agrupar varios que deban ejecutarse juntos. Los Pods son efímeros: si uno muere, se crea otro nuevo (con otra IP), por lo que rara vez se gestionan directamente.

Un ReplicaSet asegura que siempre exista el número deseado de Pods idénticos. Si uno falla, lo recrea. Normalmente no lo creas tú directamente, sino a través de un Deployment.

El Deployment es el objeto que usarás en el día a día para aplicaciones sin estado. Gestiona los ReplicaSets por ti y permite actualizar la versión de la imagen de forma progresiva, así como deshacer cambios (rollback).

Como los Pods cambian de IP constantemente, el Service ofrece un punto de acceso estable (un nombre y una IP virtual) y reparte el tráfico entre los Pods que cumplan un determinado selector de etiquetas.

Un punto clave para quien viene de Docker: Kubernetes no construye imágenes. Kubernetes consume las imágenes que tú construiste y publicaste con Docker en un registro. El flujo es:

1. Construyes la imagen con docker build.
2. La publicas en un registro con docker push (Docker Hub, GHCR, etc.).
3. En el manifiesto de Kubernetes, referencias esa imagen por su nombre y etiqueta.
4. Kubernetes descarga (pull) la imagen y la ejecuta dentro de los Pods.

Es decir, las imágenes Docker son el artefacto; Kubernetes es quien las orquesta. Por eso todo lo aprendido sobre Dockerfile, etiquetado y registros sigue siendo plenamente válido.

kubectl es la herramienta de línea de comandos para interactuar con el clúster. Estos son los comandos esenciales:

Explicación de cada comando:

• kubectl get nodes: lista las máquinas que forman el clúster y su estado.
• kubectl get pods: muestra los Pods en ejecución, cuántas réplicas están listas y reinicios.
• kubectl describe pod ...: ofrece detalles completos de un objeto, incluidos eventos útiles para diagnosticar problemas.
• kubectl logs ...: muestra la salida (stdout/stderr) del contenedor de un Pod.
• kubectl apply -f ...: aplica un fichero YAML; crea los objetos si no existen o los actualiza si ya existían (modelo declarativo).
• kubectl delete -f ...: elimina los objetos descritos en el fichero.

• Gestionar Pods a mano: los Pods son efímeros; usa Deployments para que Kubernetes los mantenga por ti.
• Esperar que Kubernetes construya imágenes: no lo hace; debes construirlas y publicarlas con Docker primero.
• Usar latest en los manifiestos: dificulta saber qué versión se ejecuta y los rollbacks. Usa etiquetas concretas.
• Olvidar el namespace: muchos objetos viven en namespaces; si no ves algo, comprueba en cuál estás (kubectl get pods -A).
• Confundir Service con Deployment: el Deployment ejecuta los Pods; el Service les da una dirección estable. Casi siempre necesitas ambos.
• No leer los eventos: kubectl describe muestra eventos que suelen explicar por qué un Pod no arranca.

Explica con tus palabras la diferencia entre el control plane y los nodos de trabajo, indicando al menos un componente de cada uno y su función.

Ordena de menor a mayor nivel de abstracción los siguientes objetos y describe brevemente cada uno: Deployment, Pod, ReplicaSet.

Describe el flujo completo desde que tienes el código fuente de una aplicación hasta que Kubernetes ejecuta su imagen, indicando qué parte corresponde a Docker y qué parte a Kubernetes.

Solución al Ejercicio 1:

El control plane es el cerebro del clúster: toma decisiones y mantiene el estado deseado. Un componente clave es el kube-apiserver, que es el punto de entrada de todas las órdenes. Los nodos de trabajo son las máquinas donde se ejecutan las aplicaciones; un componente clave es el kubelet, que se asegura de que los contenedores definidos en los Pods estén realmente en ejecución.

Solución al Ejercicio 2:

De menor a mayor abstracción: Pod → ReplicaSet → Deployment.

• Pod: unidad mínima; envuelve uno o varios contenedores.
• ReplicaSet: mantiene un número fijo de Pods idénticos en ejecución.
• Deployment: gestiona ReplicaSets y añade actualizaciones progresivas y rollbacks.

Solución al Ejercicio 3:

1. Escribes el código y un Dockerfile.
2. Construyes la imagen con docker build (Docker).
3. Publicas la imagen en un registro con docker push (Docker).
4. Defines un manifiesto YAML que referencia esa imagen (Kubernetes).
5. Aplicas el manifiesto con kubectl apply (Kubernetes).
6. Kubernetes descarga la imagen y la ejecuta dentro de Pods (Kubernetes).

Docker se encarga de construir y publicar el artefacto; Kubernetes se encarga de orquestar su ejecución.

En este tema hemos comprendido qué problemas resuelve Kubernetes frente a Docker en solitario, su arquitectura de control plane y nodos, y sus objetos básicos: Pod, ReplicaSet, Deployment y Service. También hemos visto que Kubernetes no sustituye a Docker, sino que orquesta las imágenes que construyes con él, y hemos conocido los comandos esenciales de kubectl. Con estos fundamentos claros, estamos listos para pasar a la práctica: en el próximo tema, Desplegando Contenedores Docker en Kubernetes, escribiremos manifiestos reales y desplegaremos una aplicación paso a paso.