Vanilla Kubernetes

Prethodne lekcije povezale su PersistentVolume, PersistentVolumeClaim, StorageClass, CSI i StatefulSet u sistem u kojem pod može biti zamenjen, a njegov trajni volumen sačuvan. To, međutim, još nije zaštita od pogrešnog brisanja, logičkog oštećenja podataka, ransomware-a, kvara storage sistema ili gubitka lokacije. Ova lekcija zato pomera fokus sa trajnosti aktivnog volumena na dokazivu mogućnost vraćanja aplikacije i njenih podataka u prihvatljivo stanje.

Kubernetes VolumeSnapshot API standardizuje zahtev za point-in-time snimkom CSI volumena i kreiranje novog PVC-a iz tog snimka. Snapshot je koristan mehanizam, ali nije automatski kompletan backup: može ostati u istom storage failure domenu, može zavisiti od istog administratorskog naloga, ne mora sadržati Kubernetes objekte, tajne ili spoljne zavisnosti i bez koordinacije sa aplikacijom može biti samo crash-consistent. Zaštita postoji tek kada su poznati obim, konzistentnost, mesto čuvanja, retention, pristup, RPO i RTO, a restore je periodično izvršen i potvrđen aplikativnim dokazima.

Od kopije do strategije oporavka

Kopija je tehnički artefakt; backup je kontrolisan proces, a disaster recovery je sposobnost organizacije da obnovi uslugu posle definisanog scenarija. Administrator zato prvo određuje šta se štiti: podatke u jednom PVC-u, skup međuzavisnih volumena, Kubernetes manifeste, Secrets, certifikate, operatorske custom resource objekte, image verzije, spoljne baze, DNS, identitete i konfiguraciju storage platforme. Backup samo jednog sloja može proizvesti podatke koje nije moguće bezbedno pokrenuti.

Dobra strategija često kombinuje brzi lokalni snapshot za kratki operativni rollback, aplikativno konzistentnu kopiju i nezavisnu kopiju izvan primarnog storage sistema ili lokacije. Pravilo „3-2-1” može biti koristan početni model — tri kopije, dva tipa medijuma ili sistema i jedna izdvojena kopija — ali se arhitektura zasniva na analizi rizika, ne na sloganu. Za kritične podatke izdvojena kopija treba da ima zaseban trust domen, ograničeno brisanje, enkripciju i po mogućnosti immutable ili object-lock zaštitu.

RPO, RTO, retention i poslovni kriterijum uspeha

Recovery Point Objective (RPO) određuje najveći prihvatljiv gubitak podataka izražen vremenom. Ako je RPO 15 minuta, kopija jednom dnevno ne zadovoljava zahtev. Recovery Time Objective (RTO) određuje najveće prihvatljivo vreme do obnove usluge. RTO uključuje detekciju, odluku, pribavljanje kopije, provisioniranje, restore, aplikativnu proveru i povratak saobraćaja; nije jednak samo trajanju kopiranja bajtova.

Retention određuje koliko dugo i koje generacije kopija ostaju dostupne. Kratak retention otežava oporavak od kasno otkrivenog logičkog oštećenja, a beskonačno čuvanje povećava cenu, napadnu površinu i obaveze zaštite ličnih ili regulisanih podataka. Politika mora definisati dnevne, nedeljne i mesečne generacije, legal hold, bezbedno brisanje, vlasnika odobrenja i razliku između produkcionih i test kopija.

CSI snapshot arhitektura i tok zahteva

Stabilni snapshot API koristi grupu snapshot.storage.k8s.io/v1 i tri osnovna objekta. VolumeSnapshot je namespaced zahtev korisnika; VolumeSnapshotContent je cluster-scoped reprezentacija stvarnog snapshot-a na storage sistemu; VolumeSnapshotClass je cluster-scoped administrativna klasa koja povezuje zahtev sa CSI drajverom i politikom brisanja. To su CustomResourceDefinition resursi, a ne deo osnovnog Kubernetes API-ja koji je prisutan u svakom klasteru.

Snapshot controller prati VolumeSnapshot i VolumeSnapshotContent objekte. CSI external-snapshotter sidecar prati sadržaj i poziva CSI RPC operacije konkretnog drajvera. Sam kubectl zahtev zato nije dokaz da storage podržava snapshot: potrebni su instalirani CRD-ovi, snapshot controller, kompatibilan external-snapshotter, CSI drajver koji oglašava snapshot mogućnost i odgovarajući backend.

