Aurora Libros viu en un clúster amb tres rèpliques fixes de l'API. Funciona bé a les quatre de la tarda i s'ofega el dia que un diari ressenya La sombra del viento. Aquesta lliçó fa que la plataforma creixi sola amb la càrrega, reparteixi el trànsit amb criteri i et deixi veure, amb números, on és el límit real.

1. Escalat horitzontal i vertical
2. Què escala i què no a Aurora Libros
3. El coll d'ampolla real: les connexions de PostgreSQL
4. Rèpliques de lectura i PgBouncer
5. Requisit previ: l'aplicació sense estat
6. Balanceig de càrrega: L4 i L7
7. El balanceig intern: Service, kube-proxy, iptables i IPVS
8. Balanceig d'entrada i al món Compose/Swarm
9. Algorismes i afinitat de sessió
10. Escalat manual, comparat
11. L'HorizontalPodAutoscaler a fons
12. L'HPA d'aurora-api
13. Mètriques personalitzades
14. VerticalPodAutoscaler i Cluster Autoscaler
15. Disponibilitat: PDB, repartiment i antiafinitat
16. Prova de càrrega i lectura dels límits

L'horitzontal és el natural en contenidors per una raó senzilla: arrencar una altra rèplica d'aurora-api:2.0.0 costa uns segons i no requereix permís de ningú, mentre que engrandir una màquina implica aturar-la. I aporta una cosa que el vertical no dona mai: redundància. Tres rèpliques no només aguanten el triple, sinó que sobreviuen a la pèrdua d'una.

L'asimetria de l'última fila és la realitat de gairebé qualsevol plataforma: el frontal escala amb un número, i la base de dades exigeix arquitectura. I com que tot el trànsit hi acaba passant, el límit del sistema és el seu.

Cada connexió de PostgreSQL és un procés del sistema operatiu amb uns quants megabytes de memòria pròpia. El paràmetre max_connections val 100 per defecte, i aquest número no és una recomanació: és una paret.

Amb el DB_POOL_MAX: "10" del teu ConfigMap i max_connections = 100:

Aquest és el parany que fa fracassar el primer autoescalat de molta gent: l'HPA fa la seva feina, crea vint rèpliques per absorbir el pic... i la plataforma sencera cau, perquè vint pools de deu connexions tomben PostgreSQL. Escalar l'API sense mirar la base de dades no reparteix la càrrega: trasllada la fallada.

Hi ha dues solucions i són complementàries.

Rèpliques de lectura. PostgreSQL replica en streaming cap a rèpliques de només lectura. aurora-api envia els SELECT del catàleg a una rèplica i les escriptures al primari. Funciona molt bé a Aurora Libros perquè la seva càrrega és gairebé tota de lectura, però introdueix el retard de replicació: un llibre acabat d'inserir pot trigar mil·lisegons a veure's a la rèplica, així que l'operació que acaba d'escriure ha de llegir del primari.

PgBouncer. Un pooler que es col·loca al davant i multiplexa: mil connexions de client sobre vint connexions reals.

Amb transaction i DB_HOST: pgbouncer, aurora-api pot escalar a cinquanta rèpliques mantenint vint connexions reals contra PostgreSQL. És, de bon tros, la intervenció amb millor relació entre esforç i resultat d'aquesta lliçó.

Una rèplica només és intercanviable si no guarda res que les altres no tinguin. La regla pràctica: si apagues qualsevol Pod i cap usuari no ho nota, l'aplicació és sense estat.

Guardar la sessió en memòria produeix la fallada més desconcertant d'una plataforma escalada: l'usuari inicia sessió (va a la rèplica 1), navega (rèplica 2) i apareix desconnectat. És exactament el problema que resol tenir la memòria cau fora del procés, i per això aurora-cache no és un luxe de rendiment: és el requisit que permet replicar l'API.

