A la lliçó anterior vam actualitzar api-reserves sense tallar el servei, però per comprovar que responia vam haver de buscar a mà la IP d'un pod concret i confiar que continués existint cinc segons després. Aquest és el forat que ens queda: cada desplegament, cada autoreparació i cada escalat canvien les IPs dels pods, així que cap component no pot conèixer un altre per la seva adreça. El Service és la resposta de Kubernetes: una adreça virtual estable, amb nom propi, que reparteix el trànsit entre totes les rèpliques sanes d'un component i sobreviu al fet que els pods de darrere vagin i vinguin. En aquesta lliçó entendràs el problema en profunditat, veuràs què és exactament un Service i com el controlador d'endpoints manté actualitzada la llista de destins, llegiràs el manifest camp per camp distingint port de targetPort, crearàs els quatre Serveis de Rutas Norte —botiga-web, api-reserves, postgres-reserves i redis-cache—, els verificaràs des de dins del clúster amb pods efímers i aprendràs a diagnosticar la fallada més freqüent de tot Kubernetes: un selector que no encaixa amb les etiquetes dels pods.

1. El problema: IPs efímeres
2. Què és un Service i què et dona
3. Endpoints i EndpointSlices: qui manté la llista
4. Anatomia del manifest: port, targetPort, protocol
5. Per què ClusterIP és el tipus per defecte
6. Els Serveis de Rutas Norte
7. Verificació des de dins del clúster
8. El nom DNS i els serveis headless
9. La fallada més comuna: el selector que no encaixa

Fem visible el problema amb un experiment de trenta segons. Apunta les IPs actuals d'api-reserves:

Ara provoca un desplegament qualsevol i torna a mirar:

Noms nous, IPs noves. Si botiga-web tingués escrita a la seva configuració l'adreça 10.244.0.48, acabaria de perdre la connexió amb l'API. I els moments en què això passa són constants:

I hi ha un segon problema, tan important com el primer: el repartiment de càrrega. Encara que congeléssim les IPs, botiga-web hauria de conèixer les dues, tres o set rèpliques d'api-reserves i repartir el trànsit entre elles pel seu compte, comprovant quines estan sanes. Això és reinventar un balancejador dins de cada client.

Rutas Norte necessita tres coses de cop:

1. Una adreça que no canviï mai, encara que els pods de darrere canviïn tots.
2. Repartiment automàtic del trànsit entre les rèpliques disponibles.
3. Un nom, no una IP, per no haver de configurar adreces enlloc.

Un Service és un objecte de Kubernetes que defineix un punt d'accés lògic i estable a un conjunt de pods, seleccionats per etiquetes.

El que aporta, punt per punt:

• Una IP virtual estable, la ClusterIP. S'assigna en crear el Service i no canvia mentre el Service existeixi, independentment de quants pods hi hagi al darrere o de si n'hi ha zero.
• Un nom DNS, que és el que realment faràs servir: api-reserves des del mateix namespace.
• Balanceig de càrrega entre tots els pods sans que encaixin amb el selector, per defecte aleatori.
• Actualització automàtica de destins: quan un pod neix, hi entra; quan mor o deixa d'estar llest, en surt. Sense intervenció humana.
• Un port lògic que pot ser diferent del port real del contenidor.

Un detall que descol·loca al principi: la ClusterIP no pertany a cap màquina. No hi ha cap interfície de xarxa configurada amb aquella adreça, no respon a ping i no li pots fer ssh. És una adreça virtual que existeix únicament com a regla de reenviament instal·lada a cada node del clúster. Quan un pod envia un paquet a 10.96.184.22, aquella regla el reescriu al vol cap a la IP real d'un dels pods de destí.

Qui instal·la aquestes regles i com (iptables, IPVS, eBPF) és matèria de Xarxes de Clúster. Per a aquesta lliçó n'hi ha prou amb el model mental: el Service és una regla de reenviament amb nom, no una màquina.

Un advertiment sobre el balanceig, perquè genera confusió: el repartiment es fa per connexió, no per petició. Si un client obre una connexió HTTP persistent (keep-alive) o gRPC contra la ClusterIP, totes les peticions d'aquella connexió acaben al mateix pod. És un comportament normal i previsible, però convé conèixer-lo abans de sorprendre's perquè el trànsit "no es reparteix".

