A la lliçó anterior vam portar botiga-web i api-reserves a producció. Van ser tretze objectes i una llista de comprovacions llarga, però el marge d'error era generós: si un pod es perd, en neix un altre d'idèntic i ningú no se n'assabenta. Aquí desapareix aquesta xarxa de seguretat. postgres-reserves conté les dades personals dels clients de Rutas Norte, les seves reserves i els seus pagaments. Un pod perdut pot significar minuts de servei caigut; un volum perdut, un problema d'existència per a l'empresa.

Aquesta lliçó resol l'escenari complet d'una càrrega amb estat en producció: des de la pregunta incòmoda de si aquesta base de dades hauria d'estar a Kubernetes, fins al procediment de restauració cronometrat, passant per la commutació per error, l'actualització de versió major i el cas molt diferent de redis-cache, on perdre la dada és acceptable.

Advertiment de compliment normatiu. Tot el que es descriu aquí afecta dades personals de clients (nom, correu, historial de viatges, dades de pagament tokenitzades) i la continuïtat del negoci. Les decisions sobre ubicació de les còpies de seguretat, terminis de retenció, xifratge, accés del personal a les dades i transferències entre regions han de ser revisades i aprovades pel responsable de compliment normatiu de l'organització abans d'aplicar-se. Els valors d'aquest material són il·lustratius i no substitueixen aquesta revisió.

1. La pregunta prèvia: ha de viure la base de dades a Kubernetes?
2. Què té d'especial una càrrega amb estat
3. postgres-reserves amb CloudNativePG
4. Com es connecta api-reserves: l'agrupador de connexions
5. Commutació per error: simular-la i mesurar-la
6. Còpies de seguretat i recuperació a un instant concret
7. Actualització de versió major de PostgreSQL
8. Rèpliques de lectura per a informes-ocupacio
9. redis-cache: quan perdre la dada és acceptable
10. Llista de comprovació d'una càrrega amb estat en producció

És temptador respondre "sí" per coherència: si tota la resta és al clúster, la base de dades també. És una mala raó. La pregunta correcta és quina opció minimitza el risc total al cost que l'empresa pot assumir.

Hi ha tres opcions reals.

El criteri de decisió, en una frase: fes servir la base de dades gestionada tret que tinguis una raó concreta per no fer-ho, i no muntis mai un StatefulSet artesanal per a una base de dades de producció.

Raons concretes que justifiquen l'operador dins del clúster:

• La factura de la gestionada és desproporcionada per a la mida de l'empresa.
• Calen extensions o paràmetres que el proveïdor no permet.
• Hi ha un requisit de portabilitat entre núvols o de desplegament en un centre de dades propi.
• L'equip ja té maduresa operativa demostrada a Kubernetes i algú amb coneixement real de PostgreSQL.

Raons que no justifiquen res: "queda més net", "així tot és Kubernetes", "el YAML és bonic".

La decisió de Rutas Norte. Al mòdul 6 es va presentar CloudNativePG com a substitut del StatefulSet artesanal, i al mòdul 10 es va triar EKS a eu-west-1. L'equip de plataforma ha decidit mantenir postgres-reserves dins del clúster amb CloudNativePG, amb dues condicions explícites escrites a l'acta: que les còpies vagin sempre a un magatzem d'objectes fora del clúster, i que la restauració es provi trimestralment. La raó de la decisió no és tècnica sinó econòmica i de portabilitat: el volum de dades és modest (uns 120 GB), la instància gestionada equivalent amb alta disponibilitat multizona costaria aproximadament el triple, i la direcció vol conservar l'opció de moure la plataforma a un altre núvol d'aquí a dos anys.

És una decisió legítima amb una conseqüència clara: l'equip de plataforma assumeix la guàrdia de la base de dades. Si ningú no està disposat a signar això, la resposta correcta era la gestionada.

Quatre propietats que trenquen les suposicions còmodes del mòdul anterior.