La diferència pràctica es veu amb les connexions persistents. Un balancejador L4 reparteix connexions, no peticions: si un client obre una connexió keep-alive i n'envia mil peticions, les mil van al mateix Pod. Amb clients HTTP/1.1 normals amb prou feines es nota, però amb gRPC o HTTP/2 —una sola connexió de llarga vida— el repartiment L4 es torna terriblement desigual, i aquest és el motiu pel qual aquest tipus de trànsit necessita un balancejador L7.

Quan aurora-api resol aurora-cache, obté una IP virtual que no existeix en cap interfície de xarxa: és una adreça fictícia que kube-proxy intercepta amb regles del kernel.

Amb iptables, el repartiment s'implementa encadenant regles amb probabilitats decreixents: la primera accepta amb probabilitat 1/3, la següent 1/2 de la resta, i l'última recull el que queda. El resultat és un repartiment uniforme, però aleatori i sense memòria: no sap quantes connexions té cada Pod ni quant triga a respondre. Per tenir repartiment per menys connexions cal passar a IPVS. I per a polítiques de debò —reintents, tallacircuits, repartiment per latència— cal una malla de serveis com Istio o Linkerd.

L'Ingress opera a L7 i el seu controlador parla directament amb els Pods, saltant-se la IP virtual del Service: consulta els EndpointSlices i balanceja ell mateix, cosa que li permet algorismes i reintents que kube-proxy no té.

El cas de Compose mereix una advertència: amb --scale api=3, el DNS intern retorna les tres IPs, però el client decideix quina fa servir i molts clients HTTP guarden la primera resolució per sempre. És la raó per la qual un docker compose up --scale sense un Nginx al davant reparteix molt pitjor del que sembla.

L'afinitat de sessió lliga cada client a un backend fix:

Sembla la solució fàcil al problema de la sessió en memòria, i és un mal negoci. Trenca el repartiment (un proxy corporatiu amb mil empleats és una sola IP, i tots cauen al mateix Pod), espatlla l'escalat (els Pods nous no reben trànsit existent, així que escalar no alleuja res immediatament) i converteix cada desplegament en una pèrdua de sessions. La solució correcta continua sent la de la secció 5: treure l'estat del procés. Aurora Libros no fa servir afinitat de sessió.

Un avís que estalvia ensurts: si un HPA governa el Deployment, un kubectl scale manual dura fins al cicle següent de l'autoescalador, uns quinze segons. No és una fallada; és que l'estat desitjat el fixa ara l'HPA.

L'HPA és un controlador més: cada 15 segons llegeix les mètriques, aplica una fórmula i ajusta spec.replicas.

Aquesta tolerància del 10 % és important: sense ella, l'HPA reaccionaria a cada fluctuació menor i la plataforma no pararia de crear i destruir Pods.

Requisit previ: metrics-server instal·lat i requests definides. El percentatge de l'HPA és relatiu a les requests, no al límit ni a la capacitat del node. Un Deployment sense requests deixa l'HPA sense denominador i el seu estat apareix com a <unknown>; és la causa número u de "el meu HPA no fa res".

El bloc behavior és el que evita l'efecte io-io: sense ell, una ràfega crea rèpliques, la CPU mitjana baixa, l'HPA les destrueix, la càrrega es torna a concentrar i el cicle es repeteix indefinidament, amb Pods que neixen i moren sense arribar a ser útils.

L'asimetria és deliberada i mereix gravar-se: pujar és urgent, baixar no ho és. Escalar de menys costa peticions perdudes i clients; escalar de més costa uns cèntims de CPU ociosa durant cinc minuts. La finestra d'estabilització de 300 segons fa que l'HPA faci servir el màxim de les recomanacions dels últims cinc minuts abans de reduir.

I el maxReplicas: 12 no és un número rodó: surt del compte de la secció 3. Dotze rèpliques per deu connexions són 120, ja per sobre de max_connections. Amb PgBouncer al davant, aquest sostre podria pujar tranquil·lament.

