La lliçó anterior va acabar amb un diagnòstic precís: tots els volums que coneixíem —emptyDir, configMap, secret, projected— moren amb el pod, i hostPath sobreviu però lliga les dades a un node concret i obre un forat de seguretat inacceptable. Perquè postgres-reserves conservi les reserves cal una cosa diferent: un objecte d'emmagatzematge amb vida pròpia al clúster, independent de qualsevol pod. Aquest objecte és el PersistentVolume (PV). En aquesta lliçó veuràs per què Kubernetes el va separar del consum, desmuntaràs la seva especificació camp a camp —inclòs el parany dels modes d'accés, que s'apliquen per node i no per pod—, en recorreràs les fases amb un diagrama d'estats, i crearàs un PersistentVolume real de 10 GiB per a la base de dades de Rutas Norte al teu clúster de pràctiques.

1. El problema real: qui administra i qui consumeix
2. Què és un PersistentVolume
3. Anatomia de l'objecte: capacity i volumeMode
4. Els modes d'accés i el parany del node
5. La política de reclamació: Retain, Delete i l'obsolet Recycle
6. storageClassName, mountOptions i nodeAffinity
7. Els backends possibles i quins modes admet cada família
8. Cicle de vida: les fases del PV
9. Què fer amb un PV en Released
10. Pràctica: un PV de 10 GiB per a postgres-reserves
11. Per què l'aprovisionament estàtic no escala

Abans de mirar un sol camp YAML, cal entendre quin problema organitzatiu resol aquesta abstracció, perquè si no, la parella PV/PVC sembla burocràcia innecessària.

A Rutas Norte hi ha dos papers diferents i no se solapen:

Si el manifest de postgres-reserves hagués d'anomenar directament un disc d'AWS amb el seu identificador, passarien tres coses dolentes: el manifest deixaria de ser portable entre minikube, preproducció i producció; el desenvolupador necessitaria credencials i coneixement de la infraestructura; i qualsevol canvi de proveïdor obligaria a reescriure tots els manifests de la plataforma.

La solució de Kubernetes és un contracte amb dues cares:

La frase que resumeix la lliçó sencera: el PVC és la demanda, el PV és l'oferta, i el controlador els aparella. Qui desplega l'aplicació escriu únicament la demanda.

Un PersistentVolume és un objecte de l'API que representa una porció concreta d'emmagatzematge ja existent al clúster, aprovisionada per un administrador o creada dinàmicament per una StorageClass.

Tres propietats defineixen la seva naturalesa i convé fixar-les d'entrada:

1. No té namespace. És un recurs d'àmbit de clúster, com els nodes o les StorageClasses. Ho comproves amb el que vas aprendre a 02-06:

   kubectl api-resources | grep -E "^NAME|persistentvolume"
   

   NAME                    SHORTNAMES   APIVERSION   NAMESPACED   KIND
   persistentvolumeclaims  pvc          v1           true         PersistentVolumeClaim
   persistentvolumes       pv           v1           false        PersistentVolume
   

   El PVC sí que té namespace: pertany a l'aplicació. El PV no.
2. El seu cicle de vida és independent del pod. Pots esborrar el Deployment sencer, el pod, fins i tot el PVC, i el PV pot continuar existint amb les dades a dins. Aquesta independència és justament el que faltava a 05-01.
3. És un objecte declaratiu com qualsevol altre. Té apiVersion: v1, kind: PersistentVolume, metadata, spec i status, exactament el model de 01-06. Explora'l:

   kubectl explain pv.spec
   kubectl explain pv.spec.accessModes
   

Un PV complet, amb tots els camps que importen, comentat:

La mida del volum, en unitats de Kubernetes (Gi = 2^30 bytes, G = 10^9 bytes; fes servir sempre Gi). És una dada declarada, no mesurada: Kubernetes no comprova que el disc tingui realment aquesta mida. Amb un backend hostPath de proves pots escriure capacity: 10Gi sobre un directori d'un disc de 4 GiB i ningú no protestarà fins que s'ompli. La seva funció real és servir de criteri en l'aparellament amb el PVC.

Avui storage és l'únic recurs admès a capacity; atributs com les IOPS s'expressen mitjançant els parameters de la StorageClass (05-04).

En mode bloc el contenidor no fa servir volumeMounts sinó volumeDevices, amb devicePath: /dev/xvda en lloc de mountPath: el dispositiu apareix cru, sense sistema de fitxers.