Un pod d'api-reserves és intercanviable amb qualsevol altre. Un pod de PostgreSQL no: un és el primari i accepta escriptures, els altres són rèpliques i només llegeixen. La identitat no és a l'etiqueta, és a l'estat de la replicació en aquell instant, i pot canviar sense que ningú desplegui res.

En arrencar un clúster de PostgreSQL, la primera instància ha d'inicialitzar el directori de dades; les altres s'han de clonar d'ella. En actualitzar, cal actualitzar primer les rèpliques i promocionar després. RollingUpdate no entén d'això.

El volum no és memòria cau: és l'actiu. Això canvia tres coses de cop:

• La política de reclamació del PV ha de ser Retain, no Delete (05-02).
• Esborrar el recurs no pot esborrar la dada: cal protecció explícita.
• Les còpies no són opcionals ni són un detall d'operació: són part del disseny.

La conclusió pràctica: per al que té estat, no desplegues càrregues, delegues en un operador que sap d'aquella base de dades concreta. Això és exactament el que vam veure a 06-07 i el que aplicarem ara.

CloudNativePG és un operador que implementa un clúster de PostgreSQL amb replicació en flux, elecció de primari, còpies contínues i actualitzacions controlades. No fa servir StatefulSets: gestiona els pods directament perquè necessita un control més fi de l'ordre.

Les decisions que convé entendre:

• instances: 3 i no 2. Amb dues instàncies, tan bon punt en cau una et quedes sense redundància justament quan més la necessites, perquè reconstruir una rèplica de 120 GB triga una estona. Tres és el mínim defensable en producció.
• primaryUpdateMethod: switchover. En aplicar una actualització menor, l'operador actualitza primer les rèpliques, després promociona una rèplica ja actualitzada i finalment actualitza l'antic primari. El tall es mesura en segons, no en minuts.
• walStorage separat. El WAL té un patró d'escriptura molt diferent del de les dades i, sobretot, si s'omple el volum de dades per culpa del WAL, PostgreSQL s'atura. Separar-los converteix un incident de severitat alta en un de lleu.
• podAntiAffinityType: required. Amb preferred, un clúster atapeït pot col·locar dues instàncies al mateix node i l'alta disponibilitat esdevé fictícia.
• inheritFromIAMRole: true. Cap clau d'accés desada enlloc: la ServiceAccount del pod té un rol del núvol associat. És la continuació directa del que vam veure a 08-01 i 10-06.
• retentionPolicy: "30d". Aquest valor l'ha de validar el responsable de compliment normatiu: retenir massa poc incompleix obligacions comptables i de continuïtat; retenir massa, amb dades personals a dins, incompleix el principi de limitació del termini de conservació.

El backup del Cluster defineix on i com; cal a més dir quan es pren la còpia base.

Amb la còpia base diària i l'arxivat continu del WAL, la finestra de pèrdua de dades és de segons, no d'un dia: es restaura la còpia base més recent i es reprodueixen els WAL fins a l'instant desitjat. Això és la recuperació a un instant concret de l'apartat 6.

L'operador manté un pod com a primari i n'anota la identitat a l'estat del Cluster. Quan el primari deixa de respondre a les comprovacions durant més de failoverDelay, l'operador tria la rèplica amb el WAL més avançat, la promociona i reconfigura les altres perquè segueixin la nova. Tot això sense que cap manifest canviï.

Els Services que crea automàticament:

PostgreSQL crea un procés per connexió. Amb max_connections: 200 i un HPA que durant el pont de maig porta api-reserves a 40 rèpliques amb un pool de 20 connexions cadascuna, l'aritmètica és demolidora: 800 connexions sol·licitades contra 200 de disponibles. El resultat no és lentitud, és rebuig de connexions i errors 500 en la venda de bitllets.

La solució és un agrupador de connexions (PgBouncer) davant de la base de dades, que CloudNativePG gestiona com a recurs propi:

Mil connexions d'aplicació es multiplexen sobre quaranta de reals. Per això el ConfigMap d'api-reserves de la lliçó anterior apunta a postgres-reserves-pooler-rw i no directament al Service -rw.

Preu a pagar: poolMode: transaction és incompatible amb funcionalitats lligades a la sessió (sentències preparades amb nom en alguns controladors, LISTEN/NOTIFY, taules temporals de sessió, SET persistent). A api-reserves es va comprovar que no se'n fa servir cap. Si se'n fes servir alguna, l'alternativa és session, que redueix molt l'avantatge de l'agrupador.

Un mecanisme d'alta disponibilitat que mai no s'ha provat és una hipòtesi. Aquesta és la prova que Rutas Norte executa a rutas-norte-pre abans de cada temporada alta.

Resultats de l'últim simulacre a rutas-norte-pre (tres repeticions, valors mitjans):

Quinze segons sense poder escriure. Si api-reserves no fa res al respecte, aquests quinze segons són quinze segons d'errors 500 en la compra de bitllets, i en ple pont de maig això són uns quants centenars de vendes perdudes.

Tres mecanismes, i l'ordre importa.

Temps d'espera acotats. Sense temps d'espera, una connexió a un primari mort es queda penjada fins al temps d'espera del sistema operatiu (minuts). Amb ell, falla ràpid i es pot reintentar.

Reintents amb espera exponencial i aleatorietat, només per al que és idempotent. Reintentar un SELECT és segur. Reintentar INSERT INTO reserves sense més pot duplicar la reserva i cobrar dues vegades al client: cal una clau d'idempotència.

Amb quatre intents i base de 200 ms, la finestra coberta ronda els 4-6 segons. No cobreix els quinze del tall complet, i això és deliberat: allargar-la més faria que les peticions s'acumulessin al servidor fins a esgotar la memòria.

Circuit per al que no es pot reintentar. Quan les fallades superen un llindar, el circuit s'obre i l'API deixa d'intentar-ho durant uns segons, i retorna una resposta degradada i immediata en lloc d'acumular peticions penjades.

La combinació dels tres redueix l'impacte real de la commutació a uns pocs segons de degradació parcial, amb la venda recuperant-se sola. És la diferència entre un incident de severitat 1 i una nota al registre.

Amb arxivat continu del WAL, l'RPO real és de segons. L'RTO és el que cal mesurar, i només es mesura restaurant.

CloudNativePG restaura creant un Cluster nou a partir del magatzem d'objectes. Mai no es restaura "a sobre" del clúster existent: se n'aixeca un de paral·lel, es verifica i després es decideix.

Verificació abans de donar per bona la restauració:

Simulacre del 12 de juliol de 2026 sobre una còpia de 118 GB:

Quaranta-tres minuts, dins de l'RTO d'una hora, però amb poc marge. Dues accions van sortir del simulacre: pujar maxParallel de 4 a 8 en la recuperació (ja aplicat més amunt) i tenir el manifest de restauració escrit i versionat al repositori, amb l'instant objectiu com a únic paràmetre a emplenar. Els sis minuts de "redactar el manifest" sota pressió són el pitjor lloc per improvisar.

Una còpia que no s'ha restaurat mai no existeix. És una afirmació literal, no una figura retòrica. Els modes de fallada reals són mundans: la credencial del magatzem va caducar fa quatre mesos i ningú no va mirar l'alerta; el bucket tenia una política de cicle de vida que movia els objectes a emmagatzematge en fred amb hores de latència de recuperació; la còpia es feia però d'una base de dades que ja no era la de producció. Tots es detecten restaurant, i cap no es detecta mirant que el ScheduledBackup estigui en verd.

La regla de Rutas Norte: restauració completa cronometrada cada trimestre, amb acta i amb el temps apuntat. És al calendari de manteniment d'11-06.

Les actualitzacions menors (16.4 → 16.6) les fa l'operador tot sol: canvies imageName, actualitza rèpliques, commuta i actualitza l'antic primari. Tall de segons.

