Portem tres lliçons escrivint storageClassName: rutasnorte-rapida sense haver creat mai aquesta classe, i funcionava perquè l'aparellament estàtic només comparava cadenes de text. S'ha acabat el truc. La StorageClass és l'objecte que converteix aquesta cadena en una cosa amb conseqüències reals: el clúster crea el volum exacte en el moment en què algú el demana, amb el tipus de disc, la política de reclamació i les capacitats que la classe defineix. És el salt de l'aprovisionament estàtic al dinàmic, i canvia completament l'operació diària: ningú no torna a crear un PersistentVolume a mà. En aquesta lliçó desmuntaràs la StorageClass camp a camp —amb especial atenció a volumeBindingMode, responsable d'una de les fallades més cares i difícils de diagnosticar al núvol—, entendràs la classe per defecte i la diferència entre storageClassName: "" i ometre el camp, dissenyaràs les dues classes de Rutas Norte i veuràs aparèixer un PersistentVolume tot sol, sense escriure'l.

1. De l'aprovisionament estàtic al dinàmic
2. Anatomia de la StorageClass
3. provisioner: qui crea el volum
4. parameters: els detalls del disc
5. reclaimPolicy i allowVolumeExpansion
6. volumeBindingMode: el camp que evita un desastre
7. La classe per defecte i els seus paranys
8. storageClassName: "" davant d'ometre el camp
9. Les classes que porten minikube i els núvols gestionats
10. Les classes d'emmagatzematge de Rutas Norte
11. Pràctica: un PVC que crea el seu propi volum
12. Migrar un PVC d'una classe a una altra

Repassem el flux que has practicat fins ara i comparem-lo amb el que construiràs:

Els quatre problemes de l'estàtic que vam enumerar a 05-02 desapareixen de cop:

El canvi de mentalitat és aquest: la plataforma deixa d'oferir volums concrets i passa a oferir catàleg de serveis. "Tenim disc ràpid amb retenció i disc estàndard barat; demana el que necessitis i el clúster te'l crea."

Dues característiques estructurals abans d'entrar en els camps:

1. És un recurs de clúster (sense namespace), com el PersistentVolume. El gestiona l'equip de plataforma.
2. És pràcticament immutable. Llevat d'un grapat de camps (allowVolumeExpansion, les anotacions), una StorageClass no es pot modificar un cop creada: s'ha d'esborrar i tornar a crear. I compte, esborrar una StorageClass no afecta els PV ja creats, que continuen funcionant amb la configuració que tenien.

El provisioner identifica el component que atendrà les peticions d'aquesta classe. És l'única part veritablement obligatòria, juntament amb el nom.

Dos casos especials que convé reconèixer. kubernetes.io/no-provisioner es fa servir per a classes que no aprovisionen res, cosa que sona absurda fins que veus per a què serveix: agrupar volums local creats a mà i aprofitar el volumeBindingMode: WaitForFirstConsumer perquè la planificació respecti la ubicació del disc. I els provisioners amb prefix kubernetes.io/ (com kubernetes.io/aws-ebs) són els antics controladors in-tree, eliminats del codi de Kubernetes: en un clúster 1.30+ no funcionen, i si heretes manifests amb aquests noms cal migrar-los al driver CSI equivalent.

Per saber quins drivers CSI hi ha realment instal·lats al teu clúster: kubectl get csidrivers.

parameters és un mapa opac per a Kubernetes: es passa tal qual al provisioner, que és qui l'interpreta. Per això les claus vàlides depenen completament del driver, i una clau mal escrita no dona error en crear la classe, sinó en crear el primer PVC.

Exemples reals per proveïdor:

A Google Cloud les claus equivalents són type (de pd-standard a pd-extreme) i replication-type: regional-pd, que replica el disc entre dues zones; a Azure són skuName (Standard_LRS, StandardSSD_LRS, Premium_LRS, UltraSSD_LRS) i cachingmode.