1. Korisnik kreira VolumeSnapshot sa izvorom koji je postojeći PVC u istom namespace-u.
2. Snapshot controller bira odgovarajuću VolumeSnapshotClass i kreira/binduje VolumeSnapshotContent.
3. External-snapshotter poziva CSI drajver, a drajver traži snapshot na backend storage sistemu.
4. Status readyToUse: true označava da je snapshot spreman kao izvor za novi volumen; ne dokazuje aplikativnu konzistentnost.
5. Restore se obavlja kreiranjem novog PVC-a čiji dataSource referencira VolumeSnapshot; ne „premotava” postojeći PVC na mestu.

VolumeSnapshot i izvorni PVC moraju biti u istom namespace-u. Standardni restore preko dataSource takođe referencira snapshot iz istog namespace-a. Cross-namespace data source postoje kao posebno uslovljena funkcionalnost preko dataSourceRef, ReferenceGrant-a, odgovarajućih feature gate-ova i podrške provisioner-a; ne treba ih pretpostaviti kao prenosivu produkcionu mogućnost.

VolumeSnapshotClass, dinamičko i unapred provisionirano vezivanje

Kod dinamičkog snapshot-a korisnik navodi PVC, a sistem stvara backend snapshot i VolumeSnapshotContent. Kod unapred provisioniranog modela administrator već ima identifikator snapshot-a na storage sistemu i ručno kreira odgovarajući VolumeSnapshotContent koji se vezuje za VolumeSnapshot. Drugi model je koristan za uvoz postojeće kopije ili kontrolisanu migraciju, ali zahteva tačno poznavanje drajvera, snapshot handle-a i zaštite resursa.

deletionPolicy u VolumeSnapshotClass ili VolumeSnapshotContent određuje šta se dešava sa backend snapshot-om kada se pripadajući Kubernetes snapshot sadržaj obriše. Delete uklanja i storage snapshot; Retain zadržava backend artefakt, koji zatim mora imati vlasnika, katalog i postupak ručnog životnog ciklusa. Retain smanjuje rizik slučajnog brisanja kroz Kubernetes, ali može proizvesti napuštene i naplative kopije. Delete pojednostavljuje cleanup, ali je rizičan bez nezavisnog backup-a i zaštite privilegija.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-snap-retain
driver: csi.example.com
deletionPolicy: Retain

Vrednost driver nije generička: mora se poklapati sa CSI drajverom izvornog volumena. Parametri klase, tajne, inkrementalno ponašanje, konsolidacija, performanse i geografska trajnost zavise od proizvođača storage sistema. U prenosivom materijalu ne treba izmišljati parametre; administrator ih preuzima iz zvanične dokumentacije implementacije i ograničava ko sme da kreira ili menja klasu.

Crash-consistent i application-consistent kopija

Snapshot aktivnog volumena je najčešće crash-consistent: približno predstavlja stanje diska kakvo bi ostalo posle iznenadnog gubitka napajanja. Fajl sistem i baza mogu se oporaviti journal-om ili transakcionim logom, ali poslednje neflushovane promene mogu nedostajati. Application-consistent kopija nastaje tek kada aplikacija završi ili zamrzne relevantne upise, isprazni bafer, zabeleži checkpoint i dobije snapshot koordinisan sa tim stanjem.

Generičko skaliranje StatefulSet-a na nulu može dati miran disk, ali prekida uslugu i nije automatski bezbedno za svaki klaster baze. fsfreeze zamrzava fajl sistem, ne razume transakcije aplikacije, a neuspešan post-hook može ostaviti workload zamrznut. Za baze se koriste zvanični mehanizmi kao što su backup API, dump, checkpoint, WAL/binlog arhiviranje ili operatorski backup custom resource. Pre/post hook mora imati timeout, proveru rezultata i garantovan thaw/unquiesce postupak čak i kada snapshot ne uspe.

Više PVC-ova uvodi dodatni problem: pojedinačni snapshot-i napravljeni jedan za drugim nisu nužno konzistentna grupa. CSI Volume Group Snapshot postoji u novijem snapshot ekosistemu, ali njegova dostupnost i stabilnost zavise od verzije Kubernetes-a, CRD/controller izdanja, feature gate-a i CSI/backend podrške. Bez potvrđene group-snapshot semantike primenjuje se aplikativna koordinacija ili se koristi aplikativni backup koji proizvodi jednu logičku recovery tačku.

Snapshot nije dovoljan backup

