Un Service no es un balanceador magico: el viaje hasta un Pod

Escribes un Service, le das un selector y Kubernetes te devuelve una ClusterIP. Desde fuera parece que el cluster acaba de crear un pequeño balanceador. Pero esa IP no es, en la mayoria de casos, una maquina esperando conexiones. Es una promesa: cuando alguien envie trafico a este destino, el plano de red sabra llevarlo a uno de los pods correctos.

Entender esa diferencia cambia mucho el troubleshooting. Si un Service no responde, reiniciarlo como si fuera un proceso no tiene sentido. Hay que seguir la promesa hasta descubrir en que punto dejo de tener respaldo.

Primero: a quien deberia apuntar

El Service selecciona pods por labels. Si el selector y las etiquetas no coinciden, puedes tener deployments sanos y una puerta sin ningun destino. La primera mirada es muy sencilla:

kubectl get svc api -o wide
kubectl get pods -l app=api --show-labels
kubectl get endpointslices -l kubernetes.io/service-name=api -o wide

Los EndpointSlices son la lista material de destinos que el Service puede usar. Si esta vacia, el misterio no esta en la red entre nodos: todavia no hay endpoints a los que enviar nada. Si aparecen IPs y puertos correctos, la investigacion baja una capa.

Despues: quien mueve el paquete

Kubernetes define el Service, pero algun componente debe implementar su camino. En muchos clusters kube-proxy programa reglas; en instalaciones con Cilium ese trabajo puede vivir en eBPF. No hace falta elegir bando para entender la pregunta: en tu cluster concreto, ¿donde se programa la traduccion de ClusterIP a Pod IP?

Desde un pod temporal se puede separar DNS, conexion y respuesta:

kubectl run caja-red --rm -it --image=curlimages/curl -- sh
nslookup api.default.svc.cluster.local
curl -v http://api.default.svc.cluster.local:8080/health

Si el nombre no resuelve, miras DNS. Si resuelve pero la conexion no abre, miras endpoints, puerto y datapath. Si abre pero devuelve error, probablemente ya estas dentro de la aplicacion. Las capas no eliminan el problema; evitan que lo busques en el lugar equivocado.

La prueba que deja criterio

Un laboratorio util consiste en crear un Service con dos pods, observar sus EndpointSlices y borrar uno mientras repites peticiones. El momento interesante es ver cuanto tarda en desaparecer el endpoint y que observa el cliente durante la transicion. Kubernetes deja de ser una abstraccion fija y se ve como lo que es: controladores actualizando una realidad que cambia.

Fuente: la documentacion oficial explica Services, virtual IPs y EndpointSlices en Service en Kubernetes.