Les majors (16 → 17) són una altra cosa: canvia el format del directori de dades, la replicació en flux no funciona entre versions diferents i la reversió no és trivial. Hi ha tres camins.

Rutas Norte va triar la replicació lògica. El procediment, resumit:

Seqüència del dia del canvi:

1. Setmanes abans: aixecar el clúster 17 a rutas-norte-pre, executar el conjunt complet de proves d'api-reserves contra ell i comparar plans d'execució de les deu consultes més costoses. Un canvi de pla al planificador és el risc real d'una actualització major.
2. Dies abans: aixecar el 17 a pro i deixar-lo sincronitzant per replicació lògica fins que el retard sigui de mil·lisegons.
3. Finestra de tall (uns 90 s): posar api-reserves en mode de només lectura mitjançant una bandera de funcionalitat, confirmar retard zero, aturar la subscripció, apuntar el ConfigMap al pooler del clúster 17, reiniciar el desplegament i treure el mode de només lectura.
4. Després: vigilar durant 48 hores. El clúster 16 es conserva una setmana apagat però intacte, com a pla de reversió.

Un detall que s'oblida sempre: ANALYZE complet després de la migració. Les estadístiques del planificador no es transfereixen, i sense elles les consultes van lentes durant hores i sembla que l'actualització ha anat malament.

informes-ocupacio és el CronJob nocturn que recorre mesos de reserves per calcular ocupació per línia i per franja. Són consultes pesades que, executades contra el primari, competeixen amb la venda de bitllets.

La solució és directa: apuntar-lo al Service -ro, que només enruta a rèpliques.

Dos advertiments sobre les rèpliques de lectura:

• Coherència eventual. Una rèplica va uns mil·lisegons per darrere. Per a informes és irrellevant; per a "acabo de reservar i no veig la meva reserva" és un error visible per a l'usuari. Regla a Rutas Norte: el que l'usuari acaba d'escriure es llegeix del primari; tota la resta pot anar a rèplica.
• Conflictes de recuperació. Una consulta llarga a la rèplica pot entrar en conflicte amb el WAL que arriba i ser cancel·lada. S'ajusta amb max_standby_streaming_delay, acceptant a canvi més retard de replicació durant els informes.

Redis és també una càrrega amb estat, però d'una categoria diferent: la seva dada és reconstruïble. Aquesta diferència ho canvia tot.

A Rutas Norte, redis-cache desa tres coses:

El carretó és el cas incòmode: no és crític com una reserva confirmada, però perdre'l és visible i molest.

Decisió de Rutas Norte: persistència AOF activada amb appendfsync everysec, un sol node amb volum persistent i sense rèplica. El raonament:

• Sense persistència, cada reinici de pod (una actualització de node, un canvi de configuració) buida tots els carretons actius. Passa diverses vegades al mes.
• Amb AOF cada segon, un reinici ordenat perd com a màxim un segon d'escriptures i els carretons sobreviuen.
• Muntar Redis Sentinel o un clúster per a una dada amb TTL de quinze minuts és complexitat sense retorn.

I, sobretot, l'aplicació assumeix que Redis pot no ser-hi: si la memòria cau no respon, api-reserves va a PostgreSQL; si el carretó no hi és, es demana a l'usuari que repeteixi la selecció amb un missatge clar. Cap crida a Redis no pot tombar una petició.

Una cura addicional: si Redis cau durant el pont de maig, tota la càrrega de lectura passa de cop a PostgreSQL. Cal dimensionar la base de dades per sobreviure a aquest escenari, o la fallada d'un component prescindible es converteix en la caiguda d'un que no ho és.

La fila 18 no és burocràcia: en un clúster de PostgreSQL amb dades personals, la retenció de còpies, la regió del magatzem d'objectes, qui pot obrir una psql contra producció i què en queda registrat són decisions amb conseqüències legals, no només tècniques.