Storage snapshot može biti veoma brz zato što backend u početku čuva samo metapodatke i promenjene blokove. Upravo zato original i snapshot mogu deliti fizičke komponente, quota ograničenja, enkripcioni ključ, administratorski domen i sudbinu storage sistema. Ako kvar kontrolera, greška operatora ili kompromitovan nalog može ukloniti obe kopije, snapshot nije nezavisna zaštita.

• Failure domen: potvrditi da li kopija preživljava gubitak diska, storage klastera, zone, regiona i celog Kubernetes klastera.
• Data movement: po potrebi preneti podatke snapshot-a u objektno ili drugo backup skladište; metapodaci bez podataka nisu dovoljni.
• Metapodaci: sačuvati deklarativne manifeste, CRD/CR instance, StorageClass mapiranje, image digest-e i restore redosled, uz pažljivo postupanje sa Secrets.
• Bezbednost: enkripcija u transportu i mirovanju, rotacija ključeva, najmanje privilegije, audit i zaštita od brisanja moraju važiti i za kopije.
• Prenosivost: CSI snapshot handle često nije prenosiv između različitih drajvera, storage sistema, naloga ili regiona. Migracija se dokazuje testom, ne pretpostavlja.

Alati kao Velero mogu koordinisati backup Kubernetes resursa, CSI snapshot-e, hook-ove i data mover, ali mogućnosti zavise od verzije alata i provider plugina. Instalacija alata sama po sebi ne definiše konzistentnost, RPO, retention ili kompatibilnost restore-a. Produkcioni dizajn mora eksplicitno navesti koje objekte alat obuhvata, gde su stvarni podaci, kako se štite kredencijali i kako se obnavljaju CRD-ovi, operatori i aplikacije pravilnim redosledom.

Projektovanje bezbednog backup i restore procesa

1. Katalog i klasifikacija: vlasnik aplikacije određuje podatke, tajnost, zavisnosti, RPO/RTO, retention i scenarije gubitka.
2. Metod konzistentnosti: dokumentuje se aplikativni quiesce, dump, log arhiviranje ili operatorski postupak i dokaz njegovog uspeha.
3. Mesto i zaštita: definišu se failure domen, kopiranje izvan primarnog sistema, enkripcija, ključevi, immutable period i odvojene privilegije.
4. Orkestracija i nadzor: backup posao ima raspored, timeout, retry politiku, alert za propuštenu kopiju i proveru starosti poslednje uspešne recovery tačke.
5. Restore runbook: navodi cilj, čisti namespace ili klaster, redosled CRD/operator/config/data/workload resursa, mapiranje StorageClass-a, DNS i validaciju.
6. Dokaz i poboljšanje: izolovani restore test meri RTO, poredi podatke, beleži odstupanja i pretvara nalaze u korektivne mere.

Bezbednost, RBAC i zaštita osetljivih kopija

VolumeSnapshot je namespaced, ali VolumeSnapshotContent i VolumeSnapshotClass su cluster-scoped resursi. Pravo kreiranja snapshot-a može proizvesti novu čitljivu kopiju osetljivih podataka, a pravo kreiranja PVC-a iz snapshot-a može omogućiti njihovo montiranje u drugi pod. Zato se dozvole za volumesnapshots, volumesnapshotcontents, volumesnapshotclasses, PVC-ove, podove i backup lokacije razdvajaju po ulozi i proveravaju audit zapisom.

Secrets iz Kubernetes API-ja nisu sadržaj PVC snapshot-a osim ako ih je aplikacija sama zapisala na taj volumen. Obrnuto, backup Kubernetes resursa može sadržati Secret objekte u base64 obliku, što nije enkripcija. Kopije se šifruju sopstvenim ključevima i štite od neovlašćenog restore-a. Break-glass postupak mora biti kontrolisan, vremenski ograničen i auditovan; backup servisni nalog ne treba da ima neograničena prava brisanja produkcionih podataka.

Restore kao nova instanca, validacija i povratak saobraćaja

Standardni Kubernetes restore snapshot-a kreira novi PVC. To je bezbednije od pokušaja izmene postojećeg volumena jer omogućava poređenje, forenzičko očuvanje izvora i kontrolisan cutover. Zahtevani kapacitet novog PVC-a ne sme biti manji od restoreSize koji prijavljuje snapshot; StorageClass i access mode moraju biti podržani. Topologija može ograničiti nod na kojem obnovljeni volumen može biti priključen.