La CPU és un mal indicador per a una API que espera molt per E/S: aurora-api pot estar al 20 % de CPU i amb la latència pels núvols esperant PostgreSQL. El que de debò descriu la seva càrrega són les peticions per segon i la latència.

Això requereix un adaptador que exposi les mètriques de Prometheus per l'API custom.metrics.k8s.io (prometheus-adapter o KEDA). El circuit complet és: la teva API exposa /metrics → Prometheus la recull (ja ho vas muntar a 05-06) → l'adaptador la publica com a mètrica de Kubernetes → l'HPA la consumeix. Val la pena quan el consum de CPU no es correlaciona amb la càrrega percebuda, que és el cas de gairebé qualsevol API lligada a base de dades.

El VPA ajusta requests i limits en lloc del nombre de rèpliques. El seu gran valor és al mode Off, que només recomana: et diu, amb dades de setmanes, quins valors haurien de tenir els teus contenidors, i així ajustes els manifestos sense endevinar. En mode Auto recrea els Pods per aplicar els valors nous, cosa que el fa incompatible amb l'HPA sobre la mateixa mètrica: si tots dos actuen sobre la CPU, es barallen.

El Cluster Autoscaler treballa un nivell més amunt: quan hi ha Pods en Pending perquè no caben en cap node, demana una màquina nova al proveïdor de núvol; quan un node fa estona que està infrautilitzat i els seus Pods caben en d'altres, el drena i l'apaga. És la peça que fa que l'HPA no xoqui contra el sostre de capacitat, i també la que introdueix el retard real de l'escalat: crear un node triga minuts, no segons.

Escalar no serveix de res si les dotze rèpliques són al mateix node i aquest node cau.

El PDB només cobreix les interrupcions voluntàries: si un node s'apaga de cop, ningú no pregunta res. I hi ha un parany clàssic: minAvailable: 2 amb replicas: 2 bloqueja qualsevol drenatge per sempre, perquè no se'n pot treure cap sense incomplir-lo. Expressa sempre el PDB en funció del mínim de l'HPA, no del número actual.

El p95 va passar de 1 840 ms a 88 ms sense tocar res: l'HPA ho va fer en poc més d'un minut. Fixa't en la fila del pic: 148 % d'utilització vol dir que cada Pod fa servir 1,48 vegades la seva request de CPU, és a dir, està patint throttling contra el seu límit; els dotze errors són peticions que van superar el temps d'espera del client.

L'última fila del bloc anterior és la que més importa de la lliçó: escalar l'API només ajuda quan el coll d'ampolla és l'API. En els altres casos, afegir rèpliques empitjora el problema, perquè multiplica la pressió sobre el component que ja estava saturat.

Advertència. Una prova de càrrega contra un entorn compartit pot degradar serveis d'altres equips i disparar alertes de seguretat. Acorda sempre la finestra, l'origen del trànsit i els llindars amb els responsables d'infraestructura i seguretat, i no llancis mai càrrega contra sistemes que no controles.

• Escalar l'API sense mirar la base de dades. L'HPA crea vint rèpliques, PostgreSQL rebutja connexions i la caiguda és total. Calcula rèpliques × pool abans de fixar maxReplicas.
• HPA sense requests. Els objectius apareixen com a <unknown> i no escala mai. El percentatge és relatiu a la petició.
• Sense metrics-server. L'HPA no té d'on llegir. kubectl top pods és la comprovació de trenta segons.
• scaleDown agressiu. Sense finestra d'estabilització, la plataforma oscil·la i cap rèplica arriba a ser útil.
• Afinitat de sessió com a pedaç. Trenca el repartiment i no arregla el disseny. Treu l'estat del procés.
• minAvailable igual a replicas en un PDB. Bloqueja tots els manteniments del clúster.
• Provar la càrrega contra una API amb la memòria cau calenta. Mesures Redis, no el teu sistema. Buida la memòria cau o varia les claus.
• Consell: mesura abans i després amb els mateixos percentils. El p95 i el p99 expliquen la història; la mitjana l'amaga.
• Consell: fixa maxReplicas a un número que el clúster pugui allotjar. Si no, tindràs Pods en Pending i un autoescalat que aparenta funcionar sense fer res.

