Tanquem el mòdul d'emmagatzematge amb una promesa pendent. La plataforma Rutas Norte ja té còpies de seguretat verificades i les reserves sobreviuen a l'esborrat d'un pod, però postgres-reserves continua sent un Deployment d'una sola rèplica amb strategy: Recreate. Aquesta configuració no és un descuit: és l'única que funciona, perquè un Deployment aplica la mateixa plantilla de pod —i per tant el mateix PersistentVolumeClaim— a totes les seves rèpliques. Si pugem a dues, totes dues intenten muntar el mateix volum ReadWriteOnce i la segona es queda esperant eternament.

El problema de fons és que un Deployment tracta els seus pods com a bestiar intercanviable: qualsevol serveix, tant se val el nom, tant se val l'ordre, tant se val quin disc toqui. Per a una base de dades això és exactament el contrari del que necessitem. Una rèplica de PostgreSQL necessita saber qui és, necessita el seu propi disc i necessita arrencar en un ordre concret respecte de les altres.

El StatefulSet és el controlador que aporta aquestes tres garanties. En aquesta lliçó l'estudiarem a fons, migrarem postgres-reserves de Deployment a StatefulSet sense perdre el volum existent, i acabarem amb un advertiment honest que marcarà la resta del mòdul: un StatefulSet dona identitat i disc, però no replica dades per tu.

1. Què garanteix un StatefulSet que un Deployment no pot donar
2. Identitat estable: noms ordinals i DNS per pod
3. serviceName i el Service headless
4. volumeClaimTemplates: un disc per rèplica
5. Ordre d'arrencada i aturada: podManagementPolicy
6. Estratègies d'actualització: RollingUpdate, partition i OnDelete
7. Migració pràctica de postgres-reserves a StatefulSet
8. Escalat i què passa amb els PVC
9. El límit honest: identitat no és replicació
10. Segon exemple: redis-cache

Un StatefulSet és, com el Deployment, un controlador que manté un nombre desitjat de pods a partir d'una plantilla. La diferència és què promet sobre aquests pods.

Les tres garanties, dites amb precisió:

• Identitat de xarxa estable. Cada pod rep un nom ordinal derivat del nom del StatefulSet i un hostname que hi coincideix. Aquest nom no canvia encara que el pod es reiniciï, es recreï o acabi en un altre node.
• Emmagatzematge estable per rèplica. Cada pod obté el seu propi PVC generat a partir d'una plantilla. El pod postgres-reserves-0 sempre munta el volum de postgres-reserves-0, mai el de -1.
• Desplegament i escalat ordenats. Els pods es creen i s'eliminen en seqüència, esperant que cadascun estigui llest abans de continuar (si així es configura).

Un advertiment previ que estalvia disgustos: fer servir un StatefulSet no fa que una aplicació sigui distribuïda. Si la teva aplicació no sap què fer amb tres còpies d'ella mateixa, tres rèpliques en un StatefulSet només et donen tres instàncies aïllades que es trepitgen. Hi tornarem a l'apartat 9.

Un StatefulSet anomenat postgres-reserves amb replicas: 3 produeix exactament aquests pods:

El sufix és un ordinal que comença a zero i és contigu. No hi ha salts: si existeix -2, existeixen -0 i -1. Si esborres a mà postgres-reserves-1, el controlador el recrea amb exactament el mateix nom i li torna a muntar exactament el mateix PVC. Des del punt de vista de l'aplicació, el pod "s'ha reiniciat", no "ha estat substituït per un altre".

Aquest ordinal es reflecteix en tres llocs que l'aplicació pot consultar:

• El nom del pod (metadata.name), accessible per Downward API tal com vam veure al mòdul 3.
• El hostname dins del contenidor, que coincideix amb el nom del pod.
• El subdomini que forma el registre DNS, si hi ha Service headless.

Això és el que permet que un script d'arrencada decideixi el seu propi paper:

Aquest patró —deduir el rol de l'ordinal— és la base de moltes imatges de bases de dades preparades per a Kubernetes. També és, com veurem, fràgil: si el pod -0 mor i un altre ha de prendre el relleu, l'ordinal ja no diu la veritat.

El camp serviceName és obligatori en un StatefulSet i apunta al nom d'un Service headless, aquell que a la lliçó 04-02 vam definir amb clusterIP: None i del qual vam dir que el seu ús real arribaria aquí.