Obnovljeni workload najpre se pokreće izolovano, bez produkcionih writer klijenata, outbound integracija i automatskog slanja poruka. Proveravaju se mount, fajl sistem, aplikativni recovery log, šema, broj i sadržaj reprezentativnih zapisa, referencijalni integritet, vremenska oznaka recovery tačke i bezbednosna konfiguracija. Tek posle formalnog prihvatanja menja se Service selector, konfiguracija ili drugi kontrolisani mehanizam usmeravanja saobraćaja. Stari volumen ostaje zadržan tokom dogovorenog rollback prozora.

Integrisani praktikum: CSI snapshot, restore u izolaciji i dokaz podataka

Poslovni i tehnički kontekst.

Tim želi da pre promene aplikacije napravi snapshot njenog PVC-a, obnovi ga kao novi volumen i dokaže da se kontrolni podaci mogu pročitati bez menjanja izvornog workload-a. Laboratorija demonstrira mehaniku CSI snapshot-a i crash-consistent kopiju mirnog test volumena; ne predstavlja produkcioni backup baze niti zamenu za kopiju izvan storage sistema.

Topologija i preduslovi.

• Kubernetes klaster sa funkcionalnim CSI drajverom koji podržava dinamičko provisioniranje, snapshot i restore.
• Instalirani snapshot.storage.k8s.io/v1 CRD-ovi, snapshot controller i kompatibilan external-snapshotter.
• Najmanje jedna VolumeSnapshotClass za isti CSI drajver kao izabrani StorageClass.
• kubectl kontekst za laboratorijski klaster i pravo rada u namenskom namespace-u. Kreiranje ili menjanje VolumeSnapshotClass-a ostaje administratorska operacija.
• Dovoljno kapaciteta za izvorni i obnovljeni volumen. Primer koristi jedan pod da bi izbegao istovremeni write pristup.

Rizik: manifesti kreiraju i brišu storage resurse. Klasa u promenljivoj STORAGE_CLASS i snapshot klasa u SNAPSHOT_CLASS moraju biti stvarne vrednosti iz laboratorije. Ne kopirati primer u produkciju bez potvrde drajvera, kvote, retention i aplikativne konzistentnosti.

1. Read-only discovery i provera ovlašćenja.

kubectl config current-context
kubectl api-resources --api-group=snapshot.storage.k8s.io
kubectl get storageclass
kubectl get volumesnapshotclass
kubectl get csidriver

kubectl auth can-i create namespaces
kubectl auth can-i create persistentvolumeclaims -n snapshot-lab
kubectl auth can-i create volumesnapshots.snapshot.storage.k8s.io -n snapshot-lab
kubectl auth can-i get volumesnapshotcontents.snapshot.storage.k8s.io

Ove komande ne menjaju stanje. Očekuju se resursi volumesnapshots, volumesnapshotcontents i volumesnapshotclasses sa API verzijom v1. Ako ne postoje, zaustaviti vežbu: CRD/controller instalacija zavisi od distribucije i CSI drajvera i ne izvodi se nasumičnim preuzimanjem „latest” manifesta. Ako poslednja provera vrati no, to može biti ispravno načelo najmanjih privilegija; detalje cluster-scoped sadržaja tada proverava storage administrator.

kubectl get volumesnapshotclass -o custom-columns=\
'NAME:.metadata.name,DRIVER:.driver,DELETE_POLICY:.deletionPolicy'
kubectl get storageclass -o custom-columns=\
'NAME:.metadata.name,PROVISIONER:.provisioner,BINDING:.volumeBindingMode'

Izabrani StorageClass provisioner i VolumeSnapshotClass driver moraju označavati isti CSI drajver. Zabeležite vrednosti za sledeće korake; primer koristi shell promenljive samo radi čitljivosti sesije.

export STORAGE_CLASS='unesi-stvarni-storageclass'
export SNAPSHOT_CLASS='unesi-stvarnu-volumesnapshotclass'

kubectl get storageclass "$STORAGE_CLASS"
kubectl get volumesnapshotclass "$SNAPSHOT_CLASS"

2. Kreiranje izvornog volumena i kontrolnog skupa podataka.

apiVersion: v1
kind: Namespace
metadata:
  name: snapshot-lab
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: source-data
  namespace: snapshot-lab
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: STORAGE_CLASS_PLACEHOLDER
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: source-writer
  namespace: snapshot-lab
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
    fsGroup: 1000
    fsGroupChangePolicy: OnRootMismatch
  containers:
    - name: writer
      image: busybox:1.36.1
      command: ["sh", "-c", "sleep 86400"]
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
        runAsNonRoot: true
        runAsUser: 1000
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: source-data