• Muntar la base de dades a Kubernetes per coherència estètica. Si ningú de l'equip no sap fer una recuperació a un instant concret ni està disposat a estar de guàrdia, la resposta correcta és la base de dades gestionada, encara que costi més.
• Confiar en el ScheduledBackup en verd. L'indicador diu que el procés s'ha executat, no que la còpia sigui restaurable. Només la restauració cronometrada ho demostra.
• Còpies al mateix clúster o al mateix compte que produeix la dada. Un esborrat accidental amb permisos amplis, o un compromís de credencials, s'endú la dada i la còpia alhora. Magatzem separat i, si és possible, compte separat amb immutabilitat.
• Connectar l'aplicació al Service -rw sense agrupador. Funciona perfectament fins que l'HPA escala, i llavors falla justament el dia de més vendes.
• Reintentar escriptures no idempotents. Duplica reserves i cobraments. Cada escriptura reintentable necessita una clau d'idempotència.
• Fer servir allkeys-lru en un Redis que desa carretons. En omplir-se la memòria desallotja carretons actius. volatile-lru amb TTL només en el que és memòria cau protegeix la dada que sí que importa.
• Consell: escriu el manifest de restauració abans de necessitar-lo i desa'l al repositori amb l'instant objectiu com a buit per emplenar. Estalvia els minuts més cars de l'incident.
• Consell: fes ANALYZE després de qualsevol migració o actualització major. Sense estadístiques, el planificador pren decisions dolentes i tot sembla trencat.
• Consell: dimensiona la base de dades per a l'escenari en què la memòria cau no hi és. Si no, una fallada prescindible es converteix en una de crítica.

Rutas Norte llançarà un producte nou, rutas-carga, amb la seva pròpia base de dades PostgreSQL d'uns 8 GB, tres desenvolupadors, sense equip de plataforma dedicat i amb llançament previst en sis setmanes. Les dades inclouen informació de contacte d'empreses client. Recomana una de les tres opcions i justifica la decisió amb almenys quatre criteris de la taula de l'apartat 1. Indica també quina revisió addicional cal per les dades de contacte.

api-reserves té un HPA amb maxReplicas: 40 i cada rèplica obre fins a 20 connexions. informes-ocupacio obre 5 connexions contra les rèpliques. postgres-reserves té max_connections: 200, de les quals PostgreSQL en reserva 3 per a superusuari. Calcula les connexions màximes sol·licitades sense agrupador, explica què passa al pic del pont de maig i comprova si max_client_conn: 1000 i default_pool_size: 40 són valors adequats.

Durant el simulacre trimestral, el Cluster de restauració es queda així:

Enumera tres causes possibles, digues com distingir-les i quina correcció aplicaries en cada cas. Indica a més quina implicació té això sobre l'RPO real.

Solució 1. Recomanació: base de dades gestionada del proveïdor. Criteris: (a) cost de personal, no hi ha equip de plataforma i l'operatiu de l'operador requeriria tres desenvolupadors que han de construir el producte; (b) temps fins a producció, sis setmanes no donen marge per adquirir maduresa operativa amb CloudNativePG; (c) risc de fallada catastròfica, sense guàrdia establerta una fallada nocturna queda sense resposta; (d) cost d'infraestructura, la prima del proveïdor sobre 8 GB és petita en termes absoluts, molt diferent del cas de postgres-reserves amb 120 GB. El StatefulSet artesanal queda descartat d'entrada. Revisió addicional: les dades de contacte d'empreses client són dades personals de persones físiques de contacte, per la qual cosa l'elecció de regió, la retenció de còpies i les condicions de l'encarregat del tractament (el proveïdor del núvol) han de ser revisades pel responsable de compliment normatiu abans de contractar.

