La lliçó anterior va acabar amb un PersistentVolume que va aparèixer tot sol, i amb una caixa negra sense obrir: vam dir "l'aprovisionador crea el volum" sense explicar qui és aquest aprovisionador, com s'assabenta que hi ha un PVC pendent, com connecta el disc a un node i com acaba muntat al contenidor. Aquesta maquinària es diu CSI, la Container Storage Interface, i entendre-la és el que separa qui aplica manifests de qui pot diagnosticar per què un pod porta vint minuts en ContainerCreating. A més, la StorageClass anunciava dues capacitats que encara no hem fet servir: l'expansió d'un volum en marxa i els snapshots, imprescindibles abans de tocar l'esquema d'una base de dades en producció. En aquesta lliçó les posaràs a treballar sobre postgres-reserves, i tancaràs amb l'advertiment que més incidents evita: un snapshot no és una còpia de seguretat.

1. Quin problema va resoldre CSI
2. L'arquitectura: connector de controlador i connector de node
3. Els sidecars i els objectes CSIDriver i CSINode
4. El flux complet d'un volum, d'extrem a extrem
5. Preparar el clúster de pràctiques
6. Expansió de volums: requisits i mecànica
7. Expansió en línia davant d'expansió amb reinici
8. Snapshots: els tres objectes
9. Crear un snapshot de postgres-reserves
10. Restaurar des d'un snapshot amb dataSource
11. Clonar un PVC
12. L'advertiment: consistència i què NO és un snapshot

Abans del 2018, el codi que parlava amb AWS EBS, amb Google Persistent Disk, amb Ceph o amb NetApp vivia dins del repositori de Kubernetes. Se'ls anomenava controladors in-tree, i el model tenia tres problemes greus:

CSI (Container Storage Interface) és una especificació estàndard —no exclusiva de Kubernetes: la fan servir també Mesos i Nomad— que defineix un contracte gRPC entre l'orquestrador i el sistema d'emmagatzematge. El proveïdor implementa aquest contracte en un component propi, l'empaqueta com a contenidor i el desplega al clúster, com qualsevol altra càrrega de treball. El resultat: els controladors in-tree van quedar obsolets i van ser eliminats (kubernetes.io/aws-ebs, kubernetes.io/gce-pd, kubernetes.io/azure-disk ja no existeixen a 1.30+). Avui tot l'emmagatzematge de xarxa passa per CSI, i hi ha més d'un centenar de drivers disponibles.

Un driver CSI es desplega sempre en dues meitats, perquè les operacions d'emmagatzematge són de dues naturaleses diferents:

La separació no és capriciosa: crear un disc és una crida a una API remota que només s'ha de fer un cop des d'un sol lloc; muntar-lo és una operació local que només pot fer la màquina on és el pod.

Aquí hi ha la part elegant del disseny. El driver del proveïdor no parla amb l'API de Kubernetes: només implementa el contracte gRPC de CSI. Qui observa l'API i tradueix són uns contenidors auxiliars mantinguts pel projecte Kubernetes, els sidecars, que es despleguen al costat del driver al mateix pod (el patró multicontenidor de 06-04).

Hi ha a més un livenessprobe que sonda la salut del driver. Gràcies a aquest disseny, un fabricant només escriu la lògica del seu emmagatzematge; tota la integració amb Kubernetes ja està feta i provada. I hi ha dos objectes de l'API que descriuen l'estat d'aquesta infraestructura:

Declara les capacitats d'un driver instal·lat. El clúster el consulta per saber què li pot demanar.

Es crea automàticament per cada node i registra quins drivers hi ha disponibles allà i amb quin identificador coneix el proveïdor aquella màquina.

Aquest Count és una limitació molt real en producció: AWS, per exemple, restringeix el nombre de volums EBS connectables a una instància. Quan s'esgota, els pods es queden Pending amb node(s) exceed max volume count, un missatge que ara saps d'on surt.

Aquest és el diagrama que cal retenir: què passa exactament des que apliques un PVC fins que el procés escriu el seu primer byte.

Les cinc fases, amb el seu nom tècnic i el símptoma de quan fallen:

Dos detalls que valen or en un diagnòstic. NodeStageVolume passa un cop per node; NodePublishVolume, un cop per pod, i per això un volum pot estar "muntat" i tot i així el pod no veure'l: són dos muntatges diferents. I pots seguir la fase de connexió a l'API amb kubectl get volumeattachments, cosa que rarament se sap: mostra una fila per volum connectat, amb el driver, el PV, el node i una columna ATTACHED; si aquesta columna és false durant minuts, el problema és al connector de controlador, no al node.

El provisioner de minikube (k8s.io/minikube-hostpath) no admet expansió ni snapshots, així que per a aquesta lliçó instal·larem el driver CSI de hostpath, que sí que les implementa. És un driver de referència per a proves —no el facis servir en producció— però reprodueix fidelment el comportament d'un CSI real.

Punt important: els CRDs de snapshot i el snapshot-controller no formen part de Kubernetes. En un clúster gestionat solen venir instal·lats, però en un de propi cal posar-los. Si intentes crear un VolumeSnapshot sense ells, l'error és no matches for kind "VolumeSnapshot" in version "snapshot.storage.k8s.io/v1".

Ara reescrivim rutasnorte-rapida sobre aquest driver —cal esborrar-la i recrear-la, perquè les StorageClass no s'editen—, mantenint el contracte (nom i Retain) i guanyant les dues capacitats:

Arriba el dia que 10 GiB es queden curts: la taula de reserves ocupa 8,4 GiB i el disc va camí d'omplir-se en dues setmanes. L'expansió permet fer més gran el volum sense migrar les dades.

Els requisits, els tres alhora: la StorageClass ha de tenir allowVolumeExpansion: true, el driver CSI ha d'implementar la capacitat (ControllerExpandVolume) i el PVC ha d'estar Bound.

I la restricció absoluta: un volum no es pot reduir. Ni amb un PVC nou, ni amb kubectl edit, ni de cap manera; Kubernetes rebutja la petició amb spec.resources.requests.storage: Forbidden: field can not be less than previous value.

La raó és de seguretat de dades: reduir un sistema de fitxers exigeix moure'l i compactar-lo, i cap proveïdor no garanteix fer-ho sense risc. Conseqüència pràctica: demana amb cap, perquè només pots pujar. Reduir significa crear un PVC menor i copiar, amb aturada, com a 05-04.

S'edita spec.resources.requests.storage del PVC —mai del PV—. La via ràpida és un patch; la bona, editar el manifest a Git i aplicar-lo, com mana el model declaratiu de 01-06:

I la comprovació que de debò importa, dins del contenidor:

20 GiB, amb els 8,4 GiB de dades intactes i sense haver aturat la base de dades.

L'expansió passa en dues etapes, i d'aquí les dues condicions que veuràs al PVC:

Si el PVC es queda amb la condició FileSystemResizePending, el disc ja és més gran però el sistema de fitxers no ho sap: df -h dins del contenidor continua mostrant la mida antiga. La solució és recrear el pod, i el kubelet executa NodeExpandVolume durant el muntatge:

Dos avisos operatius. Primer, subPath pot impedir l'expansió automàtica del sistema de fitxers en alguns drivers: és la raó, anunciada a 05-03, per la qual a postgres-reserves preferim la variable PGDATA al subPath. I segon, vigila l'ompliment abans que sigui urgent: Kubernetes exposa kubelet_volume_stats_available_bytes i kubelet_volume_stats_capacity_bytes, i una alerta al 75 % dona marge de sobres (07-03 i 07-04).

Un snapshot és una còpia puntual del contingut d'un volum, feta pel sistema d'emmagatzematge. La seva gran virtut és que és gairebé instantània —els sistemes moderns fan servir còpia sobre escriptura, així que no dupliquen les dades en crear-la— i que permet crear volums nous a partir d'ella. El model d'objectes és un calc exacte del dels volums, cosa que fa que ja te'l sàpigues:

I la VolumeSnapshotClass, anàloga a la StorageClass:

deletionPolicy decideix què passa amb el snapshot real en esborrar l'objecte VolumeSnapshot: Delete el destrueix; Retain el conserva, i és l'elecció coherent amb rutasnorte-rapida per als snapshots de la base de dades.

Requisits previs, que ja vas cobrir a l'apartat 5: els tres CRDs, el snapshot-controller i el sidecar external-snapshotter al costat del driver.