A Rutas Norte fem servir Filesystem a tot arreu. Block només té sentit si l'aplicació sap escriure directament sobre el dispositiu, i PostgreSQL no ho fa.

Els accessModes declaren de quines maneres es pot muntar el volum. Són quatre:

El parany és a ReadWriteOnce, i gairebé tothom hi cau almenys una vegada. El "Once" es refereix a un node, no a un pod. Això vol dir que dos, tres o vint pods poden muntar simultàniament el mateix volum RWO en lectura i escriptura si el planificador els col·loca al mateix node. Cap capa de Kubernetes no ho impedirà.

La conseqüència per a una base de dades és directa i greu: si un rollout amb estratègia RollingUpdate aixeca un pod nou de postgres-reserves al mateix node abans d'acabar el vell, tindràs dos processos de PostgreSQL sobre el mateix directori de dades. Per això postgres-reserves porta strategy: Recreate des del mòdul 2, i per això existeix accessModes: ["ReadWriteOncePod"].

ReadWriteOncePod és l'única garantia que un sol pod pot fer servir el volum; el segon es queda en Pending amb un esdeveniment explícit. És un mode estable des de Kubernetes 1.29 i requereix que el driver CSI el suporti. Quan el driver ho permet, és l'elecció correcta per a una base de dades amb una única rèplica.

Dos advertiments més sobre els modes:

• La llista és una declaració de capacitats, no una restricció activa. Un PV pot declarar ["ReadWriteOnce", "ReadOnlyMany"] per dir que admet tots dos usos; el PVC en triarà un.
• El que un backend admet de veritat no depèn del que escriguis. Pots posar ReadWriteMany en un PV suportat per un disc de blocs d'AWS, i Kubernetes ho acceptarà sense piular; la fallada apareixerà en intentar muntar-lo des del segon node. La taula de l'apartat 7 recull què admet realment cada família.

persistentVolumeReclaimPolicy decideix què passa amb el volum i amb les dades quan el PVC que l'utilitzava s'esborra. És el camp amb més conseqüències de l'objecte.

Recycle és obsolet i no s'ha de fer servir: només funcionava amb hostPath i NFS, esborrava amb un pod auxiliar sense cap garantia, i no encaixa amb el model CSI. El seu substitut és l'aprovisionament dinàmic (05-04): en lloc de reciclar un volum usat, se'n crea un de nou i net.

La decisió pràctica a Rutas Norte:

• postgres-reserves → Retain. L'escenari que cal evitar és que algú esborri per error el namespace rutas-norte-pro —recorda de 02-06 que kubectl delete ns s'emporta els PVC— i que això destrueixi les dades de tots els clients. Amb Retain, el PVC desapareix però el volum continua allà i es pot recuperar.
• Volums reconstruïbles (memòria cau, espais de treball) → Delete. Recrear és més barat que netejar a mà, i Delete evita facturar discos orfes.

Un detall important que confon molt: en l'aprovisionament dinàmic el PV hereta la política de la StorageClass, i la majoria de les classes per defecte dels núvols fan servir Delete. És a dir, si no fas res, esborrar un PVC de producció esborra el disc. Es comprova amb kubectl get storageclass -o custom-columns=NOM:.metadata.name,POLITICA:.reclaimPolicy.

I en un PV ja existent es pot canviar en calent, que és la maniobra defensiva estàndard abans de tocar res:

És una etiqueta d'aparellament: un PVC només es vincula a un PV la classe del qual coincideixi exactament. Tres situacions que cal distingir amb cura (i que tornarem a veure a 05-04):

Un PV estàtic pot portar un storageClassName que no correspon a cap StorageClass existent (per exemple manual). És una pràctica habitual i perfectament vàlida: la cadena només es fa servir per casar oferta i demanda.

Opcions que es passen tal qual al muntatge del sistema de fitxers —noatime i nodiratime per reduir escriptures, o hard i nfsvers=4.1 en NFS—. Kubernetes no les valida: si el backend no les admet, el muntatge falla i el pod es queda en ContainerCreating amb un esdeveniment de FailedMount.

Restringeix des de quins nodes es pot muntar el volum. És obligatori en els volums de tipus local, perquè el disc està físicament en una màquina i el planificador ho ha de saber per no col·locar el pod on el volum no existeix.