Recordem per què. Un Service normal té una IP virtual i reparteix el trànsit entre tots els pods que casen amb el seu selector. Això és justament el que no volem per a una base de dades replicada: si escric a "la IP del servei", no sé si estic escrivint al primari o a una rèplica de només lectura.

Un Service headless no crea IP virtual ni regles de balanceig. En el seu lloc, CoreDNS publica un registre per a cada pod:

Amb aquest Service, cada pod del StatefulSet obté un FQDN propi amb la forma:

És a dir:

Cadascun resol a la IP concreta d'aquest pod, no a una IP virtual. Ho podem comprovar:

A més, consultar el nom del Service headless retorna totes les IP dels pods llestos, cosa que serveix per descobrir la llista de membres:

A la pràctica es fan servir dos Services sobre el mateix StatefulSet:

El ClusterIP normal és el que ja coneixen els altres components des del mòdul 4; no cal tocar la configuració d'api-reserves.

Aquí hi ha la peça que trenca el sostre que vam detectar a 05-03. En lloc de referenciar un PVC ja existent, el StatefulSet declara una plantilla de PVC, i el controlador en crea un per a cada rèplica.

El nom del PVC resultant segueix una regla fixa:

Amb la plantilla anomenada dades i el StatefulSet postgres-reserves:

Dins de la plantilla de pod, el volum es munta referint-se al nom de la plantilla, no al del PVC concret:

I ara el fet crucial, el que més disgustos evita i el que més disgustos causa segons com es miri:

Els PVC creats per volumeClaimTemplates NO s'esborren automàticament. Ni en reduir rèpliques, ni en esborrar el StatefulSet sencer.

És una decisió de disseny deliberada: les dades són el més valuós i Kubernetes no les llença per tu. Si esborres el StatefulSet postgres-reserves i el tornes a crear amb el mateix nom i la mateixa plantilla, els pods es reconnecten als volums que ja existien. Això converteix l'esborrat i la recreació del StatefulSet en una operació segura, cosa que aprofitarem a la migració.

Des de Kubernetes 1.27 hi ha un camp estable per modular aquest comportament:

Per a postgres-reserves deixarem tots dos en Retain, cosa que a més és coherent amb la classe rutasnorte-rapida, la política de reclamació de la qual és Retain. Per a una memòria cau com redis-cache, Delete és defensable.

Per defecte (podManagementPolicy: OrderedReady), el StatefulSet crea el pod -0, espera que estigui Running i Ready, i només llavors crea el -1. En esborrar o reduir, va a l'inrevés: primer l'ordinal més alt.

Això és exactament el que necessita una base de dades on les rèpliques es connecten al primari: no té sentit arrencar la rèplica abans que el node del qual ha de copiar.

Però té un cost. Si el pod -0 no arriba mai a Ready —imatge mal escrita, sonda mal configurada, disc no disponible—, els altres no es creen mai. Un StatefulSet bloquejat a l'ordinal 0 és una de les incidències més habituals.

Nota important: podManagementPolicy és immutable. No es pot canviar en un StatefulSet existent; cal esborrar-lo (amb --cascade=orphan si no vols tocar els pods) i recrear-lo.

Quan canvies la plantilla de pod —per exemple, puges de postgres:16.4 a postgres:16.6—, el StatefulSet aplica la seva updateStrategy.

Actualitza els pods en ordre ordinal invers: primer -2, després -1, per últim -0. Espera que cadascun estigui Ready abans de passar al següent.

L'ordre invers és intencionat: si -0 és el primari, s'actualitza l'últim, minimitzant el temps en què el clúster està sense primari. I com que cada pod conserva el seu disc, el pod actualitzat torna amb les seves dades intactes.

Dins de RollingUpdate hi ha un camp que converteix l'actualització en un desplegament per fases:

La regla és simple: només s'actualitzen els pods l'ordinal dels quals és més gran o igual que partition. Amb partition: 2 i tres rèpliques, només s'actualitza postgres-reserves-2. Els pods -0 i -1 es queden amb la versió antiga encara que hagis canviat la plantilla.

Això permet un alliberament canari manual i controlat:

Si al pas 3 el pod -2 falla, n'hi ha prou amb tornar a pujar partition i revertir la imatge: els altres dos no s'han tocat mai.