Un paràmetre que no ha de faltar en cap classe de Rutas Norte és el de xifratge en repòs. postgres-reserves guarda nom, DNI, telèfon i correu dels clients; aquest disc ha d'estar xifrat, igual que ja ho estan els Secrets a etcd des de 03-02. A AWS és encrypted: "true"; a Azure i Google el xifratge en repòs ve activat per defecte i el que es configura és la clau.

Els PV creats per aquesta classe hereten aquesta política. Els valors són els de 05-02: Retain o Delete. I el valor per defecte, si no el poses, és Delete.

Això mereix un avís en majúscules: les classes per defecte de tots els núvols gestionats fan servir Delete. És a dir, en un clúster acabat de crear, si el teu equip esborra el PVC d'una base de dades —o el namespace que el conté—, el disc es destrueix. Comprova-ho sempre primer de tot en arribar a un clúster nou:

Com que la classe és gairebé immutable, no li pots canviar la política; el que es fa és crear una classe pròpia amb Retain per a les dades que importen. Això és exactament el que farem amb rutasnorte-rapida.

Declara si els PVC d'aquesta classe es poden fer més grans després de creats. És dels pocs camps que sí que es poden modificar en calent, amb kubectl patch sc rutasnorte-rapida -p '{"allowVolumeExpansion": true}'.

Posa'l a true en tota classe destinada a dades que creixen. El cost és zero i l'alternativa —migrar les dades a un volum més gran amb la base de dades parada— és una operació de matinada. La mecànica de l'expansió es detalla a 05-05, inclòs el fet que no es pot reduir.

És el camp menys comprès de la StorageClass i el que més incidents causa al núvol. Té dos valors:

Rutas Norte té el seu clúster de producció repartit en tres zones de disponibilitat: eu-west-1a, eu-west-1b i eu-west-1c. Amb volumeBindingMode: Immediate:

El pod es queda Pending indefinidament amb un esdeveniment del tipus:

I no hi ha arranjament còmode: el disc ja existeix a la zona equivocada i no es mou. Cal esborrar el PVC, esborrar el disc i tornar a començar, confiant en la sort.

Amb WaitForFirstConsumer l'ordre s'inverteix: el planificador decideix primer, considerant CPU, memòria, afinitats, taints i toleracions (06-05), i després l'aprovisionador crea el disc a la zona d'aquell node. El conflicte és impossible per construcció.

L'efecte secundari que cal reconèixer per no espantar-se: amb WaitForFirstConsumer, un PVC acabat de crear es queda en Pending a propòsit fins que existeixi un pod que el faci servir, i kubectl describe pvc ho diu amb l'esdeveniment WaitForFirstConsumer: waiting for first consumer to be created before binding.

Això no és un error. És el mode funcionant. Tan bon punt creïs el Deployment, el PVC passa a Bound en segons.

Regla de Rutas Norte: WaitForFirstConsumer a totes les classes, sense excepció. L'únic escenari on Immediate és preferible és un clúster d'una sola zona amb emmagatzematge de xarxa uniforme, i ni tan sols allà aporta res.

Un clúster pot tenir una StorageClass marcada com a per defecte. Quan un PVC omet el camp storageClassName, un controlador d'admissió li injecta el nom d'aquesta classe.

Es marca amb l'anotació storageclass.kubernetes.io/is-default-class: "true" al metadata de la classe, i a la sortida de kubectl get sc apareix assenyalada com standard (default). Canviar-la són un parell de kubectl patch:

Res no impedeix marcar-ne dues, i no és un error de configuració detectable a simple vista. El comportament és el següent: el controlador d'admissió tria la creada més recentment i ignora les altres. En versions anteriors arribava a rebutjar el PVC. En qualsevol cas és una configuració incorrecta, i el seu símptoma és dels pitjors: els PVC funcionen, però uns acaben en discos ràpids i cars i d'altres en discos lents, sense patró aparent.

Aleshores un PVC que ometi storageClassName no rep cap classe i es queda Pending per sempre, buscant un PV estàtic que probablement no existeix, amb l'esdeveniment ProvisioningFailed: no persistent volumes available for this claim and no storage class is set.