L'escenari real: demà es desplega la versió 3.0 d'api-reserves, que inclou una migració d'esquema —afegeix columnes a reserves i reescriu la taula de clients—. Si la migració surt malament, cal tornar enrere en minuts, i un rollout undo del Deployment (02-04) no desfà els canvis a la base de dades. Un snapshot previ sí.

Estat de partida: tres reserves a la taula, segons kubectl exec ... psql -c "SELECT count(*) FROM reserves;". El manifest del snapshot:

READYTOUSE: true és la columna que cal mirar: fins que no ho sigui, el snapshot no serveix per restaurar. El describe amplia amb el Bound Volume Snapshot Content Name, la Creation Time, el Restore Size i els esdeveniments CreatingSnapshot i SnapshotCreated del snapshot-controller.

Les anotacions amb el motiu, el responsable i el ticket no són adorn: un clúster acumula snapshots, cadascun costa diners, i sense aquesta informació ningú no s'atreveix a esborrar-ne cap. És l'aplicació directa del que vas aprendre a 02-07.

Ara simulem el desastre. La migració s'executa i va malament: esborra reserves.

La restauració no sobreescriu el volum original: crea un PVC nou el dataSource del qual apunta al snapshot. És una diferència crucial, perquè conserva l'evidència de l'estat danyat per poder analitzar-lo després.

En aplicar-lo apareix un segon PVC Bound al costat de l'original, amb el seu propi PV. I apuntem el Deployment al volum restaurat:

Les tres reserves han tornat. Quatre condicions perquè una restauració funcioni:

1. El PVC nou ha de demanar com a mínim el restoreSize del snapshot. Menys, i falla.
2. Ha de fer servir la mateixa StorageClass (o almenys el mateix driver): un snapshot no creua sistemes d'emmagatzematge.
3. El snapshot ha d'estar READYTOUSE: true.
4. El snapshot ha d'existir al mateix namespace que el PVC nou. Per creuar namespaces cal importar el VolumeSnapshotContent a mà.

Un cas germà i molt útil: crear una còpia d'un volum directament des d'un altre PVC, sense passar per un snapshot. Canvia només el kind del dataSource:

La clonació és la forma neta de donar a l'equip de desenvolupament una còpia de les dades de preproducció per assajar una migració. I compte amb la lletra petita: aquest clon conté dades personals reals de clients —nom, DNI, telèfon, correu—. Un clon per a proves és un tractament de dades igual que l'original i exigeix les mateixes proteccions, o millor, una anonimització prèvia. Es reprèn a 05-06.

Una limitació tècnica que convé saber: clonar un PVC mentre la base de dades està escrivint produeix una còpia equivalent a la d'un tall de llum, amb els mateixos problemes de consistència de l'apartat següent.

Aquest és l'advertiment central de la lliçó. Un snapshot fotografia els blocs del disc, no l'estat lògic de l'aplicació. I una base de dades en marxa té, en qualsevol instant, pàgines modificades en memòria que encara no s'han escrit al disc, transaccions a mig confirmar, i escriptures al WAL que el sistema operatiu té a la seva memòria cau i no ha bolcat.

El snapshot resultant equival a l'estat del disc després d'un tall de corrent. La bona notícia és que PostgreSQL està preparat per a això: en arrencar sobre aquell volum executa una recuperació per WAL i arriba a un estat coherent. La dolenta és doble: aquesta recuperació pot trigar minuts en una base gran, i perdràs les transaccions que no van arribar al disc. I amb motors menys robustos, o amb dades repartides entre diversos volums que es fotografien per separat, el resultat pot ser directament inservible. La solució professional és coordinar el snapshot amb l'aplicació: deixar-la en un estat consistent just abans, i alliberar-la just després.

Kubernetes ofereix el mecanisme per al tercer: els hooks de pre i post que executen una ordre dins del contenidor abans i després del snapshot. No és una capacitat nativa del VolumeSnapshot, sinó de les eines de còpia de seguretat, i per això s'estudia a la lliçó següent, 05-06, amb Velero.

És l'afirmació més important del mòdul i l'error conceptual que més dades ha destruït:

Si s'esborra el compte del núvol, si la zona es perd, si algú amb credencials d'administrador destrueix el projecte, els snapshots se'n van amb tota la resta. Són una eina magnífica per al que són —desfer un canvi local, ràpid, en minuts—, però no són una estratègia de recuperació davant de desastres. Regla de Rutas Norte: els snapshots són la xarxa de seguretat de curt termini —abans d'una migració, d'un desplegament arriscat, de tocar producció—, amb retenció de dies; la còpia de seguretat de veritat va a un magatzem d'objectes extern i és el que es construeix a la lliçó següent.

