La lliçó anterior va posar quotes als tres entorns de Rutas Norte i va deixar dos caps solts molt concrets. El primer és pràctic i molesta cada dia: des que rutas-norte-dev té quota de computació, un simple kubectl run falla amb must specify requests.cpu, i qualsevol manifest d'un tercer que no declari recursos és inaplicable. El segon és més profund: sabem que quan a un node li falta memòria algú ha de morir, però no sabem qui, i aquesta decisió no és gens aleatòria. Aquesta lliçó tanca els dos: el LimitRange injecta valors per defecte i posa topalls per contenidor dins del namespace, i les classes de qualitat de servei —Guaranteed, Burstable i BestEffort— determinen l'ordre exacte en què el kubelet desallotja i en què el kernel mata. Al final assignaràs una classe raonada a cada component de Rutas Norte i provocaràs un desallotjament real al teu minikube per veure-ho amb els teus propis ulls.

1. Què resol un LimitRange
2. Els camps: default, defaultRequest, min, max, maxLimitRequestRatio
3. Demostració: un pod sense recursos surt amb recursos
4. Els tipus: Container, Pod i PersistentVolumeClaim
5. Interacció exacta entre LimitRange i ResourceQuota
6. Les tres classes de QoS i la regla que les determina
7. Consultar la classe d'un pod
8. Conseqüència 1: oom_score_adj i l'OOM killer del kernel
9. Conseqüència 2: l'ordre de desallotjament del kubelet
10. La classe de QoS de cada component de Rutas Norte
11. El LimitRange dels tres entorns
12. Experiment: provocar un desallotjament i veure qui cau primer

El LimitRange és un objecte amb namespace que fa dues coses diferents sobre cada contenidor que s'hi creï:

1. Injecta valors per defecte als contenidors que no declaren requests o limits.
2. Valida topalls: rebutja els contenidors que demanen menys d'un mínim o més d'un màxim.

La diferència amb la ResourceQuota és l'àmbit, i convé tenir-la claríssima perquè es confonen constantment:

Una analogia amb Rutas Norte: la ResourceQuota és el pressupost anual del departament (no es poden gastar més de X euros entre tots). El LimitRange és la política de despeses per persona (ningú no pot demanar un bitllet de més de Y euros, i si no s'especifica classe, s'assumeix turista).

Els tres problemes concrets que resol:

Problema 1: la quota trenca tot el que és còmode. Ja ho vam veure:

Problema 2: un sol contenidor pot acaparar la quota sencera. Sense LimitRange, algú pot desplegar un pod amb requests.memory: 4Gi a rutas-norte-dev i esgotar de cop tota la quota de memòria de l'entorn, deixant sense lloc els cinc components.

Problema 3: valors absurds. Un contenidor amb requests.memory: 4Mi no arrencarà mai de manera estable, però res no ho impedeix.

Camp per camp:

Regles de resolució que cal conèixer amb precisió:

Regla 1: el declarat sempre guanya. El LimitRange no sobreescriu mai un valor que el contenidor declara. Només omple forats.

Regla 2: si declares limits però no requests, la request pren el valor del limit, no el de defaultRequest. Aquest comportament enxampa molta gent:

Amb el LimitRange de dalt (defaultRequest.memory: 128Mi) un esperaria requests: 128Mi. Però el resultat és:

La regla de Kubernetes de "si només hi ha limits, la request iguala el limit" té prioritat. Conseqüència pràctica: reserves 1 GiB del pressupost del namespace sense voler.

Regla 3: si declares requests però no limits, s'aplica default. Aquí sí que funciona com un espera... llevat que default sigui menor que la teva request, cas en què el pod es rebutja per incoherent.

Regla 4: maxLimitRequestRatio limita el sobrecompromís individual. Amb memory: "4", un contenidor amb requests.memory: 128Mi no pot tenir limits.memory més gran de 512Mi. És l'eina per impedir que algú reservi poc i després consumeixi molt, que és just el patró que provoca desallotjaments.

Taula dels sis escenaris possibles, amb el LimitRange de l'exemple:

Res no convenç tant com veure-ho. Partim de rutas-norte-dev amb la seva quota i apliquem el LimitRange:

Ara el mateix kubectl run que abans fallava:

Funciona. I l'interessant és veure quins recursos té realment:

El manifest que hem enviat no tenia resources i l'objecte desat a etcd sí que en té. El LimitRange els hi ha injectat.

Qui fa aquesta injecció? Un controlador d'admissió (admission controller) anomenat LimitRanger, que forma part de l'apiserver. Recorda el flux del mòdul 1: una petició passa per autenticació, autorització i admissió abans d'escriure's a etcd. L'admissió té dues fases:

L'ordre és crucial i explica tot el de l'apartat 5: el LimitRange muta primer, la ResourceQuota valida després. Quan la quota mira el pod, aquest ja té els seus recursos injectats.

I una conseqüència que cal tenir present: l'objecte al clúster ja no és igual que el fitxer YAML del teu repositori. És la primera vegada al curs que això passa, i convé saber-ho per no desconcertar-se en un kubectl diff. També la deixa anotada el mateix pod:

Comprovem també els topalls. Un contenidor demanant massa:

I un demanant massa poc:

Els tres comportaments verificats: injecta, posa sostre i posa terra.

Un LimitRange pot tenir diverses entrades a spec.limits, cadascuna amb el seu type:

Diferències entre els tres:

El tipus Pod és útil quan arribi el mòdul 6 amb els sidecars i init containers: un pod pot tenir tres o quatre contenidors, cadascun dins del max de Container, però sumant entre tots una quantitat desmesurada. El límit de Pod talla això.

El tipus PersistentVolumeClaim prendrà sentit al mòdul 5. Amb max: storage: 200Gi ningú no pot demanar un disc de 2 TiB per un error de teclat, cosa que al núvol es tradueix en una factura desagradable a final de mes.

Aquest és el punt on tot encaixa. La seqüència, per a un pod que arriba sense resources a un namespace amb tots dos objectes:

Les quatre conseqüències d'aquest ordre:

Conseqüència 1: el LimitRange salva la ResourceQuota del seu propi rigor. Sense LimitRange, la quota obliga a declarar recursos a mà a tot arreu. Amb LimitRange, el valor per defecte s'injecta i la quota el comptabilitza sense que ningú escrigui res.

Conseqüència 2: els valors injectats consumeixen quota. Això no és gratis i cal dimensionar-ho. Si defaultRequest.memory és 128Mi i algú llança 20 pods de depuració sense recursos, es mengen 2,5 GiB del pressupost del namespace. Per això els valors per defecte han de ser modestos: són per a pods que ningú no ha calibrat.

Conseqüència 3: un pod pot passar el LimitRange i fallar a la quota. Són validacions independents i cal complir-les totes dues:

Aquell pod complia el max del LimitRange (2Gi), però no cabia en el que quedava de quota.

Conseqüència 4: canviar un LimitRange no afecta els pods existents. L'admissió actua només en la creació. Si puges el defaultRequest, els pods que ja corren conserven el que se'ls va injectar. Per aplicar els valors nous cal recrear-los:

I una regla de coherència entre tots dos objectes que evita un problema desagradable: el max del LimitRange no ha de superar mai la quota del namespace. Si max.memory és 8Gi però la quota de requests.memory és 4Gi, algú pot escriure un manifest que passi el LimitRange i sigui impossible de desplegar. És millor que el rebuig arribi amb el missatge clar del LimitRange ("maximum memory usage per Container is 2Gi") que amb el de la quota, més difícil d'interpretar.

Canviem de tema i arribem a la part més interessant. Quan es crea un pod, Kubernetes li assigna automàticament una classe de qualitat de servei a status.qosClass. No es declara: es dedueix de com estiguin posats els recursos.

La regla exacta, en ordre d'avaluació:

En paraules precises:

Guaranteed — s'assigna si i només si, per a tots els contenidors del pod (inclosos els init containers):

