Vam deixar el PersistentVolume pv-postgres-reserves-10gi en fase Available, amb la columna CLAIM buida i 10 GiB esperant algú. Un PV no es munta sol: cal que l'aplicació el reclami, i aquesta reclamació és un objecte amb namespace anomenat PersistentVolumeClaim (PVC). Aquesta és la lliçó en què el deute del mòdul se salda de veritat: escriuràs el PVC, entendràs amb precisió l'algorisme pel qual el controlador aparella demanda i oferta, muntaràs el volum al pod de postgres-reserves i faràs la prova que portem prometent des del mòdul 2 —crear una reserva, esborrar el pod i trobar-la intacta—. Veuràs a més què passa en esborrar un PVC, per què de vegades es queda en Terminating, i per què un Deployment amb un PVC ReadWriteOnce no pot escalar.

1. Què és exactament un PersistentVolumeClaim
2. Anatomia de l'objecte camp a camp
3. L'algorisme d'aparellament
4. Per què pots rebre més espai del que has demanat
5. L'estat Pending i el seu diagnòstic
6. Consumir el PVC des del pod
7. El manifest definitiu de postgres-reserves
8. La demostració: les dades sobreviuen al pod
9. La relació 1:1 i el perill de dos pods sobre un RWO
10. Esborrar un PVC: finalitzadors i Terminating
11. Per què un Deployment amb PVC no escala

Un PersistentVolumeClaim és la petició d'emmagatzematge que fa una aplicació. L'analogia que millor funciona és la dels recursos de còmput que ja coneixes de 03-04:

Les seves dues propietats definitòries:

1. Té namespace. Viu al costat de l'aplicació que el fa servir, es veu afectat per les ResourceQuota del namespace (03-04) i desapareix si s'esborra el namespace. Un pod només pot muntar PVCs del seu propi namespace: no hi ha manera de referenciar un PVC d'un altre.
2. És l'única peça d'emmagatzematge que escriu l'equip d'aplicació. En un clúster amb aprovisionament dinàmic ben configurat, un desenvolupador no escriu mai un PersistentVolume; escriu PVCs.

Els camps, amb el seu significat exacte:

Dos camps mereixen un comentari a part.

Funciona igual que els selectors de 02-07, amb matchLabels i matchExpressions, i s'aplica sobre les etiquetes del PV. Serveix per expressar requisits que la capacitat no captura: matchExpressions: [{ key: tipus-disc, operator: In, values: ["ssd", "nvme"] }] significa "vull un disc ràpid, m'és igual quin".

Compte: si el PVC porta selector, l'aprovisionament dinàmic no el pot satisfer (un volum acabat de crear no tindrà aquestes etiquetes), així que el PVC quedarà Pending per sempre en un clúster que només faci servir StorageClasses. És un camp del món estàtic.

Lliga el PVC a un PV concret pel seu nom, saltant-se la cerca. És útil en una recuperació —"vull exactament aquell volum, el que té les dades"— i és el complement del claimRef que vas veure a 05-02: si tots dos objectes s'anomenen mútuament, la vinculació és determinista i ningú més no s'hi pot colar.

Quan crees un PVC sense volumeName, el controlador de PersistentVolume (part de kube-controller-manager) busca un PV candidat. El procés, en ordre:

Els cinc criteris, sense excepcions:

1. La mateixa storageClassName, comparada com a cadena exacta. "" i absent no són el mateix.
2. capacity.storage del PV ≥ requests.storage del PVC. Major o igual, mai menor.
3. Els accessModes del PVC han d'estar continguts en els del PV. Si el PVC demana ["ReadWriteMany"] i el PV ofereix ["ReadWriteOnce"], no hi ha tracte.
4. volumeMode idèntic.
5. El selector del PVC, si existeix, ha de casar amb les etiquetes del PV.

Entre tots els candidats, el controlador tria el de menor capacitat, per malgastar el mínim possible. I un cop decidit, la vinculació és bidireccional i exclusiva: s'escriu spec.claimRef al PV i spec.volumeName al PVC. A partir d'aquí tots dos objectes estan casats i cap altre PVC no pot fer servir aquest PV, encara que hi sobri espai.

De la regla 2 se'n deriva un comportament que sorprèn: requests.storage és un mínim, no una talla exacta. Si demanes 8 GiB i l'únic PV disponible en té 10, t'hi vincules i kubectl get pvc informa de CAPACITY: 10Gi. Conseqüències pràctiques:

• No hi ha devolució. Els 2 GiB de diferència es perden per a la resta del clúster: ningú més no pot fer servir aquest PV.
• La ResourceQuota compta el que s'ha demanat, no el que s'ha obtingut. Si el namespace té requests.storage: 20Gi de quota (03-04), el teu PVC de 8 GiB consumeix 8 GiB de quota encara que en gaudeixis de 10.
• En aprovisionament dinàmic això no passa: el volum es crea exactament de la mida demanada (arrodonida al mínim del proveïdor). És una raó més per preferir-lo.