El controlador no actualitza res automàticament. Els pods es recreen amb la plantilla nova només quan tu els esborres a mà. És el màxim control possible i es fa servir quan l'actualització requereix passos externs (migrar l'esquema, promoure manualment un primari, verificar la integritat de les dades entre pod i pod).

Aquest és l'exercici central de la lliçó: passar d'un Deployment d'una rèplica amb un PVC anomenat postgres-reserves-dades a un StatefulSet, sense perdre les dades.

L'obstacle és de nomenclatura. El StatefulSet exigirà un PVC anomenat dades-postgres-reserves-0, mentre que el que existeix es diu postgres-reserves-dades. Els PVC no es poden reanomenar. Però sí que podem reutilitzar el PersistentVolume subjacent, que és on hi ha les dades de veritat.

Abans de res, i amb el que hem après a 05-06:

La migració implica aturada de servei. postgres-reserves és d'un sol node: no hi ha manera de fer-la en calent.

Amb la classe rutasnorte-rapida ja és Retain, però comprovar-ho és gratis i equivocar-se és irreversible.

El PV queda en Released: conserva les dades però no admet un PVC nou fins que es netegi la referència a l'anterior.

Ara el PV torna a Available.

volumeName força l'aparellament amb aquell PV concret, en lloc d'aprovisionar-ne un de nou i buit.

Punts que val la pena assenyalar d'aquest manifest:

• serviceName apunta al Service headless, no al ClusterIP normal. És un error freqüent confondre'ls.
• Els recursos mantenen la classe Guaranteed que vam fixar a 03-05: requests iguals a limits, 1 CPU i 2 GiB.
• Es conserven la ServiceAccount dedicada i automountServiceAccountToken: false de 03-06.
• PGDATA apunta a un subdirectori del punt de muntatge. PostgreSQL es nega a inicialitzar sobre un directori que contingui lost+found, cosa habitual en volums de blocs formatats.
• El selector només fa servir app i entorn, segons la convenció del projecte. I recorda: spec.selector és immutable també aquí.

Les dades continuen allà. Ara ja es pot esborrar el Deployment antic:

Escalar un StatefulSet és idèntic en sintaxi a escalar un Deployment:

En pujar, el controlador crea -1, espera que estigui Ready, crea -2. Cadascun provoca la creació d'un PVC nou a partir de la plantilla, i amb rutasnorte-rapida i volumeBindingMode: WaitForFirstConsumer el volum s'aprovisiona a la zona on el scheduler hagi col·locat el pod.

En baixar a una rèplica:

Els pods -1 i -2 han desaparegut, però els seus PVC continuen allà (amb whenScaled: Retain). Conseqüències pràctiques:

• Avantatge: si tornes a pujar a 3, els pods recuperen els seus discos amb les seves dades. L'escalat és reversible.
• Cost: aquests volums continuen facturant. En un proveïdor cloud, tres discos SSD de 20 GiB costen el mateix estiguin muntats o no.

La neteja, quan n'estiguis segur, és manual i explícita:

Amb la classe rutasnorte-rapida en Retain, el PV passarà a Released i continuarà conservant les dades fins que un administrador l'elimini. Aquesta fricció és deliberada.

Arribem al punt més important de la lliçó, i el que més es malinterpreta.

Hem escalat postgres-reserves a tres rèpliques. Això no és un clúster de PostgreSQL. Són tres processos de PostgreSQL, cadascun amb el seu disc buit i independent, sense cap relació entre ells. Si api-reserves escrivís contra el Service ClusterIP, les reserves caurien aleatòriament en una de les tres bases de dades i les dades quedarien escampades i incoherents.

El que un StatefulSet aporta i el que no:

La replicació l'ha d'implementar l'aplicació. En PostgreSQL això significa configurar la replicació per streaming, crear l'usuari de replicació, executar pg_basebackup a les rèpliques, mantenir un primary_conninfo correcte i, sobretot, tenir alguna cosa que decideixi i executi la promoció quan el primari mor.

Aquest "alguna cosa" es pot escriure a mà: initContainers que detecten l'ordinal, sondes que comproven el rol, un script que reescriu els Services. És exactament la feina que fan els operadors, i per això la lliçó 06-07 tancarà el mòdul substituint aquest StatefulSet artesanal per un operador de PostgreSQL que sí que sap fer tot això.

Regla pràctica per al teu dia a dia:

Si l'aplicació ja sap funcionar en clúster (Kafka, Cassandra, etcd, Elasticsearch, ZooKeeper), un StatefulSet ben configurat és suficient. Si no ho sap (PostgreSQL, MySQL, MongoDB en mode simple), un StatefulSet et dona la infraestructura però necessites un operador o un servei gestionat que aporti la lògica.

Mentrestant, postgres-reserves en producció continua amb una sola rèplica. Això és honest: una sola rèplica ben protegida i restaurable és millor que tres rèpliques que fingeixen ser un clúster.

redis-cache és un cas diferent i il·lustratiu. Guarda la disponibilitat de places, és una dada reconstruïble des de postgres-reserves, i perdre-la només provoca un pic temporal de consultes.

Mereix un StatefulSet? Depèn de què vulguis:

• Redis com a memòria cau pura, sense persistència: un Deployment és perfectament vàlid. No hi ha estat a preservar.
• Redis amb persistència AOF/RDB per no arrencar en fred després d'un reinici: StatefulSet, perquè volem que el pod retrobi el seu fitxer.

Rutas Norte tria la segona opció per a producció, perquè després d'un reinici en un pont festiu una memòria cau buida dispara la càrrega sobre la base de dades justament en el pitjor moment.

Diferències deliberades respecte de postgres-reserves, i el raonament que hi ha darrere de cadascuna:

Aquí sí que tenim tres rèpliques de veritat útils, perquè cada instància atén la seva porció de trànsit de manera independent i api-reserves pot repartir consultes entre elles mitjançant el ClusterIP. No hi ha coherència a garantir: si una instància no té la clau, es consulta la base de dades i s'omple.

Confondre serviceName amb el Service normal. serviceName ha d'apuntar al Service headless. Si apunta a un ClusterIP normal, el StatefulSet arrenca sense queixar-se però els noms DNS per pod no funcionen, i les rèpliques que intentin localitzar-se entre si fallaran de manera desconcertant.

Oblidar de crear el Service headless. Kubernetes no valida que el Service de serviceName existeixi. Els pods arrenquen i tot sembla bé fins que alguna cosa intenta resoldre postgres-reserves-1.postgres-reserves-nodes... i obté NXDOMAIN.

Esperar que esborrar el StatefulSet esborri els discos. Amb la política per defecte (Retain) no ho fa. Després de diverses iteracions de proves acabes amb desenes de PVC orfes consumint quota. Revisa-ho periòdicament: kubectl get pvc -A | grep -v Bound no n'hi ha prou, perquè continuen Bound. Busca per etiqueta i compara amb els StatefulSets existents.

Escalar una base de dades i creure que ja està replicada. L'error conceptual més car d'aquesta lliçó. Tres pods de PostgreSQL amb tres discos buits són tres bases de dades diferents. Rellegeix l'apartat 9.

StatefulSet encallat a l'ordinal 0. Amb OrderedReady, si -0 no arriba a Ready, res no avança. Diagnòstic: kubectl describe pod postgres-reserves-0 i kubectl get events -n <ns> --sort-by=.lastTimestamp. Causes típiques: PVC en Pending perquè no hi ha node amb la classe d'emmagatzematge requerida, o sonda de disponibilitat mal configurada.

Canviar volumeClaimTemplates en un StatefulSet existent. És un camp pràcticament immutable: només es permet modificar resources.requests.storage (i des de 1.31 amb la porta de característiques corresponent). Qualsevol altre canvi provoca un error de validació. Si necessites canviar la StorageClass, cal migrar com a l'apartat 7.

Redimensionar el disc. No editis el volumeClaimTemplates esperant que es propagui als PVC ja existents. Cal ampliar cada PVC individualment (kubectl patch pvc dades-postgres-reserves-0 ...) tal com vam veure a 05-05, i actualitzar la plantilla perquè les rèpliques futures neixin amb la mida nova.

Consell: fes servir sempre subPath amb PostgreSQL. Els volums de blocs formatats en ext4 porten un directori lost+found a l'arrel, i initdb es nega a treballar sobre un directori no buit. Muntar a /var/lib/postgresql/data amb PGDATA=/var/lib/postgresql/data/pgdata resol el problema netament.

Consell: kubectl delete statefulset X --cascade=orphan. Esborra el StatefulSet deixant els pods vius. És la maniobra per canviar camps immutables (selector, podManagementPolicy, serviceName) sense interrompre el servei: esborres l'objecte, apliques el manifest corregit i el controlador adopta els pods existents, igual que vam veure amb els ReplicaSets a 02-02.

