Kubernetes: qué es y cómo funciona

¿Qué es Kubernetes?

Kubernetes (a menudo abreviado como K8s) es la plataforma de código abierto que se ha convertido en el estándar de facto para la gestión de cargas de trabajo contenedorizadas a escala. Su nombre proviene del griego y significa «timonel» o «piloto» — una imagen apropiada para una herramienta cuyo trabajo es guiar flotas de contenedores a través de infraestructuras heterogéneas.

Creado originalmente por un equipo de ingenieros de Google y donado a la Cloud Native Computing Foundation (CNCF) en 2015, Kubernetes es hoy mantenido por una de las mayores comunidades open-source del mundo. Según la CNCF Annual Cloud Native Survey 2025 (publicada en enero de 2026), el 82% de los usuarios de contenedores utiliza ahora Kubernetes en producción, y el 66% de las organizaciones que ejecutan cargas de trabajo de inteligencia artificial generativa utiliza Kubernetes para gestionar parte o todas sus cargas de trabajo de inferencia.

Para sysadmins y MSPs, la propuesta de valor es directa: un sistema declarativo que reconcilia continuamente el estado deseado de las aplicaciones con su estado real, automatizando todo, desde los despliegues hasta la recuperación. La versión estable más reciente, Kubernetes v1.36 «Haru», fue publicada el 22 de abril de 2026 y confirma la dirección del proyecto hacia un aislamiento más fuerte, soporte para cargas de trabajo de IA y una postura de seguridad más estricta por defecto.

Si te preguntas cómo Kubernetes se relaciona con otras herramientas de contenedores, consulta nuestra guía completa: Docker vs Kubernetes en 2026: en qué se diferencian y cómo trabajan juntos.

Arquitectura de un clúster Kubernetes

Todo despliegue de Kubernetes se organiza como un clúster, que consta de dos capas principales:

• El control plane: el conjunto de componentes que gestionan el estado general del clúster — qué aplicaciones deben estar en ejecución, qué imágenes de contenedor utilizan y cómo se asignan los recursos.
• Los worker nodes: las máquinas (físicas o virtuales) donde las cargas de trabajo contenedorizadas se ejecutan realmente.

Un clúster de nivel producción está diseñado para ser:

• Altamente disponible. El control plane puede replicarse en múltiples máquinas para evitar un único punto de fallo. En producción, la mejor práctica es ejecutar al menos tres nodos de control plane.
• Declarativo. Describes el estado deseado de tu aplicación en archivos de configuración YAML o JSON, y Kubernetes trabaja continuamente para hacer que el estado real coincida con el estado deseado. Estos manifiestos se versionan típicamente en Git, formando la base de un flujo de trabajo GitOps.
• Extensible. Kubernetes no está vinculado a ningún proveedor específico y soporta recursos personalizados, operators y plugins para adaptarse a prácticamente cualquier carga de trabajo.

Nota terminológica: el término «master» utilizado en la documentación más antigua de Kubernetes fue reemplazado en todo el proyecto por «control plane» desde 2020. Si lees guías legacy, considera ambos términos como equivalentes.

Componentes del control plane

El control plane es la capa de toma de decisiones del clúster. Expone la API de Kubernetes, almacena el estado del clúster y ejecuta los controladores que reconcilian el estado deseado con la realidad. En producción, los componentes del control plane se despliegan en al menos tres nodos para garantizar la alta disponibilidad.

kube-apiserver

El servidor API es el punto de acceso central para todas las interacciones con el clúster. Cada comando que ejecutas con kubectl y cada comunicación interna entre componentes pasa a través del servidor API. Valida y procesa las solicitudes RESTful, gestiona la autenticación y el RBAC, y es el único componente que se comunica directamente con etcd. Posteriormente actualiza el estado del clúster en consecuencia.

etcd

etcd es un almacén distribuido y consistente de tipo clave-valor que sirve como la única fuente de verdad para todo el estado del clúster — incluyendo datos de configuración, el estado de nodos y pods, secrets e información de descubrimiento de servicios. Perder etcd significa perder el estado del clúster, razón por la cual realizar backups regulares de etcd y cifrarlo en reposo son requisitos operativos críticos en entornos de producción.

kube-scheduler

El scheduler vigila los pods recién creados que no tienen un nodo asignado y selecciona el mejor nodo para cada pod en función de los requisitos de recursos, las restricciones de hardware, las reglas de afinidad/anti-afinidad, los taints, las tolerations y otras políticas de scheduling.

kube-controller-manager

El controller manager ejecuta un conjunto de bucles de control que monitorizan continuamente el estado del clúster y toman acciones correctivas. Los controladores principales incluyen:

• Node controller: monitoriza el estado de salud de los nodos y responde cuando los nodos se vuelven inalcanzables.
• ReplicaSet controller: asegura que el número deseado de réplicas de pods esté en ejecución en todo momento.
• Endpoint controller: rellena los objetos endpoint que conectan los Services con los pods.
• Job controller: gestiona los pods que se ejecutan hasta su finalización (cargas de trabajo batch).

cloud-controller-manager

El cloud-controller-manager gestiona la integración con el proveedor de nube subyacente: balanceadores de carga, volúmenes persistentes y ciclo de vida de los nodos. Solo está presente en clústeres alojados en la nube y separa la lógica específica de la nube de los controladores principales de Kubernetes.

Componentes de los worker nodes

Cada worker node ejecuta los componentes necesarios para iniciar y gestionar contenedores y reporta el estado al control plane.

kubelet

El kubelet es un agente que se ejecuta en cada nodo. Registra el nodo en el control plane, recibe las especificaciones de los pods del servidor API y asegura que los contenedores descritos en esas especificaciones estén en ejecución y en buen estado. Si un contenedor se cae, el kubelet lo reinicia.

Container runtime

El container runtime es el software responsable de descargar imágenes y ejecutar contenedores. Kubernetes requiere un runtime que implemente la Container Runtime Interface (CRI). Los dos runtimes más utilizados son:

• containerd — el runtime estándar del sector, originalmente extraído de Docker Engine y ahora un proyecto CNCF graduated. Es el runtime predeterminado en la mayoría de los servicios Kubernetes gestionados (EKS, GKE, AKS), en kubeadm y en K3s.
• CRI-O — un runtime ligero construido específicamente para Kubernetes, utilizado por defecto en Red Hat OpenShift.

Nota: Docker Engine era soportado como runtime de Kubernetes a través de un componente llamado dockershim, que fue eliminado en Kubernetes 1.24 (mayo de 2022). Las imágenes Docker siguen siendo plenamente compatibles con todos los runtimes conformes a CRI — solo la interfaz del runtime ha cambiado.

kube-proxy

kube-proxy se ejecuta en cada nodo y gestiona las reglas de red que habilitan la abstracción de los Service. Gestiona el descubrimiento de servicios y el balanceo de carga manteniendo reglas iptables o IPVS que enrutan el tráfico a los endpoints de pod correctos, permitiendo la comunicación hacia tus pods desde dentro y fuera del clúster.

Pods: la unidad desplegable más pequeña

Un pod es la unidad más pequeña que Kubernetes gestiona. Un pod encapsula uno o más contenedores que comparten el mismo namespace de red (dirección IP y puertos), volúmenes de almacenamiento y ciclo de vida. En la mayoría de los casos un pod ejecuta un único contenedor, pero los pods multi-contenedor se utilizan para patrones como sidecars, init containers y recolectores de logs.

En producción, los pods casi nunca se crean directamente. Son gestionados por objetos de nivel superior — Deployments, StatefulSets, DaemonSets — que gestionan réplicas, rolling updates y políticas de scheduling.

Puedes crear un pod sencillo con un manifiesto YAML:

apiVersion: v1
kind: Pod

metadata:

  name: my-nginx

spec:

  containers:

  - name: nginx

    image: nginx:alpine

    ports:

    - containerPort: 80

Apply it with:

$ kubectl apply -f my-nginx.yaml

$ kubectl get pods

Los operadores interactúan con el clúster a través de la herramienta de línea de comandos kubectl, que envía manifiestos YAML declarativos al kube-apiserver.

Cómo funciona todo en conjunto en Kubernetes

Esto es lo que sucede cuando despliegas una aplicación en un clúster Kubernetes:

1. Envías un manifiesto de deployment al servidor API (mediante kubectl apply).
2. El servidor API valida la solicitud y almacena el estado deseado en etcd.
3. El scheduler detecta los nuevos pods sin nodo asignado y selecciona el mejor nodo para cada uno.
4. El kubelet en el nodo seleccionado descarga la imagen del contenedor e inicia el contenedor a través del container runtime.
5. El controller manager monitoriza continuamente el estado en ejecución. Si un pod se cae o un nodo falla, crea pods de reemplazo para coincidir con el estado deseado.
6. kube-proxy actualiza las reglas de red para que el tráfico pueda alcanzar los nuevos pods.

Este bucle de reconciliación se ejecuta continuamente — Kubernetes no solo despliega tu aplicación, la mantiene activamente.

¿Cuáles son las ventajas de Kubernetes en 2026?

La promesa original de Kubernetes — orquestar contenedores en múltiples hosts, automatizar despliegues, gestionar el escalado — sigue vigente. Lo que ha cambiado en 2026 es la madurez y la amplitud de lo que está disponible out of the box.

Infraestructura declarativa y self-healing. Todo el estado deseado del clúster vive en manifiestos YAML, versionados en Git y reconciliados automáticamente. Los pods con errores se reinician, los nodos con errores se drenan, la capacidad se ajusta mediante HPA, VPA y Cluster Autoscaler (o Karpenter en EKS) sin intervención del operador.