Aquest és un cas d'emmagatzematge condicionant la planificació, un tema que s'aprofundeix a 06-05. Al núvol el mecanisme és idèntic però la clau sol ser topology.kubernetes.io/zone: un disc creat a eu-west-1a només es pot muntar des de nodes d'aquesta zona, i d'aquí neix el problema del volumeBindingMode que resoldrà 05-04.

L'spec del PV conté exactament una clau de backend, que defineix d'on surt l'emmagatzematge de veritat.

hostPath com a backend d'un PV té els mateixos perills descrits a 05-01 i només s'ha de fer servir en clústers d'un sol node com el teu minikube. local és el seu cosí seriós: també fa servir un disc de la màquina, però és un tipus pensat per a producció, respecta la planificació gràcies a la nodeAffinity obligatòria i no permet rutes arbitràries del sistema. Tot i així, un volum local no sobreviu a la pèrdua del node: la redundància és responsabilitat de l'aplicació (replicació de PostgreSQL, per exemple).

NFS és la via més senzilla per aconseguir ReadWriteMany, útil per exemple perquè les tres rèpliques de botiga-web comparteixin un directori d'imatges de trajectes. No és adequat per al fitxer de dades de PostgreSQL: el bloqueig de fitxers sobre NFS és una font clàssica de corrupció.

En un clúster gestionat no escriuràs gairebé mai un PV a mà; els crearà el driver CSI del proveïdor. Quan els inspeccionis, veuràs una clau csi amb driver: ebs.csi.aws.com, el volumeHandle (l'identificador del disc real al proveïdor), el fsType i uns volumeAttributes.

L'arquitectura de CSI s'estudia a fons a 05-05.

Taula orientativa; la veritat última la marca el driver i la seva versió.

La regla que se'n deriva: si necessites ReadWriteMany, necessites un sistema de fitxers compartit, i això és una decisió d'arquitectura i de cost, no un camp YAML. Per a postgres-reserves no ens cal: una base de dades amb una rèplica vol ReadWriteOnce (o millor ReadWriteOncePod) sobre un disc de blocs ràpid.

El PV té un camp status.phase amb quatre valors possibles:

Comprovació al clúster:

La columna CLAIM et diu, per a cada PV, quin PVC de quin namespace el té agafat. És la vista d'un cop d'ull que més es fa servir en el dia a dia.

Aquesta és una situació operativa que apareix sempre i desconcerta la primera vegada. Algú esborra el PVC de postgres-reserves; com que la política és Retain, el PV passa a Released. Crees de nou el mateix PVC, amb el mateix nom i la mateixa petició… i es queda en Pending per sempre, tot i que el PV que vol és allà amb 10Gi lliures.

La causa és que el PV conserva a spec.claimRef la referència al PVC anterior, inclòs el seu uid:

Encara que el PVC nou es digui igual, el seu uid és diferent, així que no casa. I aquest bloqueig és deliberat: és la protecció que impedeix que les dades d'un inquilí acabin muntades per error al pod d'un altre.

El procediment correcte té tres camins, en ordre de preferència:

a) Reutilitzar el volum per al mateix propòsit (el cas d'una recuperació després d'un esborrat accidental). S'elimina la referència caducada i el PV torna a Available:

Ara qualsevol PVC compatible el pot agafar. Les dades continuen a dins.

b) Preassignar-lo a un PVC concret, que és més segur que deixar-lo solt. S'edita el claimRef deixant namespace i name però sense uid: el PV només acceptarà aquest PVC exacte.

c) Descartar-lo. Si les dades ja no valen, s'esborra el PV i es neteja el volum real a mà (amb Retain, esborrar l'objecte PV no esborra les dades del backend: al núvol el disc es continua facturant).

Consell operatiu: abans de reutilitzar un PV Released que contingui dades, fes-ne una còpia. L'apartat 10 crea el volum; la còpia de seguretat s'estudia a 05-06, però la regla s'aplica des d'avui.

Anem a crear el volum que salda el deute del mòdul. A minikube el suport serà un directori del node, i aquí hostPath és acceptable per ser un clúster d'un únic node i de proves; el manifest porta un comentari que ho deixa explícit perquè ningú no el copiï a producció.

Primer preparem el directori al node:

A minikube, /data és un directori que persisteix als reinicis de la màquina virtual, a diferència de la major part del sistema de fitxers. Per això és el lloc correcte per a aquesta pràctica.