Exercici 1. Calcula i demostra el límit de connexions: esbrina el max_connections d'aurora-db, dedueix quantes rèpliques d'API hi caben amb DB_POOL_MAX: 10 i provoca la fallada escalant per sobre d'aquest número.

Exercici 2. Munta l'HPA sobre aurora-api, genera càrrega amb k6 i documenta la taula de latències i rèpliques abans, durant i després. Explica per què la baixada triga molt més que la pujada.

Exercici 3. Comprova que les rèpliques estan repartides i que la plataforma sobreviu a un manteniment: aplica un PDB i topologySpreadConstraints, drena un node i observa què fa Kubernetes.

Solució 1.

Tres rèpliques per deu connexions són exactament les 30 obertes: el DB_POOL_MAX del ConfigMap no és teòric, cada Pod obre el seu pool complet en arrencar encara que no el faci servir. El sostre teòric és (100 − 3 reservades) / 10 = 9 rèpliques.

Nou Pods Running de dotze, i els altres tres en CrashLoopBackOff: els seus pools no van aconseguir obrir-se. Però el greu no són aquests tres, sinó l'efecte sobre els que sí que van arrencar, que comencen a veure errors intermitents en renovar connexions.

Dotze rèpliques i vint connexions reals: PgBouncer ha desacoblat completament l'escalat de l'API del límit de la base de dades. Aquesta és la raó per la qual maxReplicas deixa de ser un compte de connexions i es pot fixar per capacitat de còmput.

La lliçó de fons és de mètode: el límit d'un sistema gairebé mai no és on escales. Aquí escalaves l'API i el que es trencava era PostgreSQL, un servei que ni tan sols havies tocat. Abans de pujar maxReplicas, cal preguntar-se sempre quin recurs compartit es multiplica amb cada rèplica.

Solució 2.

Les dues columnes de la dreta resumeixen el resultat: el p95 va caure de 1 840 ms a 88 ms, vint vegades, sense que ningú toqués res, i els dotze errors del primer minut són el preu d'haver començat amb tres rèpliques.

Els temps revelen l'asimetria del behavior. La pujada va ser en dos salts de 30 segons —stabilizationWindowSeconds: 0 i la política de doblar com a molt— i en 75 segons la plataforma estava estabilitzada. La baixada va començar cinc minuts després que la càrrega acabés, perquè scaleDown.stabilizationWindowSeconds: 300 obliga l'HPA a fer servir el màxim recomanat en aquella finestra; i després va baixar a poc a poc, un 25 % per minut.

Aquesta lentitud és intencionada, i la justificació és econòmica abans que tècnica. Baixar de pressa té un risc asimètric: si la càrrega torna a pujar trenta segons després —cosa molt habitual, perquè el trànsit arriba a ràfegues—, et trobes altre cop amb tres rèpliques ofegades i un altre minut de latències dolentes. Mantenir nou rèpliques cinc minuts de més costa cèntims; quedar-te curt al segon pic costa clients.

Un detall metodològic: les 247 iteracions per segon de l'informe són el rendiment sostingut, no el pic. En mesurar, importa més aquest número al costat del p95 que el màxim instantani, que gairebé sempre s'aconsegueix a costa de latències inacceptables.

Solució 3.

Repartiment perfecte gràcies a topologySpreadConstraints amb maxSkew: 1. Sense aquesta restricció, el scheduler només mira els recursos lliures i és perfectament capaç de posar les sis al mateix node si hi cabien.