Zamenite placeholder stvarnim StorageClass imenom i sačuvajte manifest kao 01-source.yaml. Primena menja stanje i provisionira storage.

sed "s/STORAGE_CLASS_PLACEHOLDER/${STORAGE_CLASS}/" \
  01-source.yaml | kubectl apply -f -

kubectl wait -n snapshot-lab \
  --for=jsonpath='{.status.phase}'=Bound pvc/source-data \
  --timeout=3m
kubectl wait -n snapshot-lab \
  --for=condition=Ready pod/source-writer \
  --timeout=3m

kubectl exec -n snapshot-lab source-writer -- sh -c \
  'printf "record=alpha\nrecord=beta\ncheckpoint=before-snapshot\n" > /data/catalog.txt && sync'

kubectl exec -n snapshot-lab source-writer -- sha256sum /data/catalog.txt

Sačuvajte checksum kao dokaz izvornog sadržaja. sync smanjuje laboratorijski rizik neflushovanih upisa, ali nije aplikativni quiesce za bazu podataka.

3. Kreiranje snapshot-a i potvrda backend rezultata.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: source-data-snap-001
  namespace: snapshot-lab
  labels:
    tutorial.tashizza.com/purpose: pre-change
spec:
  volumeSnapshotClassName: SNAPSHOT_CLASS_PLACEHOLDER
  source:
    persistentVolumeClaimName: source-data

Zamenite placeholder i sačuvajte kao 02-snapshot.yaml. Kreiranje snapshot-a menja stanje i može izazvati trošak na storage platformi.

sed "s/SNAPSHOT_CLASS_PLACEHOLDER/${SNAPSHOT_CLASS}/" \
  02-snapshot.yaml | kubectl apply -f -

kubectl wait -n snapshot-lab \
  --for=jsonpath='{.status.readyToUse}'=true \
  volumesnapshot/source-data-snap-001 \
  --timeout=5m

kubectl get volumesnapshot source-data-snap-001 -n snapshot-lab \
  -o custom-columns=\
'NAME:.metadata.name,READY:.status.readyToUse,CREATED:.status.creationTime,RESTORE_SIZE:.status.restoreSize,CONTENT:.status.boundVolumeSnapshotContentName'

kubectl describe volumesnapshot source-data-snap-001 -n snapshot-lab

Kriterijum je readyToUse=true, postojeći bound content i razumna restoreSize vrednost. Samo postojanje objekta nije dovoljno. Ako korisnik ima odobreno cluster-scoped read pravo, može proveriti sadržaj bez prikazivanja tajnih backend detalja u tiketima:

CONTENT_NAME=$(kubectl get volumesnapshot source-data-snap-001 \
  -n snapshot-lab \
  -o jsonpath='{.status.boundVolumeSnapshotContentName}')
kubectl get volumesnapshotcontent "$CONTENT_NAME" \
  -o custom-columns=\
'NAME:.metadata.name,DRIVER:.spec.driver,POLICY:.spec.deletionPolicy,READY:.status.readyToUse'

4. Promena izvora posle recovery tačke.

kubectl exec -n snapshot-lab source-writer -- sh -c \
  'printf "record=after-snapshot\n" >> /data/catalog.txt && sync'

kubectl exec -n snapshot-lab source-writer -- cat /data/catalog.txt

Izvor sada mora sadržati i red record=after-snapshot. Restore treba da vrati prethodnu recovery tačku bez tog reda, što daje proverljiv funkcionalni dokaz.

5. Kreiranje novog PVC-a iz snapshot-a.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-data
  namespace: snapshot-lab
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: STORAGE_CLASS_PLACEHOLDER
  resources:
    requests:
      storage: 1Gi
  dataSource:
    name: source-data-snap-001
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
---
apiVersion: v1
kind: Pod
metadata:
  name: restore-validator
  namespace: snapshot-lab
  labels:
    app: restore-validator
spec:
  automountServiceAccountToken: false
  securityContext:
    seccompProfile:
      type: RuntimeDefault
    fsGroup: 1000
    fsGroupChangePolicy: OnRootMismatch
  containers:
    - name: validator
      image: busybox:1.36.1
      command: ["sh", "-c", "sleep 86400"]
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
        runAsNonRoot: true
        runAsUser: 1000
      volumeMounts:
        - name: restored
          mountPath: /restore
          readOnly: true
  volumes:
    - name: restored
      persistentVolumeClaim:
        claimName: restored-data