Ara el PersistentVolume:

Available: existeix, està lliure i espera un PVC. Fixa't que no hi ha cap namespace a la sortida: és un recurs del clúster.

Vista detallada:

Dos detalls que val la pena llegir:

• Finalizers: [kubernetes.io/pv-protection]. És el mecanisme de 01-06: impedeix que el PV s'esborri mentre estigui vinculat a un PVC. Si esborres un PV en ús, l'objecte queda en Terminating fins que deixa d'estar-ho.
• Claim: buit. Ningú no l'ha reclamat encara. Aquest buit l'omplirà el PVC de la lliçó següent.

Ara comprova el que encara no passa: el pod de postgres-reserves continua sense fer-lo servir. Un PV no es munta sol; cal un PVC que el reclami. Això és exactament el contingut de 05-03.

El que acabes de fer s'anomena aprovisionament estàtic: un humà crea el PV a mà, per endavant, i espera que algú el reclami. Funciona, i per a un directori a minikube o per a una cabina d'emmagatzematge fixa en un centre de dades propi és perfectament raonable. Però com a model general falla per quatre bandes:

La solució és invertir l'ordre: en lloc de crear volums per si de cas, crear el volum exacte en el moment en què algú el demana. Això és l'aprovisionament dinàmic, i l'objecte que el fa possible és la StorageClass, que ja hem anomenat a storageClassName sense explicar-la. La veuràs a 05-04 i la maquinària que hi ha al darrere, CSI, a 05-05.

La bona notícia és que el que estàs aprenent no canvia: en aprovisionament dinàmic continuen existint PV amb exactament aquests camps —capacitat, modes d'accés, política de reclamació, afinitat de node—; l'única diferència és qui els escriu.

Consells operatius:

1. Etiqueta els PV. Sense etiquetes no els pots fer servir amb selector des d'un PVC ni filtrar-los en una auditoria. Fes servir les mateixes convencions que la resta de Rutas Norte, inclosa app.kubernetes.io/part-of.
2. Auditoria ràpida de risc — quins volums es destruirien en esborrar el seu PVC:

   kubectl get pv -o custom-columns=\
   NOM:.metadata.name,POLITICA:.spec.persistentVolumeReclaimPolicy,\
   ESTAT:.status.phase,CLAIM:.spec.claimRef.name | grep Delete
   

3. Abans de qualsevol operació delicada, canvia la política a Retain amb kubectl patch. És reversible i ha salvat moltes bases de dades.
4. kubectl get pv,pvc -A en una sola ordre et dona la foto completa d'oferta i demanda del clúster.

Crea el PersistentVolume pv-postgres-reserves-10gi de l'apartat 10 al teu minikube. Després:

1. Comprova que és un recurs sense namespace i que la seva fase és Available.
2. Escriu un fitxer dins del directori del node i verifica que hi és.
3. Canvia la seva política de reclamació a Delete amb kubectl patch i torna a deixar-la en Retain, comprovant el canvi a cada pas.
4. Intenta esborrar el PV i explica quin finalitzador apareix a kubectl describe.

L'equip de plataforma ha de preparar l'emmagatzematge de tres necessitats. Per a cadascuna, decideix capacity, accessModes, persistentVolumeReclaimPolicy, volumeMode i el tipus de backend, i justifica cada elecció:

• A. Les dades de postgres-reserves en producció: 200 GiB, una sola instància, contenen dades personals de clients, rendiment crític.
• B. Un directori d'imatges de trajectes que les tres rèpliques de botiga-web han de llegir simultàniament, i que un procés d'administració actualitza un cop al dia: 20 GiB.
• C. Un espai de treball de 500 GiB perquè informes-ocupacio generi l'informe nocturn i el borri en acabar.

Escriu el manifest del cas B.

Reprodueix i resol l'incident clàssic:

1. Crea un PV pv-practica-rescat d'1 GiB amb Retain, classe manual i suport hostPath a /data/rescat.
2. Crea un PVC anomenat dades-practica a rutas-norte-dev que el vinculi i escriu un fitxer testimoni des d'un pod.
3. Esborra el PVC i observa la fase del PV.
4. Torna a crear el mateix PVC. Què passa i per què?
5. Arregla-ho sense perdre el fitxer testimoni.

Exercici 1