El que mai no passa és el contrari: un PVC no es vincula mai a un PV més petit del que ha demanat.

Pending és l'estat que més veuràs i diagnosticaràs. Significa una sola cosa: el PVC no ha trobat volum. Les causes són poques i el mètode per distingir-les és sempre el mateix.

Els esdeveniments del final són la clau:

I el procediment de diagnòstic, en ordre, quan l'esdeveniment no n'hi ha prou:

Un Pending al PVC arrossega el pod: es queda en Pending també, amb l'esdeveniment del planificador pod has unbound immediate PersistentVolumeClaims. Diagnostica sempre el PVC primer; el pod només és el símptoma.

Al pod, el PVC es fa servir a través d'un volum del tipus persistentVolumeClaim. La mecànica volumes/volumeMounts de 05-01 no canvia en absolut:

Això és tot. El pod no esmenta el PersistentVolume enlloc, ni el proveïdor, ni el disc: només el nom del PVC. Aquesta indirecció és la que fa que el mateix manifest funcioni a minikube i en producció.

Ha arribat el moment d'esborrar el comentari "PROVISIONAL" que arrosseguem des de 02-05. Primer el PVC:

Bound per tots dos costats. La columna CLAIM del PV, que a la lliçó anterior estava buida, ara anomena el PVC amb el seu namespace. I el Deployment complet:

Quan un volum de blocs es formata amb ext4, la seva arrel conté un directori lost+found. I l'initdb de PostgreSQL es nega a inicialitzar un directori de dades que no estigui buit:

Hi ha dues maneres de resoldre-ho, i al manifest hi són totes dues, cosa que no és redundància sinó cinturó i tirants:

A Rutas Norte adoptem PGDATA com a mecanisme principal (ja venia del mòdul 3) perquè el subPath té un desavantatge seriós: un volum muntat amb subPath no es redimensiona automàticament en alguns controladors, cosa que complica l'expansió de 05-05. Si en tries només un, tria PGDATA per a PostgreSQL i reserva subPath per al cas general d'altres aplicacions.

El procés de PostgreSQL no corre com a root, sinó com l'usuari postgres (UID 999 a la imatge oficial). Un volum acabat de crear sol pertànyer a root:root, així que el procés no hi pot escriure:

securityContext.fsGroup: 999 fa que el kubelet canviï el grup propietari del volum a 999 i hi afegeixi permís d'escriptura en muntar-lo. És la solució estàndard i es tracta en profunditat a 08-02.

Aquest és el moment del mòdul. Apliquem i repetim exactament l'experiment de 05-01, que llavors va perdre totes les dades.

Creem una reserva fictícia:

I ara la prova. Esborrem el pod, igual que faria un rollout, un desallotjament o la caiguda del node:

Les reserves continuen allà, en un pod diferent, amb un altre nom i una altra IP. El deute del mòdul 2 està saldat. I pots verificar on viuen realment els bytes amb minikube ssh -p rutas-norte -- "sudo ls -l /data/postgres-reserves/pgdata": els fitxers són de l'UID 999 gràcies a fsGroup, i estan al directori del node, fora del contenidor.

Puja l'aposta si vols: esborra el Deployment sencer i torna a aplicar-lo. Les dades continuen, perquè el PVC i el PV no depenen del Deployment.

La relació entre PVC i PV és estrictament 1:1. Un PV vinculat no admet un segon PVC ni encara que li sobrin 9 GiB de 10. Comprova-ho:

Pending: l'únic PV d'aquesta classe està Bound. Esborra'l i continuem.

Ara la part perillosa. Diversos pods sí que poden muntar el mateix PVC, i és aquí on reapareix el parany de 05-02:

L'error del segon cas, que veuràs tan bon punt treballis amb un clúster de diversos nodes:

Aquest missatge és una protecció, no una avaria: el controlador de connexió impedeix que un disc de blocs es connecti a dues màquines. El greu és el primer cas, on ningú no et protegeix. Per això, per a qualsevol càrrega amb estat sobre ReadWriteOnce, la combinació obligatòria a Rutas Norte és:

• replicas: 1
• strategy: Recreate (acaba el pod vell abans de crear el nou)
• i, si el driver ho suporta, ReadWriteOncePod a PV i PVC.

Esborrar un PVC en ús és una operació que gairebé mai no surt com el principiant espera, i per bones raons.

L'ordre es queda penjada. I en un altre terminal, l'explicació:

kubernetes.io/pvc-protection és la protecció d'objecte d'emmagatzematge en ús. Mentre un pod actiu estigui fent servir el PVC, el finalitzador no es retira i l'objecte no s'esborra. És el mecanisme de finalitzadors de 01-06 aplicat a evitar que algú faci volar l'emmagatzematge d'una aplicació en marxa.

La solució és eliminar primer el consumidor, mai forçar el finalitzador:

Mai facis kubectl patch pvc ... -p '{"metadata":{"finalizers":null}}'. És la recepta que circula per internet per "desencallar" un PVC i el que aconsegueix és deixar el volum real connectat a un node sense cap objecte que el representi: un orfe invisible que s'ha de netejar a mà al proveïdor.

Quan el PVC desapareix, el destí del PV el decideix la seva política de reclamació (05-02):

En el nostre cas el PV queda Released, amb la columna CLAIM mostrant encara rutas-norte-dev/postgres-reserves-dades, i les reserves a dins. Per tornar a la situació operativa, apliques el rescat que ja coneixes i tornes a crear el PVC i el Deployment:

Aquesta és la raó de ser de Retain en una base de dades amb dades personals. Amb Delete, aquest exercici hauria acabat amb la pèrdua de totes les reserves de Rutas Norte.

Última peça, i és una limitació de fons, no un detall. Prova d'escalar:

En un clúster de diversos nodes veuries dos pods encallats amb Multi-Attach error. A minikube, que té un sol node, veuries una cosa pitjor: els tres pods arrenquen, munten el mateix directori de dades i PostgreSQL comença a queixar-se que ja hi ha una instància fent servir aquest directori (o, amb un altre motor menys protegit, corromp els fitxers en silenci).

La raó és estructural: tots els pods d'un Deployment comparteixen exactament la mateixa plantilla, inclosa la llista de volumes. Si la plantilla diu claimName: postgres-reserves-dades, les tres rèpliques demanen aquest mateix PVC. Un Deployment no sap donar a cada rèplica el seu propi volum.

La solució correcta és el StatefulSet, que incorpora un volumeClaimTemplate: crea un PVC per rèplica, amb nom estable i lligat a la identitat del pod, de manera que postgres-reserves-0 sempre retroba el seu volum. És l'objecte que obre el mòdul 6 a 06-01, i ara saps exactament quin problema ve a resoldre.

Mentrestant, la regla operativa per a Rutas Norte és clara i suficient: postgres-reserves és un Deployment d'una sola rèplica amb strategy: Recreate i un PVC ReadWriteOnce. Torna'l al seu lloc:

Consells:

1. Ordre de capçalera per veure oferta i demanda alhora:

   kubectl get pvc -A -o custom-columns=\
   NS:.metadata.namespace,PVC:.metadata.name,ESTAT:.status.phase,\
   PV:.spec.volumeName,DEMANAT:.spec.resources.requests.storage,CLASSE:.spec.storageClassName
   

2. Esbrina qui fa servir un PVC abans d'esborrar-lo, filtrant kubectl get pods -o json amb jq per .spec.volumes[]?.persistentVolumeClaim.claimName.
3. Anomena els PVC per la seva funció, no per la seva mida: postgres-reserves-dades, no pvc-10gi. La mida canvia amb l'expansió (05-05); la funció no.
4. Demana amb folgança però sense exagerar. En estàtic et vincules al PV més petit que et serveixi; en dinàmic crees exactament el que has demanat i el podràs expandir després, però mai reduir-lo.

Aplica el PVC i el Deployment definitiu de postgres-reserves de l'apartat 7 a rutas-norte-dev i demostra la persistència en tres nivells creixents:

1. Insereix tres reserves fictícies i esborra el pod amb kubectl delete pod.
2. Esborra el Deployment sencer i torna a aplicar-lo.
3. Esborra el PVC (havent esborrat abans el Deployment) i recupera les dades rescatant el PV.

Documenta a cada pas l'estat del PVC i del PV.

Crea aquests quatre PVC a rutas-norte-dev sabent que l'únic PV disponible és pv-postgres-reserves-10gi (10Gi, RWO, classe rutasnorte-rapida, etiqueta tipus-disc: ssd) i que ja està Bound. Per a cadascun, prediu si quedarà Bound o Pending i per què; després comprova-ho.

L'equip vol que redis-cache conservi el seu bolcat RDB entre reinicis per no perdre la memòria cau de disponibilitat de places a cada desplegament. Escriu el PVC (redis-cache-dades, 2 GiB) i el fragment del Deployment que el munta a /data, amb les etiquetes de Rutas Norte.

Després respon, raonant: és una bona decisió? Tingues en compte el que es va decidir a 03-05 sobre la naturalesa de redis-cache.

Exercici 1

Resum d'estats:

Si la política hagués estat Delete, el quart pas hauria destruït les dades definitivament.

Exercici 2