Al namespace rutas-norte-dev del teu minikube (perfil rutas-norte), desplega un StatefulSet anomenat notes-demo amb 3 rèpliques de busybox:1.36, un Service headless anomenat notes-demo-nodes i un volumeClaimTemplates de 100 MiB amb la classe rutasnorte-estandar, muntat a /dades. Cada pod ha d'escriure el seu nom a /dades/qui-soc.txt en arrencar i després dormir.

Després:

1. Comprova els noms dels pods i dels PVC generats.
2. Escriu un contingut addicional al pod notes-demo-1.
3. Esborra aquest pod i verifica que el pod nou recupera el fitxer.

Sobre el StatefulSet de l'exercici 1, canvia la imatge a busybox:1.37 fent servir partition de manera que només s'actualitzi el pod d'ordinal 2. Verifica que notes-demo-0 i notes-demo-1 continuen amb la imatge antiga. Després completa l'actualització.

Amb el StatefulSet de l'exercici 1 en 3 rèpliques:

1. Redueix-lo a 1 rèplica i comprova quants PVC queden.
2. Torna a pujar a 3 i verifica que notes-demo-2 recupera el seu fitxer, no un de nou.
3. Configura persistentVolumeClaimRetentionPolicy.whenScaled: Delete, redueix un altre cop a 1 i comprova la diferència.
4. Neteja-ho tot.

Solució 1

Els PVC segueixen el patró <plantilla>-<statefulset>-<ordinal>, tal com havíem anticipat.

El fitxer conserva les dues línies anteriors i n'afegeix una tercera de la nova arrencada. El pod es diu igual i ha retrobat el seu disc: identitat estable i emmagatzematge estable, exactament el que un Deployment no pot prometre.

Solució 2

Només l'ordinal més alt s'ha actualitzat. Si això fos una base de dades amb el primari a -0, hauríem provat la versió nova a la rèplica menys crítica.

L'ordre observat als esdeveniments serà -1 primer i -0 després: sempre descendent.

Solució 3

Un pod, tres PVC. És el comportament per defecte (whenScaled: Retain) i la causa habitual de factures d'emmagatzematge inexplicables.

Dues línies: la de l'arrencada original i la de la nova. El disc és el mateix d'abans.

Ara els PVC de -1 i -2 s'han esborrat en desaparèixer els seus pods. Per a una memòria cau és el que es desitja; per a postgres-reserves seria una manera ràpida de perdre les reserves d'un any.

El StatefulSet resol el sostre que arrossegàvem des de la lliçó 05-03. Amb ell, cada rèplica té nom ordinal estable, el seu propi PVC generat des de volumeClaimTemplates i un nom DNS individual gràcies al Service headless que serviceName exigeix. L'arrencada i l'aturada són ordenades (OrderedReady) o simultànies (Parallel) segons convingui, i les actualitzacions baixen en ordre invers amb la possibilitat de frenar-les per fases mitjançant partition.

Hem migrat postgres-reserves de Deployment a StatefulSet reutilitzant el PersistentVolume existent —el truc és alliberar el claimRef i crear un PVC amb el nom exacte que el controlador espera— i hem convertit redis-cache en un StatefulSet de tres rèpliques amb decisions oposades i ben raonades a cada camp.

I hem estat honestos amb el límit: el StatefulSet aporta infraestructura, no lògica. PostgreSQL no es replica pel fet d'estar dins d'un. Aquesta mancança és la que motivarà els operadors de la lliçó 06-07, que tancaran aquest mòdul substituint el nostre StatefulSet artesanal per programari que sap promoure un primari, crear rèpliques de lectura i recuperar a un instant concret.

Abans d'això hi ha altres maneres d'executar càrregues de treball que encara no coneixem. Fins ara totes les nostres càrregues es distribueixen on el scheduler vulgui i en el nombre de còpies que demanem. Però hi ha una categoria de procés —els agents d'infraestructura: recol·lectors de registres, exportadors de mètriques, connectors de xarxa— per als quals "quantes rèpliques" és la pregunta equivocada: la resposta correcta sempre és una per node, ni una més ni una menys, i automàticament als nodes que s'afegeixin demà. Aquest és l'objecte de la lliçó següent: els DaemonSets.