Mentre el PV estigui Available l'esborrat és immediat: el finalitzador es retira sol. Si estigués Bound a un PVC, l'objecte quedaria en Terminating fins que el PVC desaparegués. És la protecció de volum en ús, germana de la pvc-protection que veuràs a 05-03.

Exercici 2

Justificacions:

• A. Una sola instància de PostgreSQL: ReadWriteOncePod garanteix que cap segon pod no el pugui muntar, ni tan sols al mateix node, cosa que elimina el risc de corrupció per dos processos. Retain perquè conté dades personals de clients i un esborrat accidental del PVC no les pot destruir. Disc de blocs per rendiment: els fitxers compartits afegeixen una latència inacceptable per a una base de dades.
• B. Diversos lectors en nodes diferents exigeixen ReadWriteMany, i això obliga a un sistema de fitxers compartit: un disc de blocs no serveix aquí per molt que s'escrigui RWX al YAML. Retain perquè les imatges són contingut de negoci recuperable però costós de regenerar.
• C. Dades completament reconstruïbles: Delete evita pagar 500 GiB orfes cada nit. En realitat, el cas C és el candidat perfecte per a un volum efímer genèric (05-01), que ni tan sols requereix crear el PV.

Exercici 3

Es queda en Pending. Per què: el PV està en Released, no en Available, perquè conserva un spec.claimRef que apunta al PVC anterior amb el seu uid. El PVC nou es diu igual però té un altre uid, així que el controlador no el considera candidat. A més, un PV en fase Released mai no s'ofereix per vincular.

El fitxer testimoni continua intacte: Retain va complir la seva funció. Per netejar, esborra el PVC, repeteix el patch del claimRef i esborra el PV.

Has incorporat l'abstracció que sosté tot l'emmagatzematge de Kubernetes, i el primer que has entès és per què existeix: separa qui administra l'emmagatzematge —l'equip de plataforma, que escriu PersistentVolumes i StorageClasses, recursos del clúster— de qui el consumeix —l'equip d'aplicació, que escriu un PersistentVolumeClaim al seu namespace sense saber què hi ha a sota—. Gràcies a aquesta separació, el manifest de postgres-reserves és idèntic a minikube i en producció encara que a sota hi hagi un directori del node o un SSD d'un núvol.

Coneixes l'especificació completa del PV. La capacity, que és declarada i no mesurada. El volumeMode, amb Filesystem per al 99 % dels casos i Block per a qui gestioni la seva pròpia E/S. Els quatre modes d'accés, i sobretot el parany que més car es paga: ReadWriteOnce significa un node, no un pod, de manera que dos pods a la mateixa màquina poden escriure alhora sobre els fitxers de PostgreSQL; la garantia real és ReadWriteOncePod, estable des de 1.29. La política de reclamació, amb Retain per a tot el que guardi dades de negoci, Delete per al que és reconstruïble —i l'avís que les classes per defecte dels núvols vénen en Delete, així que esborrar un PVC esborra el disc— i Recycle obsolet i substituït per l'aprovisionament dinàmic. I storageClassName com a etiqueta d'aparellament, mountOptions sense validació prèvia i nodeAffinity obligatòria als volums local, primer exemple d'emmagatzematge que condiciona la planificació.

Saps quins backends existeixen i què admet cada família de veritat —hostPath i local per a proves i discos locals, NFS com a via senzilla a ReadWriteMany, i els controladors CSI en producció— i tens clar que escriure ReadWriteMany sobre un disc de blocs no el converteix en compartit. Domines les fases (Available, Bound, Released, Failed) i, molt en particular, l'operació que apareix sempre en un incident real: un PV atrapat en Released pel seu claimRef caducat, que es rescata eliminant aquest camp amb kubectl patch --type=json sense perdre ni un sol byte.

I has creat el volum: pv-postgres-reserves-10gi, Retain, ReadWriteOnce, classe rutasnorte-rapida, esperant en fase Available amb la columna CLAIM buida. Aquest buit és l'argument de la lliçó següent. Un PersistentVolume no es munta sol: algú l'ha de reclamar des del namespace de l'aplicació, i aquest algú és l'objecte que converteix per fi en persistent la base de dades de Rutas Norte. El construïm a Reclamacions de Volums Persistents, on a més farem la prova que portem tot el mòdul prometent: crear una reserva, esborrar el pod i trobar-la intacta.