El Service, per si sol, no sap res de pods. Només declara un selector. Qui fa la feina bruta és un altre controlador del kube-controller-manager: el controlador d'endpoints.

El seu bucle de reconciliació, que a hores d'ara ja et resulta familiar:

1. Llegeix el selector del Service.
2. Busca els pods del namespace que encaixen amb aquelles etiquetes.
3. D'aquests, selecciona els que estan llestos (Ready).
4. Escriu la llista de les seves IPs i ports en un objecte EndpointSlice associat al Service.

El punt crucial, i la raó que existeixin les sondes: només entren a la llista els pods llestos. Un pod que arrenca, un que està acabant o un la readinessProbe del qual falla queda fora i no rep trànsit. Aquest és el mecanisme exacte que fa possibles els desplegaments sense tall de la lliçó anterior, i també la peça que encara ens falta fins a Verificacions de Salut i Sondes.

Històricament aquesta llista vivia en un objecte Endpoints (un per Service, amb totes les adreces a dins). En clústers grans, un Service amb milers de pods generava un objecte enorme que es reenviava sencer a tots els nodes cada cop que canviava una sola IP. Per això des de Kubernetes 1.21 el mecanisme real són els EndpointSlice: fragments de fins a 100 adreces cadascun.

A la pràctica continuaràs fent servir kubectl get endpoints per diagnosticar perquè la seva sortida és més compacta i llegible, i Kubernetes el manté sincronitzat. Només recorda que per sota són EndpointSlices.

Primer Service del projecte, el d'api-reserves:

Camp per camp:

• apiVersion: v1: el Service pertany al grup core, com el Pod. No porta apps/.
• metadata.name: api-reserves: importantíssim, perquè el nom del Service és el nom DNS. http://api-reserves:3000 funcionarà gràcies a aquesta línia.
• spec.type: ClusterIP: és el valor per defecte; l'escrivim explícit per claredat. La resta de tipus, a Tipus de Serveis.
• spec.selector: quins pods hi ha al darrere. Aquí no hi ha matchLabels: el selector d'un Service és un mapa pla d'igualtat, més simple que el d'un Deployment. I un advertiment que desenvoluparem a l'apartat 9: aquestes etiquetes han de coincidir amb les dels pods, és a dir, amb spec.template.metadata.labels del Deployment, no amb les del Deployment en si.
• ports[].name: http: obligatori si hi ha més d'un port, recomanable sempre.
• ports[].port: 3000: el port del Service. És al qual es connecten els clients: api-reserves:3000.
• ports[].targetPort: http: el port del pod al qual es reenvia. Aquí fem servir el nom del port declarat al contenidor.
• ports[].protocol: TCP: per defecte TCP. També admet UDP i SCTP.

És la confusió número u amb els Serveis. La regla és simple:

port és per on entra el trànsit al Service. targetPort és per on surt cap al pod.

No han de ser iguals per força, i sovint no ho són. Un cas molt habitual a Rutas Norte:

Així botiga-web pot cridar http://api-reserves sense especificar port, mentre l'aplicació continua escoltant on li convé.

Compara les dues maneres d'apuntar al pod:

La segona és clarament superior, i és la que adopta el projecte. Avantatges:

• Desacobla el Service del contenidor. Si demà api-reserves passa a escoltar al 8080, n'hi ha prou amb canviar el containerPort al Deployment; el Service continua sent vàlid sense tocar-hi ni una línia.
• Permet un Service comú a pods heterogenis. Pods diferents poden exposar el port http en números diferents i el mateix Service els serveix tots.
• Es documenta sol. targetPort: metrics diu més que targetPort: 9090.

Requisit per poder-la fer servir: el contenidor ha de declarar el port amb nom. El nostre Deployment ja ho fa:

Compte amb una asimetria que confon: port no admet nom, només número. El nom només val per a targetPort.

Kubernetes ofereix quatre tipus de Service. Aquesta lliçó se centra en ClusterIP; la resta es tracten en detall a Tipus de Serveis.

Que ClusterIP sigui el valor per defecte no és casualitat: és una decisió de disseny alineada amb el principi de mínim privilegi. Un component no hauria de ser accessible des de fora tret que algú ho decideixi explícitament.

Aplicat als sis components de Rutas Norte:

Fixa't que fins i tot els components públics fan servir ClusterIP. L'exposició a l'exterior la farà un únic Controlador d'Ingress que enruta per domini cap a aquests Serveis interns: una sola porta d'entrada, un sol lloc on acabar el TLS i aplicar regles.