• Es declaren limits de CPU i de memòria.
• Es declaren requests de CPU i de memòria (o s'ometen, cas en què igualen els limits).
• requests és exactament igual que limits en tots dos recursos.

BestEffort — s'assigna si cap contenidor del pod no declara cap request ni cap limit, de cap recurs.

Burstable — tota la resta. És el calaix per defecte: almenys un contenidor declara alguna cosa, però no es compleix la condició estricta de Guaranteed.

Exemples que aclareixen els casos frontera:

Tres paranys que convé memoritzar:

Parany 1: n'hi ha prou amb un contenidor per arruïnar la classe. Si un pod té l'aplicació amb requests == limits i un sidecar de registre sense recursos, el pod sencer és Burstable. La classe és del pod, no del contenidor.

Parany 2: amb LimitRange actiu, BestEffort és gairebé impossible. El LimitRanger injecta valors per defecte, així que cap pod no arriba a BestEffort. És un efecte secundari important i en general desitjable.

Parany 3: defaultRequest diferent de default impedeix Guaranteed. Si el LimitRange injecta requests: 100m i limits: 300m, tots els pods sense recursos seran Burstable. Perquè un pod sigui Guaranteed cal declarar-ho explícitament.

Per a tots els pods del namespace d'un cop d'ull:

Un recompte ràpid per classe:

Aquests sis BestEffort mereixen una mirada: en un clúster de producció són els primers candidats a morir, així que convé saber qui són i si això és intencionat.

describe també la mostra:

Aquí hi ha la primera conseqüència real de la classe, i és de vida o mort, literalment.

Quan el kernel de Linux es queda sense memòria, executa l'OOM killer, que tria una víctima. L'elecció es basa en una puntuació per procés, oom_score, que combina la memòria que consumeix amb un ajust manual anomenat oom_score_adj, un valor entre -1000 i 1000. Com més alt sigui, abans mor.

El kubelet estableix aquest ajust segons la classe de QoS:

La fórmula per a Burstable és la que dona tot el matís:

Llegeix-la a poc a poc: com més gran sigui la teva request de memòria, menor és la teva puntuació i més tard mors. Un pod Burstable que demana molta memòria està gairebé tan protegit com un Guaranteed; un que en demana molt poca està gairebé tan exposat com un BestEffort.

Comprovem-ho en un node amb 8 GiB assignables. Per a api-reserves amb requests.memory: 512Mi:

Exactament el previst. I la conclusió de negoci és directa:

Quan al node li falti memòria, el kernel matarà api-reserves molt abans que postgres-reserves. I això és justament el que volem: perdre un pod de l'API significa perdre unes peticions que el client pot reintentar; perdre la base de dades significa que tota la plataforma deixa de vendre bitllets i, en el pitjor cas, que una transacció a mitges corromp dades.

Cal distingir dues situacions diferents que es confonen sovint:

El segon cas és el desconcertant: un pod mor i les seves mètriques mostren que estava molt per sota del seu límit. La causa és en un veí que es va descontrolar, i la classe de QoS és el que va determinar que la víctima fos ell i no un altre.

Abans que el kernel arribi a matar processos, el kubelet té el seu propi mecanisme, més ordenat: el desallotjament per pressió de recursos (eviction).

El kubelet vigila els recursos del node cada 10 segons. Quan creua un llindar, marca la condició corresponent (MemoryPressure, DiskPressure, PIDPressure) i comença a desallotjar pods per recuperar recursos.

Els llindars per defecte:

I el criteri de selecció de les víctimes, en aquest ordre estricte:

1. Primer, si el pod excedeix les seves requests. Els que consumeixen més del que van reservar són candidats abans que els que es mantenen dins.
2. Segon, la classe de QoS: BestEffort primer, després Burstable, i Guaranteed en últim lloc.
3. Tercer, la PriorityClass, si està definida.
4. Quart, quant excedeix l'ús sobre la request. Entre dos candidats iguals, cau el que més s'ha passat.

Dit de manera operativa:

El primer pod a caure és un BestEffort. Si no n'hi ha cap, cau el Burstable que més s'hagi passat de la seva request. Un pod Guaranteed que es manté dins dels seus recursos és pràcticament intocable.

Un pod desallotjat es veu així:

Aquest missatge ho diu tot: request is 0 perquè era BestEffort, i per tant qualsevol consum excedeix la seva reserva. Va ser el candidat perfecte.

Dos apunts pràctics importants:

Els pods desallotjats no s'esborren sols. Queden en Failed ocupant espai a etcd. Convé netejar-los:

Un pod desallotjat que pertany a un Deployment es recrea. El ReplicaSet del mòdul 2 veu que falta una rèplica i en crea una altra, possiblement en un altre node. Un pod solt desallotjat, en canvi, no torna mai. Un motiu més per no desplegar pods solts.

Ara la decisió de disseny, que és el que dona sentit a tot l'anterior. La pregunta és, per a cada component: què passa si aquest pod mor de sobte?

Els manifests concrets. postgres-reserves com a Guaranteed:

api-reserves com a Burstable:

L'anàlisi puntual com a BestEffort:

Compte: amb un LimitRange actiu a rutas-norte-dev, aquest resources: {} no produirà BestEffort, perquè el LimitRanger injectarà els valors per defecte. Per aconseguir un pod BestEffort de debò cal fer servir un namespace sense LimitRange, i per això l'experiment de l'apartat 12 en fa servir un a part.

Un cas que mereix comentari: redis-cache és Burstable encara que tingui estat. No s'hauria de protegir com postgres-reserves? No, i la diferència és el valor de la dada. redis-cache desa la disponibilitat de places en memòria cau: si es perd, es recalcula consultant la base de dades. L'impacte és un pic de latència i de càrrega sobre postgres-reserves, no una pèrdua d'informació. El que determina la classe no és si el component té estat, sinó què es perd si mor.

Tanquem la part de configuració amb els tres objectes, coherents amb les quotes de la lliçó anterior.

Comparativa de les decisions:

Toca comprovar la teoria. Crearem un namespace sense LimitRange (per poder tenir pods BestEffort de debò), desplegarem tres pods de les tres classes, i pressionarem la memòria del node fins que el kubelet comenci a desallotjar.

Avís: fes-ho al teu minikube de pràctiques, mai en un clúster compartit. Provocarem deliberadament pressió de memòria en un node.

Pas 1: preparar el terreny.

Uns 7,7 GiB assignables.

Pas 2: els tres pods.

Les tres classes confirmades. Verifiquem també els seus oom_score_adj:

El 975 de victima-burstable surt de la fórmula de l'apartat 8: 1000 - (1000 × 200Mi / 7751Mi) = 1000 - 25 = 975. Demana poquíssim, així que està gairebé tan exposat com el BestEffort.

Pas 3: prémer fins a provocar la pressió.

Pas 4: observar.

L'ordre és exactament el previst: primer el BestEffort, després el Burstable que més s'havia passat de la seva request, i el Guaranteed segueix dret.

Pas 5: llegir els missatges de desallotjament.

Compara les dues últimes frases: el BestEffort excedia una reserva de 0 (tot el que faci servir l'excedeix), i el Burstable excedia la seva reserva de 200Mi en 505Mi. Tots dos eren candidats; el BestEffort primer per classe.

Pas 6: la condició del node i els esdeveniments.

Pas 7: netejar.

El que aquest experiment demostra, traduït a Rutas Norte: si un pont d'agost provoca pressió de memòria al node on viu postgres-reserves, la base de dades no serà la que caigui. Cauran abans els pods d'anàlisi puntual, després les rèpliques d'api-reserves que s'hagin passat de la seva reserva —i el Service continuarà repartint entre les que quedin—, i la plataforma continuarà venent bitllets. Aquesta cadena de supervivència no és casualitat: l'has dissenyada tu en assignar les classes.

Consells:

1. Quota i LimitRange van sempre junts. Tracta'ls com una sola decisió en crear un namespace.
2. Valors per defecte modestos, max generós. El valor per defecte és per al que no s'ha calibrat; el max és una xarxa de seguretat contra els zeros de més.
3. Guaranteed només per al que és veritablement crític. Costa capacitat real: reserves el màxim tot el temps. A Rutas Norte, només postgres-reserves.
4. Vigila els Burstable amb relació alta. Un pod amb request de 200Mi i limit de 4Gi és un candidat permanent al desallotjament. maxLimitRequestRatio ho preveu des del namespace.
5. Afegeix la classe de QoS a les teves revisions de manifests. És una línia a la revisió d'una pull request i evita descobrir en un incident que la base de dades era Burstable.

Amb el LimitRange limits-dev de l'apartat 11 aplicat a rutas-norte-dev:

1. Crea sis pods, un per cada fila de la taula de l'apartat 2 (sense res, només requests de CPU, només limits de memòria d'1Gi, tots dos complets, requests.memory: 16Mi, i requests: 128Mi amb limits: 1Gi).
2. Per als que es creïn, mostra els resources efectius i la seva classe de QoS.
3. Per als que fallin, copia el missatge d'error exacte.
4. Explica en particular per què el tercer acaba amb requests.memory: 1Gi en lloc de 128Mi, i quina conseqüència té sobre la quota del namespace.
5. Calcula quanta quota consumirien entre tots si s'haguessin creat els sis.

1. Llista tots els pods dels tres namespaces de Rutas Norte amb la seva classe de QoS en una sola taula.
2. Comprova si postgres-reserves és Guaranteed als tres entorns. Si no ho és en algun, identifica per què.
3. Modifica el manifest de postgres-reserves perquè sigui Guaranteed a rutas-norte-pro, verifica el canvi i comprova el seu oom_score_adj.
4. Calcula a mà l'oom_score_adj esperat d'api-reserves amb requests.memory: 512Mi en un node amb 7751Mi assignables, i compara'l amb el valor real.
5. Afegeix un sidecar sense recursos a postgres-reserves i observa què li passa a la classe del pod. Explica el resultat i reverteix el canvi.

1. Reprodueix l'experiment de l'apartat 12 al teu minikube.
2. Anota l'ordre exacte dels desallotjaments i els missatges de describe.
3. Modifica victima-burstable perquè la seva requests.memory sigui 1Gi (en lloc de 200Mi) mantenint el mateix consum, i repeteix l'experiment. Canvia l'ordre? Explica per què fent servir la fórmula de l'oom_score_adj.
4. Explica què hauria passat si postgres-reserves de Rutas Norte hagués estat en aquell node com a Burstable amb requests.memory: 256Mi i un consum real d'1,8 GiB.
5. Proposa dues mesures addicionals, més enllà de la classe de QoS, per protegir postgres-reserves d'aquest escenari, i indica en quina lliçó del curs s'estudia cadascuna.

Solució 1

El cas p3 és l'interessant: hem declarat només limits.memory: 1Gi i el resultat és requests.memory: 1Gi, no els 128Mi del defaultRequest. La raó és l'ordre de resolució: Kubernetes aplica primer la seva regla general de "si hi ha limit i no hi ha request, la request iguala el limit", i el defaultRequest del LimitRange només omple el que continua buit després d'això.

La conseqüència sobre la quota és seriosa: aquest pod, que probablement consumeixi 4 MiB de memòria real, ha compromès 1 GiB del pressupost de 4 GiB del namespace. Amb quatre pods així, rutas-norte-dev es queda sense quota de memòria sense que ningú no estigui fent servir res. És un error molt car i molt invisible.

Consum total si s'haguessin creat els sis (només compten els quatre vàlids):

p3 només és el 25 % dels pods i consumeix el 67 % de la memòria compromesa.

Solució 2

postgres-reserves no és Guaranteed en cap entorn. Motiu:

La memòria coincideix però la CPU no (500m davant de 2). N'hi ha prou amb un recurs desigual per perdre Guaranteed. És un error clàssic: s'iguala la memòria pensant en l'OOM i s'oblida la CPU.

El càlcul d'api-reserves:

Coincideix. La diferència de 1931 punts amb postgres-reserves és enorme: a la pràctica, el kernel sacrificarà totes les rèpliques de l'API abans de tocar la base de dades.

El sidecar:

El pod ha perdut Guaranteed per culpa d'un sidecar sense recursos. A rutas-norte-pro el LimitRange li injecta requests: 200m/256Mi i limits: 500m/512Mi, que són diferents entre si, i això ja n'hi ha prou. La correcció és donar al sidecar requests == limits també:

Amb això el pod recupera Guaranteed. Lliçó: en un pod que ha de ser Guaranteed, tots els seus contenidors ho han de ser, inclosos els sidecars i els init containers.

Solució 3

L'ordre observat és BestEffort → Burstable → el Guaranteed sobreviu, amb els missatges de l'apartat 12.

Amb requests.memory: 1Gi a victima-burstable i el mateix consum de 700Mi:

El Burstable ja no cau. Dos motius que actuen alhora:

1. El seu oom_score_adj va baixar de 975 a 868, així que el kernel el prioritza menys com a víctima.
2. I sobretot, ja no excedeix la seva request: consumeix 700Mi i n'havia reservat 1Gi. El primer criteri de selecció del kubelet (apartat 9) és precisament "pods que excedeixen les seves requests", i aquest ja no és en aquell grup.

La moralitat operativa és contundent: declarar una request de memòria realista és la protecció més barata que existeix contra el desallotjament. No canvia el que consumeixes; canvia si ets candidat o no.

4. Si postgres-reserves hagués estat Burstable amb requests.memory: 256Mi i un consum real d'1,8 GiB:

Un 967, gairebé tan exposat com un BestEffort, i excedint la seva request en més d'1,5 GiB, cosa que el posa al primer grup de candidats. Hauria estat dels primers a caure. Per a Rutas Norte això significa: la base de dades cau al pic de venda d'un pont, api-reserves comença a retornar errors de connexió, botiga-web mostra errors als clients, i en el pitjor cas una transacció de reserva a mitges deixa places bloquejades sense bitllet emès. Un Recreate de PostgreSQL a més implica recuperació del WAL en arrencar, amb minuts d'indisponibilitat.

Tot això ho evita una línia: requests == limits.

5. Dues mesures addicionals:

I una tercera, la més important a mitjà termini: convertir postgres-reserves en un StatefulSet amb volum persistent i còpies de seguretat verificades, de manera que la supervivència de la dada no depengui de la supervivència del pod. És la feina dels mòduls 5 i 6.

Has tancat els dos caps solts que va deixar la lliçó anterior. El LimitRange converteix una quota estricta en una cosa portable: injecta default i defaultRequest als contenidors que no declaren res, posa terra i sostre amb min i max, i limita el sobrecompromís individual amb maxLimitRequestRatio. Saps que actua com a controlador d'admissió mutant abans que la ResourceQuota validi, que per tant els valors injectats consumeixen quota, que no és retroactiu, i que els tres tipus —Container, Pod i PersistentVolumeClaim— cobreixen des del contenidor solt fins al cost d'un disc. I coneixes la regla que més diners costa quan s'ignora: si declares només limits, la request copia el limit, no el defaultRequest, i amb això reserves molt més del que et penses.

Domines també les classes de qualitat de servei i la regla exacta que les determina: Guaranteed exigeix requests == limits de CPU i memòria a tots els contenidors del pod, BestEffort exigeix que cap no declari res, i Burstable és tota la resta. La saps consultar amb -o jsonpath='{.status.qosClass}' i, sobretot, saps quines conseqüències té: l'oom_score_adj que el kubelet escriu a cada procés (-997 per a Guaranteed, fins a 1000 per a BestEffort, i una fórmula proporcional a la request de memòria per a Burstable) i l'ordre de desallotjament del kubelet, que mira primer qui excedeix les seves requests i després la classe. Has distingit l'OOM del cgroup —mors pel teu propi límit, sense importar la classe— de l'OOM del node, on la classe ho decideix tot.

Rutas Norte té ara un disseny raonat: postgres-reserves és Guaranteed perquè desa les reserves i les dades personals dels clients i la seva mort atura la venda; api-reserves, botiga-web, redis-cache i worker-notificacions són Burstable perquè tenen rèpliques, són recuperables i necessiten ràfega als ponts; i l'anàlisi exploratòria és BestEffort perquè ha de ser el primer a caure. Els tres entorns tenen el seu LimitRange coherent amb la seva quota. I ho has comprovat provocant un desallotjament real al minikube, veient caure el BestEffort primer, el Burstable que s'havia passat de la seva reserva després, i sobreviure el Guaranteed; i descobrint de passada que pujar una request a un valor realista és la protecció més barata que existeix contra el desallotjament.

Queda una última peça del mòdul, i és d'una altra naturalesa. Hem donat als nostres components la seva configuració, les seves credencials i els seus recursos, però no els hem donat identitat. Tots els pods de Rutas Norte estan fent servir ara mateix la ServiceAccount default del seu namespace, amb un token muntat que cap d'ells no necessita, i cap no té manera de dir a l'API de Kubernetes qui és. La lliçó següent, ServiceAccounts i Accés a l'API des dels Pods, ho resol: veuràs la diferència entre usuaris i ServiceAccounts, per què fer servir la default és mala idea, com han canviat els tokens (de secrets eterns a tokens projectats de vida limitada que el kubelet rota), què hi ha exactament a /var/run/secrets/kubernetes.io/serviceaccount/, per què automountServiceAccountToken: false ha de ser la teva opció per defecte, i parlaràs amb l'API des de dins d'un pod amb curl per veure tant una resposta autoritzada com un 403 Forbidden ben merescut.