Woluminy trwałe i żądania zasobów

Pody powstają i znikają, ale dane aplikacji często muszą przetrwać. Dotyczy to na przykład bazy danych lub plików przesłanych przez użytkowników.

• Po ponownym uruchomieniu Poda lub zaplanowaniu go na innym węźle wszelkie dane zapisane bezpośrednio w systemie plików kontenera zostają utracone.
• Ta efemeryczna natura jest odpowiednia dla aplikacji bezstanowych, ale dane krytyczne wymagają trwałego rozwiązania.
• Kubernetes udostępnia zaawansowany system zarządzania pamięcią trwałą, która przetrwa cykle życia Podów.

PersistentVolume (PV) to zasób pamięci masowej w klastrze Kubernetes.

• Jest to zasób o zasięgu całego klastra, co oznacza, że nie należy do żadnej konkretnej przestrzeni nazw.
• PVs są udostępniane przez administratora lub dynamicznie za pomocą StorageClass.
• Abstrahują szczegóły bazowej technologii pamięci masowej (np. Google Persistent Disk, AWS EBS, udziału NFS).

PVs definiuje się za pomocą szczegółów takich jak pojemność, tryby dostępu i typ pamięci masowej. Ten plik YAML opisuje PV używający hostPath (do testów lokalnych) i zapewniający 5 gigabajtów pamięci.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

Uwaga: hostPath jest zazwyczaj przeznaczony do programowania na jednym węźle i nie jest zalecany w środowisku produkcyjnym.

PersistentVolumeClaim (PVC) to żądanie pamięci masowej wystosowane przez użytkownika lub aplikację w konkretnej przestrzeni nazw.

• Pody nie korzystają bezpośrednio z PV — żądają pamięci masowej za pośrednictwem PVC.
• PVC mają zasięg przestrzeni nazw, więc znajdują się w obszarze konkretnego projektu lub zespołu.
• Określają wymagany rozmiar, tryby dostępu i opcjonalnie klasę pamięci masowej.

Kubernetes automatycznie dopasowuje PVC do dostępnego PV w procesie nazywanym wiązaniem.

• Po utworzeniu PVC Kubernetes wyszukuje PV spełniający wymagania PVC (rozmiar, tryby dostępu, klasa pamięci masowej).
• Po znalezieniu odpowiedniego PV oba zasoby zostają ze sobą „powiązane” w relacji jeden do jednego.
• To powiązanie gwarantuje, że PVC otrzyma dokładnie taką pamięć masową, o jaką poproszono.

Tryby dostępu określają sposób montowania pamięci masowej i korzystania z niej przez Pody. Tryby te są żądane przez PVC i obsługiwane przez PV:

• ReadWriteOnce (RWO): Wolumin można zamontować w trybie odczytu i zapisu na jednym węźle.
• ReadOnlyMany (ROX): Wolumin można zamontować w trybie tylko do odczytu na wielu węzłach.
• ReadWriteMany (RWX): Wolumin można zamontować w trybie odczytu i zapisu na wielu węzłach.

Dostępność tych trybów zależy od konkretnego dostawcy pamięci masowej.

StorageClass umożliwia administratorom definiowanie „klas” pamięci masowej (np. „fast-ssd”, „slow-hdd”).

• Zamiast ręcznie tworzyć PV, można skonfigurować StorageClass tak, aby dynamicznie udostępniał PV, gdy zażąda go PVC.
• Automatyzuje to tworzenie PV na podstawie zdefiniowanych wcześniej szablonów.
• Oddziela udostępnianie pamięci masowej od korzystania z niej, ułatwiając pracę użytkownikom.

Utwórzmy PVC, który żąda 1 gigabajta pamięci masowej z dostępem ReadWriteOnce. Ten PVC wyszuka istniejący PV lub uruchomi dynamiczne udostępnianie za pomocą StorageClass.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard # Optional: if you have a 'standard' StorageClass

Zapisz ten plik jako pvc.yaml i zastosuj go poleceniem kubectl apply -f pvc.yaml.

Po powiązaniu PVC Pod może z niego korzystać, odwołując się do nazwy PVC w konfiguracji woluminu. Pod nie musi znać bazowego PV — wystarczy mu PVC.

apiVersion: v1
kind: Pod
metadata:
  name: my-data-pod
spec:
  containers:
    - name: data-container
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello from CoddyKit!' > /mnt/data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /mnt/data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: my-app-pvc

Ten Pod zapisze plik na zamontowanym woluminie trwałym.

Stan zasobów trwałej pamięci masowej można monitorować za pomocą kubectl:

• Aby wyświetlić wszystkie PV: kubectl get pv
• Aby wyświetlić wszystkie PVC w danej przestrzeni nazw: kubectl get pvc
• Aby uzyskać szczegółowe informacje, w tym stan i zdarzenia:
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

Należy upewnić się, że PV mają stan Bound, a PVC są powiązane (Bound) z właściwym PV.

Użytkownik chce wdrożyć bazę danych, która wymaga 50 GB trwałej pamięci masowej. Który zasób Kubernetes bezpośrednio reprezentuje żądanie tej pamięci przez aplikację użytkownika?

Omówiliśmy sposób, w jaki Kubernetes zarządza trwałą pamięcią masową dla aplikacji:

• PersistentVolumes (PV) to zasoby klastra reprezentujące rzeczywistą pamięć masową.
• PersistentVolumeClaims (PVC) to żądania użytkowników dotyczące pamięci masowej.
• Kubernetes wiąże PVC z odpowiednimi PV na podstawie wymagań.
• Tryby dostępu określają sposób korzystania z pamięci masowej (RWO, ROX, RWX).
• StorageClass umożliwia dynamiczne udostępnianie PV i automatyzuje konfigurację.

System ten zapewnia trwałość danych aplikacji nawet wtedy, gdy Pody są tworzone i usuwane, zwiększając niezawodność aplikacji stanowych.