Persistent Volumes (PV) w Kubernetes – trwałe przechowywanie danych dla aplikacji

Jedną z najważniejszych cech kontenerów jest ich nietrwałość (ephemeral nature). Kontener może zostać zatrzymany, usunięty lub odtworzony w dowolnym momencie, a wszystkie dane zapisane wewnątrz jego systemu plików zostaną utracone.

Dla aplikacji stateless, takich jak serwery WWW czy API, zwykle nie stanowi to problemu. Jednak bazy danych, systemy kolejkowe, aplikacje analityczne czy platformy CMS wymagają trwałego przechowywania danych.

To właśnie dlatego Kubernetes udostępnia mechanizmy Persistent Volumes (PV) i Persistent Volume Claims (PVC).

Dlaczego kontenery tracą dane?

Załóżmy, że uruchamiamy bazę PostgreSQL w kontenerze.

Pod

↓

Container

↓

Filesystem

Do bazy trafiają dane klientów.

Po pewnym czasie Node ulega awarii.

Kubernetes tworzy nowy Pod.

Old Pod

↓

Deleted

↓

New Pod

↓

Empty Filesystem

Cała baza danych znika.

Tip eksperta

To jeden z najczęstszych błędów początkujących administratorów Kubernetes. Uruchomienie bazy danych bez Persistent Volume oznacza, że każda awaria lub ponowne wdrożenie może zakończyć się utratą danych.

Czym jest Persistent Volume?

Persistent Volume to zasób klastra reprezentujący trwałą przestrzeń dyskową.

Może pochodzić z:

• lokalnego dysku,
• macierzy SAN,
• serwera NFS,
• dysku w chmurze,
• systemu Ceph,
• GlusterFS,
• Longhorn,
• Amazon EBS,
• Azure Disk,
• Google Persistent Disk.

Schemat:

Application

↓

Persistent Volume Claim

↓

Persistent Volume

↓

Storage

Najważniejsze elementy

Kubernetes wykorzystuje trzy główne obiekty.

Persistent Volume (PV)

Reprezentuje fizyczny zasób dyskowy.

Persistent Volume Claim (PVC)

Jest żądaniem przestrzeni dyskowej przez aplikację.

StorageClass

Opisuje sposób automatycznego tworzenia dysków.

Persistent Volume

Administrator może utworzyć PV ręcznie.

Przykład:

apiVersion: v1
kind: PersistentVolume

metadata:
  name: mysql-pv

spec:

  capacity:
    storage: 20Gi

  accessModes:
  - ReadWriteOnce

  persistentVolumeReclaimPolicy: Retain

  hostPath:
    path: /data/mysql

Tutaj utworzono:

• dysk 20 GB,
• dostęp ReadWriteOnce,
• politykę Retain.

Uwaga

hostPath jest wygodny do testów i środowisk laboratoryjnych, ale nie jest zalecany w produkcji. W środowiskach produkcyjnych warto korzystać z rozwiązań sieciowych lub chmurowych zapewniających wysoką dostępność.

Persistent Volume Claim

Aplikacja nie odwołuje się bezpośrednio do PV.

Tworzy:

apiVersion: v1
kind: PersistentVolumeClaim

metadata:
  name: mysql-pvc

spec:

  accessModes:
  - ReadWriteOnce

  resources:
    requests:
      storage: 20Gi

Schemat:

Application

↓

PVC

↓

PV

↓

Disk

Jak działa powiązanie?

Administrator tworzy:

Persistent Volume

20 GB

Aplikacja prosi:

Persistent Volume Claim

20 GB

Kubernetes automatycznie łączy oba obiekty.

PVC

↓

Bound

↓

Persistent Volume

StorageClass

W nowoczesnych klastrach rzadko tworzy się PV ręcznie.

Stosuje się:

StorageClass

Przykład:

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:
  name: fast-storage

provisioner: kubernetes.io/aws-ebs

Proces:

PVC

↓

StorageClass

↓

Automatic Disk Creation

↓

Persistent Volume

To tzw. Dynamic Provisioning.

Access Modes

Jednym z najważniejszych parametrów jest sposób dostępu.

ReadWriteOnce (RWO)

One Node

↓

Read + Write

Najczęściej wykorzystywany dla baz danych.

ReadOnlyMany (ROX)

Many Nodes

↓

Read Only

Przydatny dla współdzielonych danych tylko do odczytu.

ReadWriteMany (RWX)

Many Nodes

↓

Read + Write

Idealny dla:

• CMS,
• współdzielonych plików,
• aplikacji HA.

ReadWriteOncePod (RWOP)

Nowy tryb zapewniający, że wolumen może być zamontowany do zapisu tylko przez jeden Pod jednocześnie, co zwiększa bezpieczeństwo i przewidywalność działania.

Tip eksperta

Nie każdy backend storage obsługuje wszystkie tryby dostępu. Przed wyborem rozwiązania sprawdź jego dokumentację – np. wiele dysków blokowych oferuje tylko ReadWriteOnce.

Reclaim Policy

Co zrobić po usunięciu PVC?

Retain

PVC Deleted

↓

Data Stays

Najbezpieczniejsza opcja.

Delete

PVC Deleted

↓

Disk Deleted

Popularna w chmurach.

Recycle

Mechanizm historyczny, obecnie praktycznie nieużywany.

Pod wykorzystujący PVC

Przykład:

volumes:

- name: mysql-storage

  persistentVolumeClaim:

    claimName: mysql-pvc

Montowanie:

volumeMounts:

- mountPath: /var/lib/mysql

  name: mysql-storage

Efekt:

Pod

↓

PVC

↓

Persistent Volume

↓

Storage

StatefulSet i Persistent Volumes

Dla baz danych zaleca się:

StatefulSet

Dlaczego?

Każdy Pod otrzymuje własny dysk.

Przykład:

mysql-0

↓

PVC-0

↓

Disk-0


mysql-1

↓

PVC-1

↓

Disk-1

Tip eksperta

Deployment świetnie sprawdza się dla aplikacji stateless, natomiast dla baz danych, brokerów wiadomości czy systemów kolejkowych zdecydowanie lepszym wyborem jest StatefulSet.

Snapshoty

Wiele StorageClass obsługuje snapshoty.

Proces:

Persistent Volume

↓

Snapshot

↓

Backup

↓

Restore

To znacznie szybsze niż klasyczny backup plików.

Rozszerzanie wolumenów

Nowoczesne StorageClass pozwalają zwiększyć rozmiar dysku.

Przykład:

resources:

  requests:

    storage: 100Gi

Po zastosowaniu zmian Kubernetes może automatycznie rozszerzyć wolumen (o ile wspiera to backend storage i StorageClass).

CSI – Container Storage Interface

Obecnie większość rozwiązań korzysta z:

CSI Driver

Architektura:

Application

↓

PVC

↓

CSI Driver

↓

Storage System

Popularne sterowniki:

• AWS EBS CSI,
• Azure Disk CSI,
• GCE PD CSI,
• Ceph CSI,
• Longhorn CSI,
• OpenEBS,
• Dell PowerFlex.

Lokalne dyski vs Storage sieciowy

Backup danych

Persistent Volume nie jest kopią zapasową.

To częsty błąd.

Schemat:

Persistent Volume

↓

Snapshot

↓

Backup

↓

Offsite Storage

Warto stosować rozwiązania takie jak:

• Velero,
• Restic,
• Kasten K10,
• chmurowe mechanizmy snapshotów.

Monitoring przestrzeni dyskowej

Administrator powinien monitorować:

• zajętość dysków,
• liczbę PVC,
• opóźnienia I/O,
• błędy storage,
• dostępność backendu.

Popularne narzędzia:

• Prometheus,
• Grafana,
• kube-state-metrics.

Bezpieczeństwo Persistent Volumes

Dane na dysku często zawierają:

• hasła,
• certyfikaty,
• bazy danych,
• dokumenty,
• logi.

Dlatego warto:

• szyfrować dyski (at-rest encryption),
• ograniczać dostęp przez RBAC,
• stosować dedykowane ServiceAccount,
• wykonywać regularne backupy,
• monitorować operacje na wolumenach.

Tip eksperta

Jeżeli środowisko działa w chmurze, włącz szyfrowanie dysków zarządzane przez dostawcę lub wykorzystaj własne klucze KMS (Key Management Service). To niewielki koszt, a znacząco zwiększa bezpieczeństwo danych.

Najczęstsze błędy

❌ uruchamianie bazy danych bez PV

❌ używanie hostPath w produkcji

❌ brak kopii zapasowych

❌ brak monitorowania przestrzeni dyskowej

❌ wybór niewłaściwego Access Mode

❌ usuwanie PVC bez znajomości Reclaim Policy

❌ przechowywanie danych krytycznych na lokalnym dysku pojedynczego Node’a

Najlepsze praktyki

✅ korzystaj z Dynamic Provisioning

✅ stosuj StorageClass zamiast ręcznego tworzenia PV

✅ używaj StatefulSet dla aplikacji stanowych

✅ wykonuj regularne snapshoty i backupy

✅ monitoruj wykorzystanie przestrzeni

✅ szyfruj dane na dyskach

✅ dobieraj odpowiedni Access Mode

✅ regularnie testuj proces odtwarzania danych

Architektura trwałego przechowywania danych

                Application

                     |

                     ↓

                 StatefulSet

                     |

                     ↓

        Persistent Volume Claim

                     |

                     ↓

              StorageClass (CSI)

                     |

                     ↓

          Persistent Volume

                     |

                     ↓

      Storage Backend (EBS, Ceph,
      Longhorn, NFS, SAN, Azure Disk)

                     |

                     ↓

         Snapshot / Backup / Restore

Podsumowanie

Persistent Volumes to fundament pracy z aplikacjami przechowującymi dane w Kubernetes. Oddzielają cykl życia danych od cyklu życia kontenerów, dzięki czemu awaria Poda, aktualizacja aplikacji czy migracja na inny Node nie oznacza utraty informacji.

Nowoczesne środowiska produkcyjne wykorzystują StorageClass, Dynamic Provisioning, CSI, StatefulSet oraz regularne snapshoty i backupy, tworząc niezawodną i skalowalną warstwę przechowywania danych.

Najważniejsza zasada:

Kontenery są tymczasowe, ale dane biznesowe nie. Projektując aplikację dla Kubernetes, zawsze planuj trwałe przechowywanie danych już na etapie architektury.

Polecane wpisy

Tiktok jak dodać napisy

Oto kilka wskazówek dotyczących dodawania napisów do filmików na TikToku: Tiktok jak dodać napisy Korzystaj z Czytaj dalej

Tor na smartfonie: Orbot i Orfox – konfiguracja i użycie na Androidzie i iOS

📱 Tor na smartfonie: Orbot i Orfox – konfiguracja i użycie na Androidzie i iOS 🔍 Wprowadzenie W dobie rosnącej Czytaj dalej