Corectarea unei cereri PVC nu micșorează volumul

Un incident de stocare poate cuprinde trei numere diferite: capacitatea cerută, capacitatea alocată efectiv și capacitatea necesară pentru restaurarea unui punct de recuperare util. Un ghid operațional care le tratează drept aceeași stare poate transforma o corectare într-o presupunere periculoasă. Kubernetes 1.34 a simplificat modificarea cererilor de extindere eșuate. Nu a introdus suport pentru micșorarea fizică a volumelor și nici nu a făcut dintr-un snapshot dovada suficientă a posibilității de recuperare.

Privind din noiembrie 2026, anunțul despre recuperare din 19 septembrie 2025 descrie trecerea funcționalității la disponibilitate generală în 1.34. Exemplul privește o cerere prea mare care nu s-a finalizat. Cererea corectată trebuie să rămână mai mare decât capacitatea efectivă inițială din .status.capacity. Aceasta este limita unei cereri de creștere neîndeplinite, nu permisiunea de a recupera spațiu deja alocat prin reducerea unei valori din manifest.

Porniți de la starea care există efectiv

Dimensiunea dorită exprimă o instrucțiune. Starea raportată și observațiile din sistemul de stocare descriu progresul către ea. Când extinderea eșuează, copierea valorii dorite în rezumatul incidentului ca și cum ar fi capacitate alocată pierde informația necesară alegerii pasului următor. Păstrați separat dimensiunea inițială, ținta nereușită și progresul observat înainte să decideți ce poate realiza o corectare.

Referința despre opțiunile de activare din versiunea 1.34 listează RecoverVolumeExpansionFailure drept activată și GA în 1.34, după beta activată în 1.32–1.33. Versiunea clusterului rămâne o dovadă insuficientă despre întregul traseu de stocare. Extinderea cere un driver care o acceptă și o clasă StorageClass potrivită, care permite extinderea; documentația versionată a volumelor persistente descrie condițiile. Confirmați componentele instalate, fără să presupuneți că toate sistemele de stocare au primit aceeași capacitate.

Distincția pentru afacere este simplă. Corectarea unei cereri imposibile poate permite o extindere mai mică, încă necesară. Nu readuce aplicația la o stare anterioară a datelor. Dacă incidentul privește înregistrări corupte, nu o țintă de extindere indisponibilă, corectarea dimensiunii dorite rezolvă altă problemă. Numirea precisă a incidentului îi ajută pe operatori să nu promită recuperare printr-un mecanism care schimbă doar capacitatea cerută.

Un snapshot de grup răspunde altei întrebări

Articolul din 16 septembrie 2025 despre snapshoturi de grup privește trecerea la v1beta2, a doua versiune beta a unor API-uri de extensie acceptate de drivere CSI. Descrie snapshoturi ale unui grup selectat de volume, coerente la nivelul stării de după o oprire bruscă. Acesta nu era statutul GA al recuperării extinderii și nici garanția că toți furnizorii acceptau snapshoturi de grup.

Revizia API-ului a tratat lipsa informației restoreSize când un driver nu implementa ListSnapshots. Articolul descrie informații pe snapshot returnate prin driver și un webhook de conversie pentru obiectele beta existente. Detaliile contează deoarece recunoașterea unui obiect de grup și obținerea metadatelor necesare volumelor individuale de restaurare sunt capacități separate. Numele unui API într-un rezumat de versiune nu dovedește că driverul, controlerul și componenta sidecar instalate respectă același contract.

Disponibilitatea componentelor are propria cronologie: external-snapshotter v8.4.0, lansat pe 23 octombrie 2025, introduce explicit v1beta2. Articolul din septembrie nu poate data singur lansarea componentei. README-ul v8.4.0 cere definițiile CRD de snapshoturi de grup și activarea CSIVolumeGroupSnapshot atât în controlerul de snapshot, cât și în componenta sidecar CSI snapshotter; descrie suportul de grup pentru CSI 1.10.0 și ulterior. Driverul are în continuare nevoie de operațiunea de grup, iar servirea obiectelor beta mai vechi cere webhookul de conversie. Sunt detalii ulterioare, versionate, de implementare, nu dovezi ale disponibilității pe orice cluster din septembrie. Articolul nu schimbă niciuna dintre aceste componente.

Coerența după o oprire bruscă lasă muncă aplicației

Un punct coerent între volume după o oprire bruscă este util fiindcă starea capturată corespunde aceleiași limite de defectare. Nu înseamnă că aplicația a oprit deliberat scrierile și a stabilit propriul punct coerent pentru operațiunile afacerii. O bază de date și un depozit de fișiere asociat pot avea obligații care cer coordonare specifică aplicației. Gruparea cererilor lor prin etichete nu definește această coordonare.

Un plan de recuperare ar trebui, așadar, să spună ce se așteaptă aplicația să găsească după restaurare. Poate avea nevoie de reluarea operațiunilor, reconciliere sau o procedură documentată de oprire temporară a scrierilor la crearea punctului de recuperare. Procedura potrivită depinde de aplicație și de contractul driverului. Sunt întrebări de proiectare, nu relatarea unui experiment Kubernetes sau o instrucțiune universală de a suspenda orice sarcină.

Disponibilitatea restaurării depinde și de alte lucruri decât păstrarea unui obiect API. Snapshoturile din sistemul de stocare, permisiunile, capacitatea compatibilă la destinație și traseul restaurării trebuie să mai existe când sunt necesare. O captură reușită nu dovedește că un mediu înlocuitor o poate folosi. Dovezile relevante ar veni dintr-un exercițiu autorizat de restaurare cu verificări ale aplicației; pentru articol nu s-au modificat clustere și nu s-au creat sau restaurat snapshoturi.

Păstrați cel mai simplu plan adecvat

Contraargumentul cel mai puternic este o aplicație cu un singur volum obișnuit și o cerere eșuată care nu a schimbat capacitatea alocată. Snapshoturile de grup și coordonarea aplicației pot fi irelevante pentru corectarea acelui incident. Poate fi suficientă o corectare precisă, în condițiile documentate ale extinderii. Adăugarea unei proceduri complicate de restaurare doar fiindcă un articol apropiat menționează snapshoturi poate spori confuzia.

În schimb, când incidentul cere într-adevăr restaurarea mai multor volume, schimbarea cererii PVC nu poate înlocui un punct de recuperare. Păstrați corectarea capacității și restaurarea ca ramuri separate ale ghidului. Consemnați observațiile care aleg fiecare ramură și persoana care poate confirma rezultatul aplicației. Astfel, planul rămâne util sub presiune, fără să pretindă că platforma a eliminat toate condițiile specifice stocării.

Pentru dezvoltare software la comandă, predați o explicație a stărilor stocării odată cu instrucțiunile operaționale. Identificați independent creșterea cerută, capacitatea alocată și datele recuperabile. Folosiți schimbările din septembrie pentru contractele mai restrânse pe care le îmbunătățesc și cereți dovezi din aplicație înainte să declarați că o operațiune de stocare a refăcut serviciul necesar clienților.