Services de Kubernetes — conceptos esenciales — Recursos

Proyecto projet11-kubernetes-services · la teoría útil antes (o durante) la práctica.

¿Por qué un Service?

Un Pod es efímero: puede eliminarse, recrearse, moverse a otro nodo — y su dirección IP cambia. Imposible, por tanto, codificar «a pelo» la IP de un Pod.

El Service resuelve este problema: ofrece una dirección estable (IP + nombre DNS) y reparte automáticamente el tráfico hacia el conjunto de Pods que coinciden con su selector de labels.

El enlace Service → Pods no es una IP fija: es un selector de labels. Kubernetes mantiene solo la lista de Pods correspondientes (los Endpoints).

Los tres tipos principales

1. ClusterIP (por defecto)

Dirección IP interna al clúster, inaccesible desde el exterior.
Sirve para la comunicación entre Pods (p. ej. el frontend llama al backend).
Base del descubrimiento de services: alcanzable por nombre DNS (http://demo-clusterip).

2. NodePort

Abre un puerto fijo en cada nodo (rango 30000–32767).
Acceso externo simple: http://<ip-du-noeud>:<nodePort> (aquí http://localhost:30082).
Práctico en dev/local; rara vez se expone tal cual en producción.

3. LoadBalancer

Pide una IP externa a la infraestructura.
En la nube (AWS/GCP/Azure): provisiona un load balancer real.
Con Docker Desktop: el EXTERNAL-IP pasa a ser localhost (http://localhost:8090).

Tabla comparativa

Tipo	Alcance	Acceso	Caso de uso típico
ClusterIP	Interno	Nombre DNS interno	Base de datos, API interna, comunicación Pod↔Pod
NodePort	Externo	`localhost:<30000-32767>`	Demo / dev local
LoadBalancer	Externo	IP pública (localhost en local)	Service público en producción cloud

También existen ExternalName (alias DNS hacia un service externo) y el Ingress (enrutado HTTP/HTTPS por nombre de dominio, visto más adelante) — fuera de este proyecto.

El descubrimiento de services (DNS interno)

Kubernetes ejecuta CoreDNS en el clúster. Cada Service recibe un nombre DNS:

<nom-du-service>                       # desde el mismo namespace
<nom-du-service>.<namespace>           # desde otro namespace
<nom-du-service>.<namespace>.svc.cluster.local   # nombre completo (FQDN)

Así, desde cualquier Pod del mismo namespace:

bash

curl http://demo-clusterip            # resuelto por CoreDNS -> IP del Service -> un Pod

Service y Endpoints

El Service define qué exponer (mediante el selector).
Los Endpoints son la lista real de IP:port de los Pods correspondientes, actualizada automáticamente por Kubernetes.

bash

kubectl get endpoints demo-clusterip   # muestra las IP de los Pods detrás del Service

Si ningún Pod coincide con el selector → Endpoints vacíos → el Service responde «no hay backend» (conexión rechazada).
Es el error n.º 1: un label del Pod que no coincide con el selector del Service.

Para recordar

Un Service = dirección estable + reparto de carga + selector de labels.
ClusterIP (interno, DNS), NodePort (puerto del nodo), LoadBalancer (IP externa).
El descubrimiento de services se hace por nombre DNS gracias a CoreDNS.
Los Endpoints enlazan dinámicamente el Service con sus Pods.

Curso creado por el Dr. Haythem REHOUMA — Desarrollo y despliegue de soluciones de datos