I fixa't també que dos components no porten Service en absolut. Un Service només és necessari si algú ha d'iniciar connexions cap al component. worker-notificacions consumeix una cua i parla amb PostgreSQL, però ningú no el crida a ell.

Donarem adreça estable a la plataforma. Comencem pel que ja tenim escrit:

Aquí hi ha la IP virtual: 10.96.184.22. No canviarà mai mentre existeixi el Service.

Encara no hem desplegat PostgreSQL —necessita emmagatzematge persistent i arribarà al mòdul 5—, però podem deixar preparat un Deployment provisional d'una rèplica per practicar la connectivitat. El Service és el que ens interessa:

I el Deployment provisional, amb una contrasenya que de moment va en clar. És una mala pràctica deliberada i temporal: es corregeix a Secrets.

Aplica-ho tot i contempla el resultat:

Quatre adreces estables per a la plataforma Rutas Norte. A partir d'ara, cap component no torna a conèixer una IP de pod.

Abans de provar trànsit, verifica sempre que el Service ha trobat pods:

Aquella columna ENDPOINTS és la dada més valuosa del diagnòstic de Serveis: són les IPs reals a les quals es reenviarà el trànsit. Tres pods de botiga-web, dos d'api-reserves, un de cada base de dades. Exactament el que esperàvem.

La vista moderna, en EndpointSlices:

Fem servir la tècnica de la lliçó de Pods. Fixa't que ara no necessitem esbrinar cap IP:

Hem cridat l'API pel seu nom. Aquell http://api-reserves:3000 és exactament la cadena de connexió que anirà a la configuració de botiga-web, i no canviarà mai.

Aquí és on ens serveix haver inclòs el nom del pod a la resposta de l'API:

Vuit peticions repartides entre les dues rèpliques. El repartiment és aleatori, no estrictament altern: no esperis una distribució perfecta en poques peticions.

La prova definitiva. Escala, torna a desplegar i torna a cridar:

La ClusterIP continua sent 10.96.184.22. Els quatre endpoints són IPs completament noves. Aquest és el contracte del Service en una línia: l'adreça de fora no canvia mai, la llista de dins s'actualitza sola.

Els quatre components són assolibles pel nom des de qualsevol punt del clúster. La plataforma ja té sistema circulatori.

Torna a 2 rèpliques abans de continuar:

Cada Service obté automàticament un registre DNS amb aquesta forma:

Per a la nostra API: api-reserves.rutas-norte-dev.svc.cluster.local. I com que el DNS del clúster configura sufixos de cerca a cada pod, des de rutas-norte-dev pots fer servir qualsevol d'aquestes formes:

Comprova-ho:

El nom resol a la ClusterIP, no a les IPs dels pods. El funcionament intern de CoreDNS, els sufixos de cerca, els registres SRV i la resolució entre namespaces s'estudien a fons a DNS Intern i Descobriment de Serveis.

Existeix una variant que convé conèixer encara que no la fem servir de moment: un Service amb clusterIP: None, anomenat headless.

El seu comportament és diferent: no té IP virtual i no balanceja res. En comptes d'això, el DNS retorna directament les IPs de tots els pods que encaixen amb el selector.

Per a què serveix: quan un client necessita adreçar-se a una rèplica concreta en lloc de a "qualsevol". És el cas d'un clúster de PostgreSQL on cal escriure al primari i llegir de les rèpliques, o de Kafka, o de qualsevol sistema amb quòrum. Per això els headless van gairebé sempre de la mà dels StatefulSets: la combinació dona a cada rèplica un nom DNS propi i estable com ara postgres-reserves-0.postgres-reserves.rutas-norte-dev.svc.cluster.local.

Quan al mòdul 6 convertim postgres-reserves en un StatefulSet, el seu Service passarà a ser headless. Els detalls, a DNS Intern i StatefulSets.

Si haguessis de memoritzar una sola cosa d'aquesta lliçó, que sigui aquesta. L'avaria número u amb Serveis a Kubernetes és un selector que no coincideix amb les etiquetes dels pods. I és especialment traïdora perquè no produeix cap error: el Service es crea sense protestar, obté la seva ClusterIP, apareix a kubectl get svc amb un aspecte perfectament sa... i no reenvia trànsit enlloc.

