Perzistentní úložiště

Perzistentní úložiště

Zapisovatelná vrstva kontejneru umírá s kontejnerem a emptyDir s podem. Cokoli, co má přežít přeplánování, musí přijít zvenčí.

Tři objekty

• PersistentVolume (PV) – kus úložiště, který existuje. Cluster-scoped.
• PersistentVolumeClaim (PVC) – „potřebuji 1 GiB, ReadWriteOnce“. V namespace. Pod odkazuje na claim, nikdy na volume.
• StorageClass – továrna, která PV vytváří automaticky (dynamické provisioning).

Tenhle cluster je dodaný bez StorageClass a bez CSI driveru, takže se zpočátku nic nevytvoří samo: PV napíšete vy a ukážete jím na jeden z NFS exportů na support01 (/storage1, /storage2, /storage3). Přesně takhle vypadá on-premise realita, kterou cloud skrývá – a druhá polovina labu 18 to napraví instalací driveru.

Statický NFS PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-storage1
spec:
  capacity:
    storage: 1Gi
  accessModes: ["ReadWriteMany"]
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ""            # výslovně žádná třída
  nfs:
    server: support01
    path: /storage1

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 1Gi
  storageClassName: ""            # sedne na PV bez třídy

Vazbu dělá control plane: hledá PV, které je alespoň tak velké, má kompatibilní access modes a stejnou třídu. Vazba je výhradní – jeden PVC vlastní jeden PV, i když si řekl o méně.

Dynamické provisioning: CSI + StorageClass

Psát PV na každý volume se nedá udržet. CSI driver naučí cluster mluvit s konkrétním úložištěm a StorageClass je pojmenovaný recept, který ho používá. PVC, které si o třídu řekne, dostane PV vytvořený na počkání.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-csi
provisioner: nfs.csi.k8s.io
parameters:
  server: support01
  share: /storage3
reclaimPolicy: Retain            # zdědí každý PV, který třída vytvoří
volumeBindingMode: Immediate     # nebo WaitForFirstConsumer

PVC pak pojmenuje třídu a nic jiného:

spec:
  accessModes: ["ReadWriteMany"]
  resources: { requests: { storage: 300Mi } }
  storageClassName: nfs-csi

Driver je obyčejná zátěž: DaemonSet, který na každém uzlu připojuje, plus Deployment s kontrolerem, který volumes vytváří a maže. Uzly pořád potřebují nfs-common – CSI kernelový mount řídí, nenahrazuje ho.

In-tree vs. out-of-tree. Pole nfs: ve statickém PV výše je in-tree plugin zakompilovaný do Kubernetes. In-tree storage pluginy jsou zmrazené a postupně se odstraňují; všechny současné drivery žijí mimo strom a mluví CSI. Pro cokoli nového volte CSI driver.

Třída označená storageclass.kubernetes.io/is-default-class: "true" se použije u každého PVC, které žádnou nepojmenuje. Tenhle cluster výchozí třídu nemá, a proto PVC bez třídy věčně visí v Pending místo toho, aby tiše dostalo volume.

Access modes

Reclaim policy

• Retain – PV si po smazání PVC ponechá data a musí se uklidit ručně. Správná volba pro cokoli, na čem vám záleží.
• Delete – volume zmizí spolu s claimem, včetně dat. Obvyklá výchozí hodnota u dynamického provisioningu a důvod, proč lidé přicházejí o databáze.

Nastavuje se na PV, když ho píšete ručně, a na StorageClass, když ho píše driver. PV s Retain, jehož claim zmizel, přejde do Released a zůstane tam: abyste ho dali novému PVC, vyčistíte claimRef a nový claim ho pojmenuje přes volumeName. Ten ruční krok je záměr – člověk potvrdí, že se stará data smějí znovu použít.

Co se obvykle pokazí

Reference

• Persistent Volumes
• NFS volumes