Aquesta distinció val una secció pròpia perquè és subtil, s'oblida constantment i produeix fallades desconcertants.

La cadena buida és la forma explícita de dir: "desactiva l'aprovisionament dinàmic per a aquest PVC; vull un PV estàtic concret". És el que cal escriure quan restaures un volum preexistent i no vols que el clúster te'n creï un de nou i buit al costat. L'error clàssic i el seu símptoma: en un clúster amb classe per defecte, algú crea un PV estàtic sense classe per restaurar unes dades, escriu un PVC ometent storageClassName, i en lloc de vincular-se al PV amb les dades, el clúster aprovisiona un volum nou i buit. El PVC queda Bound, l'aplicació arrenca sense errors i la base de dades està buida. És una fallada silenciosa, i la protecció és doble: storageClassName: "" i volumeName apuntant al PV concret.

El teu clúster de pràctiques ja té una classe, proveïda per l'addon storage-provisioner que vas activar a 01-04:

k8s.io/minikube-hostpath crea directoris sota /tmp/hostpath-provisioner/<namespace>/<nom-pvc> dins de la VM. Les seves limitacions són les esperables d'un clúster d'un node: no admet expansió ni snapshots, i la seva política és Delete. Serveix perfectament per aprendre el flux, però no per practicar el de 05-05; allà instal·larem el driver CSI de hostpath, que sí que les suporta.

Taula comparativa orientativa de les classes típiques que trobaràs:

Els preus i rendiments varien i no té sentit memoritzar-los; el que sí que convé retenir és el patró: cada núvol ofereix com a mínim un disc de blocs estàndard, un de premium i un sistema de fitxers compartit més car per a ReadWriteMany, i les classes preinstal·lades vénen amb Delete.

Amb tot l'anterior, el disseny del catàleg de la plataforma: dues classes, cadascuna amb una intenció clara.

Per què Retain a la classe de la base de dades. És la decisió més important del catàleg i convé poder defensar-la:

• El PVC de postgres-reserves conté nom, DNI, telèfon i correu de tots els clients i totes les reserves venudes. La seva pèrdua no és una incidència tècnica: és una aturada de negoci i un incident de dades personals.
• Els mecanismes que poden esborrar un PVC sense que ningú ho pretengui són molts i quotidians: un kubectl delete namespace equivocat (02-06), un kubectl delete -f k8s/ sobre el directori sencer, una eina de GitOps que sincronitza i "poda" recursos que ja no són a Git (10-05), un script de neteja d'entorns.
• Amb Delete, qualsevol d'aquests accidents destrueix el disc de manera irreversible. Amb Retain, deixa un PV en Released que es rescata en dos minuts amb el kubectl patch de 05-02.
• El cost de Retain és real però petit: volums orfes que s'han de netejar a mà i que es continuen facturant. Es compensa amb una revisió mensual de PV en Released.

La regla general que se'n deriva: Retain per a dades de negoci, Delete per a dades reconstruïbles.

És la classe per defecte, i aquesta elecció també és deliberada: si algú crea un PVC sense pensar, que caigui a la classe barata i esborrable, no a la cara i retinguda. La classe de la base de dades s'ha de demanar explícitament, cosa que obliga a una decisió conscient.

A minikube no existeix ebs.csi.aws.com. Per practicar, es creen les mateixes classes amb el provisioner local. Fixa't que el nom no canvia: és l'únic que veuen els manifests de l'aplicació, i per això el PVC de postgres-reserves és idèntic a minikube i en producció.

Que la configuració de dev difereixi de la de producció en parameters i provisioner és normal i correcte: el que ha de romandre idèntic és el contracte, és a dir, el nom de la classe i la seva política de reclamació.

Apliquem les classes i comprovem l'efecte. Primer, la classe per defecte al seu lloc:

Ara, i això és l'important: esborrem el PersistentVolume estàtic que vam crear a mà a 05-02, comprovem amb kubectl get pv que no en queda cap (No resources found) i creem un PVC nou sense cap PV esperant.