Sačuvajte kao 03-restore.yaml, zamenite StorageClass placeholder i primenite. Read-only mount na nivou poda smanjuje rizik izmene dokaza tokom validacije, mada backend volumen može biti provisioniran kao read-write prema access mode-u.

RESTORE_STARTED=$(date -u +%Y-%m-%dT%H:%M:%SZ)

sed "s/STORAGE_CLASS_PLACEHOLDER/${STORAGE_CLASS}/" \
  03-restore.yaml | kubectl apply -f -

kubectl wait -n snapshot-lab \
  --for=jsonpath='{.status.phase}'=Bound pvc/restored-data \
  --timeout=5m
kubectl wait -n snapshot-lab \
  --for=condition=Ready pod/restore-validator \
  --timeout=5m

kubectl get pvc,pod -n snapshot-lab -o wide
kubectl exec -n snapshot-lab restore-validator -- cat /restore/catalog.txt
kubectl exec -n snapshot-lab restore-validator -- sha256sum /restore/catalog.txt

printf 'restore_started=%s\nrestore_validated=%s\n' \
  "$RESTORE_STARTED" "$(date -u +%Y-%m-%dT%H:%M:%SZ)"

Obnovljeni fajl mora sadržati alpha, beta i checkpoint=before-snapshot, ne sme sadržati record=after-snapshot, a checksum mora odgovarati checksum-u pre snapshot-a. Vremenske oznake omogućavaju izračunavanje laboratorijskog restore vremena, ali produkcioni RTO uključuje i odluku, aplikativni start, testove i cutover.

kubectl exec -n snapshot-lab restore-validator -- \
  grep -q '^checkpoint=before-snapshot$' /restore/catalog.txt

if kubectl exec -n snapshot-lab restore-validator -- \
  grep -q '^record=after-snapshot$' /restore/catalog.txt; then
  echo 'FAIL: restore sadrži promenu nastalu posle snapshot-a'
  exit 1
else
  echo 'PASS: potvrđena je očekivana recovery tačka'
fi

6. Prikupljanje dokaza i troubleshooting bez preuranjenog brisanja.

kubectl get pvc,volumesnapshot -n snapshot-lab -o yaml \
  > snapshot-lab-observed.yaml
kubectl get events -n snapshot-lab \
  --sort-by='.metadata.creationTimestamp' \
  > snapshot-lab-events.txt
kubectl describe pvc restored-data -n snapshot-lab \
  > restored-pvc-describe.txt
kubectl describe volumesnapshot source-data-snap-001 -n snapshot-lab \
  > snapshot-describe.txt

Događaji su vremenski ograničeni i ne zamenjuju centralni log sistem. Za kontroler snapshot-a proveravaju se logovi deployment-a koji je instalirala distribucija, često u kube-system namespace-u; naziv se prvo otkriva, ne pretpostavlja. Za CSI problem korelišu se vreme događaja, external-snapshotter log, CSI controller log, storage audit/događaji i backend posao.

kubectl get deployments -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name' | \
  grep -Ei 'snapshot|csi'

kubectl get pods -A -o wide | grep -Ei 'snapshot|csi'

Posle identifikacije stvarnog poda i kontejnera, ovlašćeni platform administrator koristi vremenski ograničen upit, na primer kubectl logs -n kube-system POD -c CONTAINER --since=30m. Traže se CSI RPC greške, timeout, permission denied, quota/capacity i nepostojeći snapshot handle; tajni parametri i kredencijali ne kopiraju se u nezaštićene tikete.

Tipične greške i dijagnostičke grane.

• Server ne poznaje VolumeSnapshot: CRD nije instaliran ili se koristi pogrešna API verzija. Potvrditi kubectl api-resources; ne primenjivati nasumičnu verziju CRD-a.
• Snapshot nema readyToUse: pregledati status.error, događaje, podudaranje klase i CSI drajvera, controller/sidecar logove, kvotu i backend stanje.
• Nema podrazumevane snapshot klase: eksplicitno navesti odobrenu klasu. Više default klasa za isti drajver može dovesti do greške; storage administrator ispravlja konfiguraciju.
• Restore PVC je Pending: proveriti snapshot spremnost, minimalni restoreSize, StorageClass, provisioner, access mode, zonu/topologiju i događaje PVC-a.
• PVC je Bound, pod ContainerCreating: problem je verovatnije attach/mount ili node CSI plugin; proveriti pod događaje, kubelet i CSI node logove.
• Fajl postoji, aplikacija se ne pokreće: storage restore je tehnički uspeo, ali aplikativna validacija nije. Proveriti verziju aplikacije, šemu, ključeve, certifikate, dozvole, transakcioni recovery i spoljne servise.
• Restore sadrži neočekivano vreme podataka: preispitati trenutak quiesce-a, asinhronost backend snapshot-a i aplikativni checkpoint; readyToUse nije dokaz recovery point-a.