Els quatre queden Pending, cadascun per una raó diferent, i for x in a b c d; do kubectl describe pvc prova-$x -n rutas-norte-dev | tail -3; done ho confirma amb el mateix esdeveniment genèric FailedBinding: no persistent volumes available for this claim and no storage class is set — un recordatori que l'esdeveniment diu que no hi ha candidat, però no per què: això ho has de raonar tu amb els cinc criteris.

Perquè A es vinculés caldria alliberar abans el PV (esborrar el PVC de postgres-reserves i netejar el claimRef), cosa que il·lustra la limitació central de l'aprovisionament estàtic que resol 05-04.

Exercici 3

És una bona decisió? És acceptable, però no és prioritària i té contrapartides. A 03-05 vam classificar redis-cache com a Burstable precisament perquè és prescindible: el que guarda —la disponibilitat de places en memòria cau— es recalcula consultant postgres-reserves. El que es perd en reiniciar no és informació, és una estona de latència més alta.

A favor: després d'un desplegament, la memòria cau arrenca temperada i postgres-reserves no rep una allau de consultes; en un pont, aquest pic de recàlcul pot ser notable.

En contra, tres coses: el PVC el converteix en una càrrega amb estat, amb replicas: 1 i Recreate obligatoris; una memòria cau persistida pot servir dades caducades si l'RDB és de fa hores i la disponibilitat de places ha canviat, cosa que és pitjor que no tenir memòria cau; i si Redis guarda qualsevol dada personal de clients, aquest volum entra en l'àmbit de protecció de dades i de les còpies de seguretat de 05-06.

Decisió de Rutas Norte: no persistir redis-cache. Si el problema real és el pic de consultes després d'un desplegament, la solució correcta és un preescalfament controlat de la memòria cau en arrencar, no conservar dades de disponibilitat potencialment obsoletes.

El deute que arrossegava Rutas Norte des del mòdul 2 està saldat. Has escrit el PersistentVolumeClaim —l'objecte amb namespace que expressa la demanda de l'aplicació i l'única peça d'emmagatzematge que escriu un equip d'aplicació—, l'has vinculat al PV de la lliçó anterior i has vist la columna CLAIM omplir-se per tots dos costats amb Bound. I sobretot has fet la prova: tres reserves inserides, el pod esborrat, el Deployment esborrat, i les reserves intactes en un pod nou amb un altre nom i una altra IP. Els bytes, verificables al node, viuen fora del contenidor.

Saps com es produeix aquesta vinculació. L'algorisme d'aparellament exigeix cinc condicions —mateixa classe exacta, capacitat suficient, modes d'accés del PVC continguts en els del PV, volumeMode idèntic i selector que casi— i, entre els candidats, tria el menor, d'on surt el comportament que sorprèn: requests.storage és un mínim i pots rebre més espai del que has demanat, sense devolució possible i sense que la quota ho reflecteixi. Quan no hi ha candidat, el PVC queda Pending, i ja no ho diagnostiques a cegues: kubectl describe pvc i els seus esdeveniments distingeixen en segons entre "no hi ha PV compatible", "la classe no existeix", "esperant el primer consumidor" —que no és un error— i "quota excedida".

Domines el manifest definitiu de la base de dades i els tres paranys que l'envolten: el mountPath correcte (/var/lib/postgresql/data, no un nivell més amunt), el subdirectori via PGDATA o subPath que evita la fallada de lost+found, i el fsGroup sense el qual el procés no root no pot escriure al seu propi volum. Coneixes la relació 1:1 entre PVC i PV —un PV vinculat no admet un segon reclamant encara que li sobri espai— i la diferència entre les dues maneres de trencar-se amb ReadWriteOnce: en nodes diferents el Multi-Attach error et protegeix; al mateix node ningú no et protegeix, i per això replicas: 1 amb strategy: Recreate no és una preferència sinó un requisit. I saps esborrar sense destruir: el finalitzador kubernetes.io/pvc-protection deixa el PVC en Terminating mentre un pod el faci servir, es resol eliminant el consumidor i mai forçant el finalitzador; i el que li passa després al PV ho decideix la seva política de reclamació, on Retain t'ha permès recuperar les reserves d'un esborrat que amb Delete hauria estat definitiu.

Queda apuntat el sostre d'aquesta arquitectura: un Deployment té una sola plantilla, així que totes les seves rèpliques demanen el mateix PVC i per tant no escala; la resposta és el volumeClaimTemplate dels StatefulSets (06-01). I queda l'altre sostre, el que obria aquesta lliçó: continuem creant els PersistentVolumes a mà, un per un, amb el malbaratament, la feina manual i els orfes que això implica. La solució és que el clúster creï el volum exacte en el moment en què algú el demana, i l'objecte que ho fa possible és el que portem tres lliçons anomenant a storageClassName sense explicar: Classes d'Emmagatzematge.