El detall que cal observar és que les expulsions es van fer d'una en una i esperant. El drenatge no expulsa alhora tots els Pods del node: demana permís al PDB abans de cadascun, i si expulsar el següent deixés menys de dos disponibles, espera que el reemplaçament estigui preparat en un altre node. Per això ALLOWED DISRUPTIONS va baixant durant l'operació.

Aquí hi ha el parany de la secció 15, en directe: amb minAvailable: 6 i sis rèpliques, cap expulsió no és admissible i el drenatge falla indefinidament. En una actualització nocturna del clúster, aquest PDB deixaria el manteniment penjat sense que ningú entengui per què.

La regla que se'n dedueix: expressa el PDB en funció del mínim de l'HPA, mai del nombre actual de rèpliques. Amb minReplicas: 3, un minAvailable: 2 (o millor, maxUnavailable: 1) dona marge tant en repòs com amb dotze rèpliques.

I la limitació que aquest exercici no cobreix: tot això protegeix davant d'interrupcions voluntàries. Si aurora-worker s'apagués de cop, els seus tres Pods desapareixerien sense que el PDB digués res, i només el repartiment entre nodes —que sí que has garantit— evitaria que Aurora Libros es quedés sense cap rèplica viva.

La plataforma ja creix i s'encongeix sola. Distingeixes l'escalat horitzontal del vertical i saps quins serveis d'Aurora Libros accepten cadascun: l'API i el frontal repliquen sense més perquè no guarden estat, i la base de dades no, per dos motius que has mesurat —el PVC ReadWriteOnce i, sobretot, el max_connections—. Aquesta va ser la troballa més valuosa: el límit del sistema no era on escalaves. Dotze rèpliques per deu connexions tombaven PostgreSQL, i PgBouncer en mode transaction ho va resoldre deixant dotze rèpliques sobre vint connexions reals, amb les rèpliques de lectura com l'altra meitat de la resposta.

Entens per què la memòria cau compartida a aurora-cache no és un luxe sinó el requisit que permet replicar l'API, i per què l'afinitat de sessió és un pedaç que trenca el repartiment en comptes d'arreglar el disseny. Saps què separa L4 de L7, com kube-proxy implementa la IP virtual amb regles probabilístiques d'iptables —i què hi guanya IPVS—, com l'Ingress balanceja parlant directament amb els EndpointSlices, i per què un docker compose up --scale reparteix pitjor del que sembla.

Has muntat l'HorizontalPodAutoscaler amb la seva fórmula, la seva tolerància del 10 % i un behavior deliberadament asimètric: pujar en segons perquè l'usuari espera, baixar en cinc minuts perquè el trànsit arriba a ràfegues. I ho has provat de debò amb k6: el p95 va caure de 1 840 ms a 88 ms en poc més d'un minut mentre l'HPA portava les rèpliques de 3 a 9, i va tornar sol a 3 en acabar. Coneixes les mètriques personalitzades com a pas següent quan la CPU no descriu la càrrega, el VPA en mode recomanació i el Cluster Autoscaler amb el seu retard de minuts. I has assegurat la disponibilitat amb PodDisruptionBudget i topologySpreadConstraints, veient el drenatge expulsar d'una en una i comprovant de primera mà com un PDB mal calibrat bloqueja un manteniment per sempre. Amb la taula que tradueix cada símptoma al seu coll d'ampolla real, perquè escalar l'API només ajuda quan el problema és l'API.

Queda una última peça. Aurora Libros aguanta la càrrega, però cada vegada que publiques una versió nova continua havent-hi un moment delicat. A la lliçó següent, Estratègies de Desplegament i Rollback, veuràs com conviuen la versió vella i la nova: rolling update amb maxSurge i maxUnavailable, blue-green, canari i shadow, amb el seu cost i el seu risc; assajaràs un desplegament fallit d'aurora-api:2.1.0 que no passa la readiness per veure com s'atura tot sol i desfer-lo; i afrontaràs el problema que cap estratègia no resol tota sola, el de les migracions de base de dades.