Fixa't en els quatre detalls que resumeixen la lliçó:

1. Ha aparegut un PersistentVolume que tu no vas escriure. L'aprovisionador el va crear en veure el PVC.
2. El seu nom és pvc-<uid-del-pvc>: si un nom de PV comença per pvc-, és dinàmic.
3. CAPACITY: 3Gi, exactament el demanat, i RECLAIM POLICY: Delete, heretada de la classe per defecte.

I la comprovació que el PVC de la base de dades, en demanar la classe rutasnorte-rapida, obté un volum amb Retain:

Dos volums, dues polítiques diferents, cap escrit a mà. Aquest és el catàleg funcionant.

Última peça operativa, i la resposta curta és contundent: no es pot canviar la classe d'un PVC existent. El camp storageClassName és immutable un cop vinculat, i amb raó: la classe determina el disc físic, i un disc no canvia de tipus per editar un YAML. Un kubectl patch pvc ... -p '{"spec":{"storageClassName":"rutasnorte-rapida"}}' s'estavella contra:

El missatge a més t'avança l'única cosa que sí que es pot canviar: resources.requests, és a dir, l'expansió de 05-05. El procediment real de migració implica copiar les dades, i hi ha tres variants segons el que et puguis permetre:

El pas 6 no és opcional. No esborris el PVC d'origen fins haver verificat les dades al destí, i encara així deixa'l uns dies. Recorda que si la seva classe és Retain, esborrar-lo deixa el PV en Released recuperable.

Per a una base de dades sol ser més net: pg_dump de l'origen, crear el PVC nou buit, arrencar PostgreSQL sobre ell i restaurar amb pg_restore. És més lent però valida les dades pel camí (una còpia binària arrossegaria una corrupció; un bolcat lògic no es restaura si està corrupte). Es detalla a 05-06.

Requereix replicació a nivell d'aplicació: aixecar una rèplica de PostgreSQL sobre el volum nou, sincronitzar-la i promoure-la. És un procediment de base de dades, no de Kubernetes, i es delega en un operador (06-07).

Consells:

1. Documenta cada classe amb una anotació (rutasnorte.example/descripcio). Qui tria la classe sol ser un desenvolupador que no sap què hi ha a sota, i aquesta línia li estalvia preguntar.
2. Audita el catàleg el primer dia en qualsevol clúster amb un kubectl get sc -o custom-columns=... que mostri alhora provisioner, reclaimPolicy, allowVolumeExpansion, volumeBindingMode i l'anotació de classe per defecte.
3. Poques classes i amb noms que diguin la intenció. rutasnorte-rapida i rutasnorte-estandar s'entenen; sc-gp3-6000iops-encrypted obliga a saber d'AWS i lliga el nom al proveïdor.
4. Els noms de classe són el contracte entre entorns. Mantén els mateixos noms a dev, pre i pro encara que a sota hi hagi provisioners diferents: així els manifests de l'aplicació són idèntics.

Al teu minikube:

1. Crea rutasnorte-rapida i rutasnorte-estandar amb el provisioner local, deixant rutasnorte-estandar com a classe per defecte i traient la marca a standard.
2. Verifica amb una sola ordre que només hi ha una classe per defecte.
3. Crea un PVC d'1 GiB sense storageClassName i comprova en quina classe acaba i amb quina política.
4. Crea un altre PVC d'1 GiB amb storageClassName: rutasnorte-rapida i compara la política de reclamació de tots dos PV.
5. Esborra els dos PVC i explica per què un dels PV desapareix i l'altre no.

Un company de l'equip de plataforma ha creat aquesta classe per al clúster de producció, que té nodes a eu-west-1a, eu-west-1b i eu-west-1c:

L'endemà, el pod de postgres-reserves porta 40 minuts en Pending amb aquest esdeveniment:

Explica què ha passat exactament, per què el PVC sí que està Bound mentre el pod no arrenca, com es resol l'incident avui i quins tres canvis cal fer a la classe perquè no torni a passar.