Aspecte impecable. Però:

Quatre passos, sempre en aquest ordre.

Pas 1: té endpoints? És la pregunta que resol el 80 % dels casos.

<none>. El Service no ha trobat ni un sol pod. Confirmat: el problema és al selector o a les etiquetes, no a la xarxa ni a l'aplicació.

Pas 2: quin selector té el Service?

Pas 3: quines etiquetes tenen els pods?

Pas 4: comparar. app=api-reserve enfront de app=api-reserves. Aquí hi ha l'essa que falta.

La prova definitiva és fer servir el selector del Service com a filtre de kubectl: si no retorna pods, el Service tampoc no els trobarà.

Quan ENDPOINTS és buit o incomplet, la causa és sempre en aquesta taula:

De totes elles, la segona és la més subtil i la que fa perdre més temps. Mira aquest Deployment:

Un Service amb selector: {app: api-reserves-deploy} no trobarà res, perquè aquella etiqueta la porta el Deployment, que no és un pod. El Service selecciona pods, sempre. La convenció de Rutas Norte —fer servir les mateixes tres etiquetes al Deployment i al template— evita aquest error per construcció.

Si ENDPOINTS té adreces però la connexió no funciona, el problema és més avall:

Si el pod respon per IP directa però no pel Service, mira el targetPort. Si no respon ni per IP directa, el problema és l'aplicació, no Kubernetes.

I un últim advertiment que estalvia hores: si la teva aplicació escolta a 127.0.0.1 en lloc de a 0.0.0.0, només es respon a si mateixa. El Service tindrà endpoints correctes i tot i així totes les connexions fallaran. És una fallada de configuració de l'aplicació que sembla una fallada de Kubernetes.

• Selector que no encaixa amb les etiquetes dels pods. La fallada número u. El Service es crea sense error i no serveix res. Diagnòstic: kubectl get endpoints.
• Apuntar el selector a les etiquetes del Deployment. Els Services seleccionen pods: les etiquetes rellevants són les de spec.template.metadata.labels.
• Confondre port amb targetPort. port és on escolta el Service; targetPort, on escolta el contenidor.
• Fer servir un nom a port. Només targetPort admet noms. port és sempre numèric.
• Esperar que un Service arribi a pods d'un altre namespace. No ho fa: només selecciona al seu. Per creuar, es fa servir el nom DNS complet, com veurem a Namespaces.
• Que l'aplicació escolti a 127.0.0.1. Ha d'escoltar a 0.0.0.0 per ser assolible des de fora del contenidor.
• Crear un Service per a worker-notificacions. No rep connexions entrants; un Service sense clients és soroll i superfície d'atac innecessària.
• Esperar un repartiment perfectament altern. El balanceig és aleatori per connexió, no per petició. Amb keep-alive, totes les peticions d'una connexió van al mateix pod.
• Fer ping a una ClusterIP. No respon: és una regla de reenviament, no una interfície. Fes servir curl o nc al port del Service.
• Consell: el diagnòstic de Serveis comença sempre per kubectl get endpoints <nom>. Buit significa problema de selector o d'etiquetes; amb adreces, problema de ports o d'aplicació.
• Consell: fes servir sempre targetPort pel nom. Desacobla el Service del contenidor i t'estalvia un canvi cada cop que l'aplicació mogui el seu port.
• Consell: per a una prova ràpida sense escriure manifests, kubectl expose deployment api-reserves --port=3000 --target-port=http --dry-run=client -o yaml genera un Service correcte que pots revisar i desar.

1. Aplica el Service de botiga-web d'aquesta lliçó i comprova que té 3 endpoints.
2. Des d'un pod efímer, fes 6 peticions a http://botiga-web/ i verifica que respon nginx.
3. Apunta la ClusterIP, escala el Deployment a 5 rèpliques, torna a desplegar-lo amb rollout restart i demostra amb dues ordres que la ClusterIP no ha canviat i que els endpoints sí.
4. Explica per què el Service fa servir port: 80 i targetPort: http en lloc de targetPort: 80.

Un company ha aplicat aquests tres Serveis a rutas-norte-dev i cap no funciona. Per a cadascun, identifica la causa exacta, indica l'ordre que la revela i escriu la correcció.

Objectiu: que api-reserves parli amb redis-cache i amb postgres-reserves només pel nom, sense cap IP.