Dijagnostički tok incidenta.

1. Simptom, obim i posledica: utvrditi da li je problem neuspešan backup posao, jedan snapshot, čitava klasa/drajver, restore provisioniranje ili aplikativna upotrebljivost podataka.
2. Dokazi pre promene: zabeležiti vreme, poslednje promene, YAML/status bez tajni, događaje, controller/CSI/backend logove, backup katalog i stanje izvornog workload-a.
3. Neposredni uzrok: razlikovati API/CRD, RBAC, class-driver, CSI RPC, backend, quota, data movement, mount i aplikativnu konzistentnost.
4. Osnovni uzrok: utvrditi zašto monitoring, kompatibilnost, kapacitet, retention ili restore test nisu ranije otkrili problem.
5. Zaobilazno rešenje: koristiti poslednju dokazano dobru kopiju, drugi odobreni restore put ili aplikativni backup; ne brisati neuspešne artefakte pre forenzičkog prikupljanja.
6. Trajna korekcija: uskladiti komponente, prava, kapacitet, hook, data mover, alert ili runbook i ponoviti ceo restore test.
7. Potvrda: dokazati podatke, aplikativno zdravlje, RPO/RTO, bezbednost i poslovni kriterijum, pa dokumentovati nalaz i preventivnu meru.

Rollback, cleanup i zadržavanje dokaza.

U realnom incidentu povratak na stari volumen izvodi se samo ako nije promenjen posle cutover-a ili ako postoji odobren plan razrešavanja divergentnih upisa. U laboratoriji izvor nije menjan od strane restore poda, pa se rollback svodi na uklanjanje validatora i obnovljenog PVC-a. Najpre sačuvajte rezultate; zatim proverite deletionPolicy snapshot klase.

kubectl get volumesnapshotclass "$SNAPSHOT_CLASS" \
  -o jsonpath='{.deletionPolicy}{"\n"}'

kubectl delete pod restore-validator -n snapshot-lab
kubectl delete pvc restored-data -n snapshot-lab
kubectl get volumesnapshot,pvc -n snapshot-lab

Upozorenje: brisanje VolumeSnapshot-a pri politici Delete može ukloniti backend snapshot. Pri politici Retain backend artefakt ostaje i mora se evidentirati i kasnije bezbedno ukloniti prema proceduri. Sledeći cleanup izvršava se samo kada su dokazi sačuvani i kopija više nije potrebna.

kubectl delete volumesnapshot source-data-snap-001 -n snapshot-lab
kubectl delete pod source-writer -n snapshot-lab
kubectl delete pvc source-data -n snapshot-lab
kubectl delete namespace snapshot-lab

Posle cleanup-a storage administrator proverava da li su backend volumen i snapshot zaista uklonjeni ili pravilno zadržani. Kubernetes objekat koji je nestao nije dokaz da nema orphaned storage resursa, a obrnuto, Retain artefakt bez kataloga nije upravljiva kopija.

Merljivi kriterijumi prihvatanja praktikuma.

• Potvrđeno je postojanje stabilnog snapshot API-ja i podudaranje CSI drajvera StorageClass-a i VolumeSnapshotClass-a.
• Izvorni PVC je Bound, pod Ready, a checksum početnog fajla sačuvan.
• VolumeSnapshot ima readyToUse=true, bound content i očekivani restoreSize.
• Novi PVC je uspešno provisioniran iz snapshot-a bez izmene izvornog PVC-a.
• Obnovljeni checksum odgovara recovery tački, a promena posle snapshot-a nije prisutna.
• Vreme restore-a je zabeleženo, događaji i statusi sačuvani, a deletionPolicy proverena pre cleanup-a.
• Jasno je dokumentovano da laboratorija dokazuje CSI restore, ali ne nezavisnost kopije ni aplikativnu konzistentnost produkcione baze.

Administratorske prakse