Portabilidad de cargas de trabajo. Los mismos manifiestos funcionan en EKS, GKE, AKS, OpenShift, clústeres kubeadm on-premises o K3s en el edge. Ninguna otra plataforma ofrece una portabilidad comparable — un argumento real para los MSPs que gestionan entornos heterogéneos de clientes.

Postura de seguridad moderna. Desde la v1.25, el controlador Pod Security Admission aplica los Pod Security Standards (Privileged, Baseline, Restricted) mediante etiquetas en los namespaces. En la v1.36, los User Namespaces alcanzaron el estado Stable, proporcionando una capa crítica de defensa en profundidad que mapea el root del contenedor a un usuario no privilegiado en el host — una mitigación largamente esperada contra las vulnerabilidades de escape de contenedores.

Cargas de trabajo de IA y ML como ciudadanos de primera clase. La Dynamic Resource Allocation (DRA) alcanzó GA en la v1.34 y ha continuado madurando a lo largo de la v1.36 con funcionalidades adicionales que alcanzaron el estado stable, convirtiendo a Kubernetes en la plataforma estándar para la programación de GPUs, gang scheduling para entrenamiento distribuido y serving de inferencia.

Un ecosistema de servicios gestionados. Amazon EKS, Google GKE y Azure AKS eliminan la carga de gestionar el control plane y se integran nativamente con la identidad en la nube (IRSA, Workload Identity, Entra ID), convirtiéndolos en la opción predeterminada para organizaciones y MSPs sin equipos dedicados de plataforma. Para una comparación detallada, lee nuestro artículo sobre servicios Kubernetes Cloud.

Un ecosistema operativo maduro. Observabilidad (Prometheus, Grafana, OpenTelemetry), GitOps (Argo CD, Flux), backup (Velero), aplicación de políticas (Kyverno, OPA Gatekeeper) y service mesh (Istio, Linkerd, Cilium) son todos proyectos open-source de nivel producción bajo la supervisión activa de la CNCF.

Qué significa esto para sysadmins y MSPs

Kubernetes en 2026 es una plataforma madura, con seguridad reforzada y preparada para la IA — pero una plataforma que exige disciplina operativa continua. El proyecto sigue un ciclo de lanzamiento de cuatro meses y una política de soporte N−2: las ramas soportadas son v1.34, v1.35 y v1.36, mientras que la v1.33 permanece en modo de mantenimiento hasta el fin de su vida útil el 28 de junio de 2026. Posponer las actualizaciones ya no es una estrategia viable, y una migración crítica está ahora en la hoja de ruta de todos — el proyecto comunitario Ingress NGINX ha sido oficialmente retirado desde marzo de 2026, con la Gateway API como sucesora recomendada para la gestión del tráfico.

Para sysadmins y MSPs, el caso operativo se sustenta en tres puntos:

• Infraestructura declarativa que escala sin necesidad de hacer crecer el equipo.
• Portabilidad de cargas de trabajo en cualquier entorno.
• Un ecosistema lo suficientemente maduro para entregar servicios de plataforma a los clientes con márgenes que simplemente no eran posibles hace una década.

Si gestionas clústeres Kubernetes en producción, proteger tus datos es fundamental — especialmente el estado de etcd y los volúmenes persistentes. Uranium Backup soporta el backup de máquinas virtuales, bases de datos y la infraestructura que alimenta tus entornos contenedorizados.

Preguntas frecuentes sobre Kubernetes

¿Cuáles son los principales componentes de Kubernetes?

Kubernetes está compuesto por un control plane (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) y worker nodes que ejecutan kubelet, kube-proxy y un container runtime. El runtime por defecto desde Kubernetes 1.24 es containerd.

¿Cuál es la diferencia entre Docker y Kubernetes?

Docker es una herramienta para construir y ejecutar contenedores individuales. Kubernetes es una plataforma de orquestación que gestiona flotas de contenedores en múltiples hosts, gestionando automáticamente scheduling, escalado, self-healing y rolling updates.

¿Qué versiones de Kubernetes están soportadas en 2026?

A mediados de 2026, las ramas soportadas son v1.34, v1.35 y v1.36 (la última versión estable). Kubernetes sigue una política de soporte N-2 con un ciclo de lanzamiento de 4 meses. La v1.33 alcanza el fin de su vida útil el 28 de junio de 2026.

¿Es Kubernetes adecuado para MSPs?

Sí, particularmente a través de servicios gestionados como Amazon EKS, Google GKE y Azure AKS, que eliminan la carga de gestionar el control plane. La principal ventaja para los MSPs es la portabilidad de las cargas de trabajo: los mismos manifiestos funcionan en diferentes proveedores de nube y entornos on-premises sin cambios.