Consells:

1. Abans de qualsevol canvi irreversible —migració d'esquema, actualització major del motor, script de neteja— fes un snapshot i anota'l amb el ticket. Costa segons i ha salvat carreres.
2. Verifica que un snapshot serveix, no que existeix. Un snapshot no provat no és res. Restaura periòdicament en un PVC de prova i comprova les files.
3. Vigila l'ompliment amb antelació amb un df -h sobre el punt de muntatge, i automatitza-ho amb alertes al 75 % a 07-04.
4. Diagnostica l'emmagatzematge per fases. Si un pod no arrenca pel volum, mira en aquest ordre: kubectl describe pvc (provisió), kubectl get volumeattachments (connexió), kubectl describe pod (muntatge) i els registres del pod del driver CSI a kube-system.

Amb el driver CSI de hostpath instal·lat i rutasnorte-rapida recreada amb allowVolumeExpansion: true:

1. Comprova la mida actual del volum de postgres-reserves des de dins del contenidor.
2. Amplia'l de 10 GiB a 20 GiB editant el PVC.
3. Segueix les condicions del PVC fins que acabi i verifica la mida amb df -h.
4. Intenta reduir-lo a 5 GiB i transcriu l'error.
5. Comprova que les reserves continuen allà.

Assaja el procediment complet que faràs servir en producció:

1. Insereix cinc reserves fictícies a postgres-reserves.
2. Crea un VolumeSnapshot anomenat snap-practica amb les anotacions de motiu, responsable i ticket. Espera a READYTOUSE: true.
3. Provoca el desastre: DROP TABLE reserves.
4. Crea un PVC restaurat amb dataSource i apunta-hi el Deployment.
5. Verifica que les cinc reserves han tornat.
6. Mesura el temps total des del pas 3 fins al 5 i anota'l: és el teu RTO real per a aquest tipus d'incident.

Respon de forma raonada, en forma de taula de decisió que puguis presentar a l'equip:

• A. Quins volums de Rutas Norte mereixen snapshots automàtics i quins no? Justifica cada component.
• B. Amb quina freqüència i amb quina retenció? Tingues en compte que en un pont es venen unes 400 reserves per hora i que un snapshot de 20 GiB costa diners cada mes.
• C. Per què els snapshots no basten com a estratègia de protecció de dades de Rutas Norte? Enumera tres escenaris concrets en què no salvarien la situació.

Exercici 1

El df -h final ha de dir 20G amb només un 1 % usat. Si status.conditions mostra FileSystemResizePending=True, falta la segona etapa: un kubectl rollout restart deploy/postgres-reserves i ja ho dirà.

L'expansió no toca les dades: només fa més gran el dispositiu i estén el sistema de fitxers sobre l'espai nou.

Exercici 2

Aquest número —de l'ordre d'un a tres minuts en un clúster local, i de cinc a quinze en producció amb volums grans— és el teu RTO per a aquest tipus d'incident. Anota'l: és la dada que cal portar a la conversa sobre objectius de recuperació de 05-06. I fixa't que el volum original continua allà, amb la taula esborrada, disponible per investigar què va passar.

Exercici 3

A. Què mereix snapshots:

B. Freqüència i retenció:

L'aritmètica que justifica el punt tres: amb snapshot diari, l'RPO és de 24 h i en un pont això són unes 9.600 reserves perdudes. Amb snapshot cada 4 h, l'RPO baixa a 4 h, és a dir, unes 1.600. I amb el WAL arxivat de forma contínua baixaria a minuts, que és la solució de veritat i es comenta a 05-06. L'RPO és una decisió de negoci, no tècnica: algú ha de decidir quantes reserves és acceptable perdre.

C. Tres escenaris en què els snapshots no salven la situació:

1. Pèrdua del sistema d'emmagatzematge o de la zona. Els snapshots viuen a la mateixa cabina o regió que els volums originals. Si desapareix, desapareixen amb ella. Una còpia de seguretat en un magatzem d'objectes d'una altra regió sí que sobreviu.
2. Esborrat del compte o el projecte del núvol, accidental o maliciós. Un administrador compromès, o un error de facturació que suspèn el compte, s'emporta volums i snapshots per igual. La protecció és una còpia en un altre compte, amb credencials diferents i immutabilitat activada.
3. Corrupció lògica no detectada a temps. Un error de l'aplicació que corromp registres a poc a poc durant tres setmanes fa inútils els snapshots de 7 dies: tots contenen ja la corrupció. Calen còpies amb retenció llarga —mensuals, anuals— i, sobretot, bolcats lògics verificables: un pg_dump que es restaura correctament demostra que les dades són coherents, cosa que un snapshot de blocs no demostra. Un quart escenari que convé esmentar: migrar a un altre proveïdor o restaurar en un altre clúster; un snapshot d'EBS no es restaura a GKE, un bolcat lògic sí.

Has obert la caixa negra. Saps que CSI existeix perquè tenir el codi de cada fabricant dins de Kubernetes era insostenible, i que la seva arquitectura són dues meitats: un connector de controlador, desplegat com a Deployment, que parla amb l'API del proveïdor i crea, connecta i fotografia volums; i un connector de node, desplegat com a DaemonSet, que formata i munta a cada màquina. Entre el driver i l'API de Kubernetes s'interposen els sidecars —external-provisioner, external-attacher, external-resizer, external-snapshotter, node-driver-registrar—, que tradueixen objectes de l'API en crides gRPC i permeten que un fabricant només escrigui la lògica del seu emmagatzematge. I coneixes els objectes que descriuen aquesta infraestructura: CSIDriver, amb les capacitats declarades, i CSINode, amb els drivers de cada node i aquell Count que explica l'exceed max volume count. Sobretot, tens el flux complet al cap —Provision, Attach, NodeStage, NodePublish— i saps quin símptoma produeix cada fase en fallar, inclòs el kubectl get volumeattachments que gairebé ningú no fa servir i que distingeix en un segon un problema de controlador d'un de node.

Has expandit en calent el volum de postgres-reserves de 10 a 20 GiB, amb la base de dades en marxa i sense tocar una sola dada. Coneixes els tres requisits —allowVolumeExpansion, suport del driver i PVC Bound—, que la petició es fa sempre al PVC i mai al PV, i les dues etapes del procés: la del disc real i la del sistema de fitxers, amb la condició FileSystemResizePending que delata quan cal recrear el pod perquè df -h digui la veritat. I tens gravada la restricció: no es pot reduir, així que la mida es pensa abans.

I domines els snapshots, amb el seu model d'objectes calcat del dels volums —VolumeSnapshotClass, VolumeSnapshot, VolumeSnapshotContent, exactament el paper de StorageClass, PVC i PV—, els seus requisits previs que no vénen amb Kubernetes (els CRDs i el snapshot-controller), i el flux de treball real: snapshot anotat amb motiu, responsable i ticket abans d'una migració d'esquema; desastre; i restauració creant un PVC nou amb dataSource, que no sobreescriu l'original i conserva l'evidència. Saps clonar un PVC en calent canviant el kind del dataSource, i que aquell clon de producció porta dades personals reals i mereix la mateixa cura que l'original.

I t'emportes els dos advertiments que donen sentit a la lliçó següent. El primer: un snapshot d'un disc amb una base de dades en marxa és crash-consistent, equivalent a l'estat després d'un tall de llum; PostgreSQL es recupera per WAL, però triga i pot perdre el que no s'ha bolcat, i el remei és coordinar l'aplicació amb hooks abans i després. El segon, el més important del mòdul: un snapshot no és una còpia de seguretat. Viu al mateix sistema d'emmagatzematge que l'original, així que no sobreviu a la pèrdua de la zona, ni a l'esborrat del compte, ni a una corrupció lògica descoberta tres setmanes tard, ni serveix per restaurar en un altre clúster. És una xarxa de seguretat de curt termini, excel·lent per al que és.

Falta, per tant, el que de veritat protegeix Rutas Norte: treure les dades del clúster, posar-les en un magatzem independent, incloure també els objectes de l'API, coordinar la base de dades perquè la còpia sigui consistent, definir retenció i —això és innegociable— provar la restauració. Això és Còpies de Seguretat i Restauració de Dades, la lliçó que tanca el mòdul.