• Kontrola starosti kopije: monitoring mora prikazati vreme poslednjeg uspešnog i poslednjeg dokazano upotrebljivog backup-a. Alarm se vezuje za RPO, ne samo za status poslednjeg posla.
• Periodični restore test: po kritičnosti aplikacije planira se automatski ili nadzirani restore u izolovan namespace/klaster. Beleže se početak, recovery point, RTO, checksum i aplikativni kriterijumi; neuspeh je incident backup sistema čak i kada svakodnevni poslovi imaju status Success.
• Separation of duties: tim koji koristi snapshot ne mora imati pravo izmene VolumeSnapshotClass-a ili brisanja backend kopija. Backup i produkcioni administrativni nalozi razdvajaju se i auditiraju.
• Kapacitet i performanse: prati se broj snapshot-a, promenjeni blokovi, latency izvornog volumena, trajanje snapshot/data-movement poslova, quota i restore throughput. Snapshot storm može opteretiti storage i aplikaciju.
• Lifecycle i katalog: svaka kopija ima vlasnika, aplikaciju, namespace, recovery point, klasifikaciju, retention, lokaciju, enkripcioni ključ i status poslednjeg testa. Napušteni Retain sadržaji se ne brišu bez korelacije sa katalogom.
• Promena verzija: upgrade Kubernetes-a, CSI drajvera, external-snapshotter-a, CRD-a, storage firmware-a ili backup alata zahteva proveru compatibility matrix-a i probni snapshot/restore pre i posle promene.
• DR vežba: povremeno se simulira gubitak klastera ili lokacije, uz read-only zaštitu backup lokacije tokom oporavka. Vežba mora dokazati dostupnost ključeva, image-a, manifesta, DNS-a i ljudi/runbook-a, ne samo podataka.

Završna kontrolna tačka

• Umemo da razlikujemo trajni volumen, snapshot, backup, replikaciju i disaster recovery.
• RPO, RTO, retention i failure domen definisani su za svaku zaštićenu aplikaciju.
• Identifikovani su svi podaci, Kubernetes objekti, tajne, ključevi i spoljne zavisnosti potrebni za oporavak.
• Potvrđene su verzije snapshot CRD/controller/sidecar komponenti i podrška konkretnog CSI drajvera i backenda.
• VolumeSnapshotClass driver i deletionPolicy su eksplicitno provereni; nema oslanjanja na nepoznatu default klasu.
• Metod aplikativne konzistentnosti je dokumentovan i testiran, uključujući bezbedan unquiesce posle greške.
• Kopija potrebna za DR nalazi se izvan odgovarajućeg primarnog failure i trust domena.
• Backup je šifrovan, pristup je najmanje privilegovan, brisanje zaštićeno i audit omogućen.
• Restore se izvodi kao novi PVC i izolovani workload pre kontrolisanog cutover-a.
• Validacija obuhvata checksum i aplikativne kriterijume, a ne samo readyToUse, Bound ili Running stanje.
• Probni restore je izmeren i zadovoljava RPO/RTO; rezultat, odstupanja i korektivne mere su evidentirani.
• Cleanup uzima u obzir deletionPolicy, PV reclaim policy, backend artefakte i obavezno zadržavanje dokaza.

Zaključak

VolumeSnapshot daje standardizovan Kubernetes interfejs za point-in-time snimak CSI volumena i provisioniranje novog PVC-a iz tog snimka. Njegova prava vrednost zavisi od kompletne putanje: kompatibilnih CRD/controller/sidecar komponenti, mogućnosti CSI drajvera, storage backenda, pravilne klase, aplikativne konzistentnosti, zaštite kopije i bezbednog restore postupka. Status readyToUse potvrđuje tehničku spremnost snapshot-a, ali ne potvrđuje da aplikacija može da se oporavi niti da kopija preživljava kvar primarnog sistema.

Administrator mora da projektuje zaštitu prema scenarijima gubitka i merljivim RPO/RTO ciljevima, razdvoji snapshot od nezavisnog backup-a, ograniči privilegije, zaštiti ključeve i održava katalog kopija. Restore se tretira kao kontrolisana promena: najpre se čuvaju dokazi, zatim se novi volumen obnavlja u izolaciji, proveravaju se podaci i aplikativno ponašanje, a saobraćaj se vraća tek posle formalnog kriterijuma prihvatanja.

Najopasnija pretpostavka glasi „backup posao je uspeo, dakle podaci su bezbedni”. Profesionalni dokaz je uspešan, ponovljiv i izmeren oporavak. Kada kopija nije nezavisna, konzistentnost nije poznata, ključevi nisu dostupni, restore prelazi RTO ili postoji mogućnost divergentnih upisa i gubitka podataka, administrator zaustavlja rizičnu promenu i eskalira vlasniku aplikacije, storage/backup timu i incident ili disaster recovery rukovodstvu.