1. Comprova que els tres Serveis tenen endpoints.
2. Des d'un pod efímer de redis:7.2-alpine, escriu a la memòria cau la disponibilitat d'una expedició: la clau places:BIL-SAN:2026-08-14 amb valor 37. Recupera-la després des d'un altre pod efímer diferent.
3. Des d'un pod efímer de postgres:16, crea la taula reserves amb columnes id, client i expedicio, insereix dues reserves fictícies i consulta-les.
4. Escriu el fragment de variables d'entorn que portaria el Deployment d'api-reserves per connectar-se a tots dos pel nom, i explica per què aquella configuració és idèntica a rutas-norte-dev, rutas-norte-pre i rutas-norte-pro.

Solució 1

La ClusterIP continua sent 10.96.12.209; els cinc endpoints són IPs noves.

4. targetPort: http referencia el nom del port declarat al contenidor (ports[].name: http) en lloc del seu número. Així, si demà botiga-web canvia el seu nginx per escoltar al 8080, n'hi ha prou amb actualitzar el containerPort al Deployment: el Service continua sent correcte sense tocar-lo. És un desacoblament entre la definició del servei i el detall d'implementació del contenidor, i a més fa el manifest autoexplicatiu.

Solució 2

Solució 3

Dos pods efímers diferents, creats i destruïts, han compartit estat a través de redis-cache sense conèixer cap IP.

4. Configuració d'api-reserves pel nom:

Aquella configuració és idèntica als tres entorns perquè el nom curt redis-cache es resol dins del namespace on corre el pod. Un pod d'api-reserves a rutas-norte-pro resoldrà redis-cache com a redis-cache.rutas-norte-pro.svc.cluster.local, mentre que el mateix pod a rutas-norte-dev el resoldrà com a redis-cache.rutas-norte-dev.svc.cluster.local. El mateix manifest serveix per als tres entorns sense canviar ni una sola línia, i cadascun parla amb la seva pròpia base de dades i la seva pròpia memòria cau. És exactament el mecanisme que explota la lliçó següent, Namespaces.

La plataforma Rutas Norte ja té sistema circulatori. Has vist en primera persona per què les IPs de pod són inservibles com a punt de connexió —canvien a cada desplegament, cada autoreparació i cada escalat— i com el Service resol el problema amb una ClusterIP virtual que no canvia mai, un nom DNS i balanceig automàtic entre les rèpliques sanes. Saps que aquella IP no és una màquina sinó una regla de reenviament, i que la llista de destins reals la manté al dia el controlador d'endpoints, escrivint als EndpointSlices únicament les adreces dels pods llestos.

Llegeixes un manifest de Service sense dubtar: port és per on entra el trànsit i targetPort per on surt cap al contenidor, preferiblement pel nom per desacoblar el Service de la implementació. Entens per què ClusterIP és el tipus per defecte i per què a Rutas Norte ho són tots els Serveis, inclosos els dels components públics, que s'exposaran mitjançant una única porta d'entrada. I has donat adreça estable a quatre components: botiga-web, api-reserves, postgres-reserves i redis-cache, mentre que worker-notificacions i informes-ocupacio no porten Service perquè ningú no inicia connexions cap a ells. Ho has verificat sense trampes: pods efímers cridant pel nom, vuit peticions repartides entre dues rèpliques, i la prova definitiva d'escalar i tornar a desplegar veient com la ClusterIP aguanta mentre tots els endpoints es renoven.

Finalment, t'emportes el procediment de diagnòstic més rendible de tot Kubernetes: quan un Service no respon, el primer és kubectl get endpoints. Buit significa que el selector no encaixa amb les etiquetes dels pods, i d'aquí a comparar describe svc amb get pods --show-labels hi ha un pas. Amb adreces, el problema és als ports o a l'aplicació.

Has notat que en tota la lliçó hem escrit rutas-norte-dev una vegada i una altra, i que la configuració d'api-reserves no menciona l'entorn enlloc perquè el DNS ho resol sol. Això no és casualitat: és la propietat que fa possible desplegar la mateixa plataforma tres vegades sense tocar els manifests. A la lliçó següent, Namespaces, muntarem els tres entorns de Rutas Norte —dev, pre i pro—, desplegarem el mateix manifest en diversos d'ells, veurem què aïlla realment un namespace i, el més important, què no aïlla en absolut.