Solució 2. Sense agrupador: 40 × 20 = 800 connexions d'api-reserves, més 5 d'informes = 805 de sol·licitades davant de 197 d'utilitzables. Al pic del pont de maig, tan bon punt se superen les 197, PostgreSQL rebutja amb FATAL: sorry, too many clients already; els pods afectats fallen les seves sondes de preparació, surten del balanceig, l'HPA veu més càrrega als restants i escala més, i empitjora el problema: un cicle de realimentació destructiu. Amb el pooler: max_client_conn: 1000 cobreix les 805 sol·licitades amb marge (adequat); default_pool_size: 40 més reserve_pool_size: 10 obre com a màxim 50 connexions reals contra el primari, folgadament dins de 197, i deixa lloc per a informes, manteniment i superusuari. Tots dos valors són correctes. Convé vigilar la mètrica de temps d'espera en cua de PgBouncer: si creix durant el pic, el coll d'ampolla passa a ser default_pool_size i caldria pujar-lo (amb marge fins a unes 150 connexions reals).

Solució 3. Causes possibles: (a) retenció insuficient, els WAL d'aquell període ja s'han eliminat per la política de 30 dies o per una regla de cicle de vida del bucket; es distingeix llistant el prefix wals/ al magatzem i comprovant si el segment existeix; correcció: triar un instant objectiu dins del rang disponible i revisar la política de retenció i les regles de cicle de vida. (b) Fallada de l'arxivat continu, el primari va deixar d'arxivar WAL en algun moment (credencial caducada, permisos, disc ple) i hi ha un buit; es distingeix mirant cnpg_collector_last_failed_archive_time i els registres del primari; correcció: reparar l'arxivat i, molt important, prendre immediatament una còpia base nova. (c) Permisos o ruta incorrectes a la restauració, el serverName o el destinationPath no coincideixen amb els de l'origen, o el rol federat no té lectura sobre aquest prefix; es distingeix perquè fallarien tots els segments, no un de concret; correcció: ajustar serverName/destinationPath i els permisos del rol. Implicació sobre l'RPO: si l'arxivat té buits, l'RPO declarat de 5 minuts és fals, i el real és l'antiguitat de l'última còpia base completa, que pot ser de gairebé 24 hores. És exactament la raó per la qual existeix l'alerta CopiaPostgresAntiga i per la qual el simulacre trimestral és obligatori.

Hem resolt de principi a fi l'escenari d'una càrrega amb estat en producció. Vam començar per la pregunta que no convé esquivar —si la base de dades ha d'estar a Kubernetes— i vam arribar a una decisió raonada i amb condicions: a Rutas Norte es queda dins del clúster amb CloudNativePG, amb còpies fora i restauració provada cada trimestre. Vam veure què fa especial l'estat (identitat, ordre, dada irreemplaçable, actualitzacions que no admeten RollingUpdate), el recurs Cluster complet amb les seves decisions justificades, l'agrupador de connexions que evita que l'èxit de l'HPA tombi la base de dades, la commutació per error mesurada en quinze segons i els tres mecanismes que permeten a api-reserves travessar-los sense errors visibles, la recuperació a un instant concret amb el seu temps real de 43 minuts, l'actualització de versió major per replicació lògica, les rèpliques de lectura per als informes i redis-cache com el cas en què perdre la dada és acceptable, sempre que l'aplicació ho assumeixi.

La idea que resumeix la lliçó: a les càrregues amb estat, el que et salva no són els manifests, sinó els procediments provats. La còpia que mai no es va restaurar, la commutació que mai no es va simular i l'actualització que mai no es va assajar a pre són deute esperant a vèncer en el pitjor moment.

Ja tenim l'aplicació sense estat i la base de dades en producció. El que no hem explicat encara és com hi arriba el codi. A la lliçó següent, CI/CD amb Kubernetes, seguim el camí complet des del git push d'un desenvolupador fins al pod que atén peticions a rutas-norte-pro, passant per la construcció de la imatge, el seu escaneig i signatura, les proves contra un clúster efímer i la promoció entre entorns amb Argo CD.