L'equip ha de restaurar les dades de postgres-reserves de preproducció. Un administrador ha creat a mà un PV anomenat pv-restauracio-pre (20 GiB, Retain, sense storageClassName) que apunta al volum amb les dades recuperades. Un desenvolupador aplica aquest PVC:

El PVC queda Bound en segons, PostgreSQL arrenca sense errors… i la base de dades està buida. Explica què ha passat i escriu el PVC correcte.

Exercici 1

El PVC sense classe va rebre rutasnorte-estandar per injecció del controlador d'admissió (comprova-ho amb kubectl get pvc prova-defecte -o yaml: el camp apareix escrit a l'objecte, encara que tu no l'hi posessis). I en esborrar tots dos PVC (pas 5), kubectl get pv només retorna pvc-e5f6a7b8-... 1Gi Retain Released rutas-norte-dev/prova-rapida.

Només en queda un. El de rutasnorte-estandar tenia Delete i es va destruir amb el seu PVC; el de rutasnorte-rapida va heretar Retain de la seva classe i va quedar en Released amb les dades a dins. És exactament la protecció que buscàvem per a la base de dades. Neteja: kubectl delete pv pvc-e5f6a7b8-....

Exercici 2

Què ha passat. La classe fa servir volumeBindingMode: Immediate (i a més és el valor per defecte, així que n'hi ha prou d'ometre'l per caure al parany). En crear-se el PVC, l'aprovisionador d'EBS va crear el disc immediatament, triant una zona sense cap informació sobre on acabaria el pod —diguem eu-west-1c—. El PV resultant porta una nodeAffinity que exigeix topology.kubernetes.io/zone=eu-west-1c.

Per què el PVC està Bound i el pod no arrenca. Són dues decisions independents: la vinculació PVC-PV la fa el controlador de PersistentVolume i només mira capacitat, modes i classe; la col·locació del pod la fa el planificador, que a més de l'afinitat del volum avalua CPU, memòria i taints. El PVC està perfectament vinculat; el que no existeix és un node que satisfaci alhora la zona del disc i els recursos del pod. Els 6 node(s) had volume node affinity conflict són els nodes de les altres dues zones, i els 3 Insufficient memory són els d'eu-west-1c, que sí que valen per zona però estan plens —postgres-reserves demana 2 GiB amb QoS Guaranteed (03-05)—.

Com es resol avui. Cal decidir entre dos camins. L'opció A és fer lloc a eu-west-1c —localitza els nodes amb kubectl get nodes -L topology.kubernetes.io/zone, mira els seus Allocated resources amb kubectl describe node, i allibera càrrega o afegeix-hi un node—. L'opció B és refer el volum: esborrar el Deployment i el PVC de rutas-norte-pro, corregir la classe i tornar a aplicar.

L'opció B només és acceptable perquè el volum encara no té dades. Si en tingués, l'única sortida seria una restauració des de còpia de seguretat (05-06), perquè un disc EBS no canvia de zona.

Els tres canvis a la classe:

1. volumeBindingMode: WaitForFirstConsumer, que inverteix l'ordre: primer planifica el pod, després crea el disc a la seva zona. Elimina el conflicte per construcció.
2. reclaimPolicy: Retain, perquè la classe que faltava posava Delete per defecte i això és la base de dades de producció.
3. allowVolumeExpansion: true, per no haver de repetir aquesta maniobra el dia que els 200 GiB es quedin curts.

Recorda que la StorageClass no es pot editar: s'ha d'esborrar i recrear. Els PV ja existents conserven la configuració amb què van néixer.

Exercici 3

Què ha passat. El PVC omet storageClassName. El controlador d'admissió li va injectar aleshores la classe per defecte del clúster (rutasnorte-estandar). A partir d'aquí, el PV pv-restauracio-pre va quedar descartat com a candidat —està sense classe, i la classe ha de coincidir exactament— i al seu lloc l'aprovisionador va crear un volum nou, buit i de 20 GiB. El PVC es va vincular a aquell volum nou en segons, PostgreSQL va trobar un directori buit, va executar initdb i va arrencar tan content: una base de dades nova i buida, sense ni un sol error als registres.

És la fallada més perillosa de la lliçó precisament perquè no falla res. I hi ha un dany col·lateral: el PV amb les dades continua Available, però si ningú no se n'adona i l'aplicació comença a operar sobre la base buida, es perd la finestra de restauració.

El PVC correcte porta doble protecció:

I el procediment segur de restauració, per no repetir l'incident:

El pas 2 —comprovar volumeName abans d'arrencar l'aplicació— és la verificació que hauria evitat l'incident.

Has fet el salt que canvia l'operació diària d'un clúster: de l'aprovisionament estàtic, on un humà crea cada PersistentVolume per endavant amb el seu malbaratament, les seves esperes i els seus orfes, al dinàmic, on l'equip d'aplicació crea un PVC i el volum exacte apareix en segons. Has vist néixer un PV que no vas escriure, amb el nom pvc-<uid> que delata el seu origen, de la mida justa demanada i amb la política heretada de la seva classe.

Coneixes la StorageClass camp a camp. El provisioner, que identifica el driver —CSI en producció, k8s.io/minikube-hostpath en pràctiques, i mai els kubernetes.io/* in-tree, ja eliminats—. Els parameters, opacs per a Kubernetes i específics de cada driver, on va el tipus de disc, les IOPS i, obligatòriament a Rutas Norte, el xifratge en repòs. La reclaimPolicy que hereten els PV, amb l'avís que cal comprovar el primer dia en qualsevol clúster nou: les classes per defecte dels núvols vénen en Delete, així que esborrar un PVC esborra el disc. L'allowVolumeExpansion, que no costa res i evita una matinada de migració. I, sobretot, el volumeBindingMode: Immediate crea el disc a cegues i el pot deixar en una zona on el pod no hi cap, produint un volume node affinity conflict irreparable sense restaurar de còpia; WaitForFirstConsumer inverteix l'ordre —primer planifica el pod, després crea el disc on aquell pod és— i elimina el problema per construcció, al preu d'un Pending deliberat que ja no t'espanta.

Domines la classe per defecte: la seva anotació storageclass.kubernetes.io/is-default-class, el desordre que produeix tenir-ne dues i el Pending etern de no tenir-ne cap. I distingeixes amb precisió els dos silencis: ometre storageClassName deixa que t'injectin la classe per defecte, mentre que storageClassName: "" significa "sense classe, res de dinàmic, vull un PV estàtic". Aquesta diferència de dues cometes és el que separa una restauració correcta d'una base de dades buida que arrenca sense ni un sol error, com vas veure al tercer exercici.

I has dissenyat el catàleg de la plataforma: rutasnorte-rapida amb Retain per a postgres-reserves, perquè el disc guarda dades personals de clients i hi ha massa maneres quotidianes d'esborrar un PVC sense voler; i rutasnorte-estandar amb Delete com a classe per defecte, perquè un descuit caigui sempre en el que és barat i esborrable i la classe protegida s'hagi de demanar a consciència. Els noms es mantenen idèntics a dev, pre i pro encara que a sota canviïn el provisioner i els paràmetres: el nom de la classe és el contracte entre entorns. I saps que la classe d'un PVC és immutable, de manera que migrar significa copiar les dades, amb aturada i amb verificació abans d'esborrar res.

Queda per obrir la caixa negra. Hem dit "l'aprovisionador crea el volum" sense explicar qui és, com s'assabenta que hi ha un PVC pendent, com connecta el disc al node i com el munta al pod. I hi ha dues capacitats que la StorageClass anuncia però que encara no hem fet servir: l'expansió que habilita allowVolumeExpansion i els snapshots, imprescindibles abans de tocar l'esquema d'una base de dades en producció. Tot això és la maquinària de la Container Storage Interface, i és la lliçó següent: Aprovisionament Dinàmic, Expansió i Snapshots.