Persistent Volumes og Claims

PVs defineres med detaljer som kapasitet, tilgangsmoduser og lagringstype. Denne YAML-filen beskriver et PV som bruker hostPath (for lokal testing) med 5 gigabyte lagring.

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

Merk: hostPath brukes vanligvis til utvikling på én node og anbefales ikke i produksjon.

En PersistentVolumeClaim (PVC) er en forespørsel om lagring fra en bruker eller applikasjon i et bestemt namespace.

• Pods bruker ikke PVs direkte; de ber om lagring gjennom en PVC.
• PVCs har namespace-omfang, så de ligger i et bestemt prosjekt eller område for et team.
• De angir ønsket størrelse, tilgangsmoduser og eventuelt en StorageClass.

Kubernetes kobler automatisk en PVC til et tilgjengelig PV gjennom en prosess som kalles binding.

• Når en PVC opprettes, søker Kubernetes etter et PV som oppfyller PVC-ens krav (størrelse, tilgangsmoduser og StorageClass).
• Når et egnet PV er funnet, blir de «bundet» sammen i et én-til-én-forhold.
• Denne koblingen sikrer at PVC-en får den bestemte lagringen den ba om.

Tilgangsmoduser definerer hvordan lagringen kan monteres og brukes av Pods. Disse modusene etterspørres av PVCs og støttes av PVs:

• ReadWriteOnce (RWO): Volumet kan monteres med lese- og skrivetilgang av én enkelt node.
• ReadOnlyMany (ROX): Volumet kan monteres skrivebeskyttet av flere noder.
• ReadWriteMany (RWX): Volumet kan monteres med lese- og skrivetilgang av flere noder.

Hvilke moduser som er tilgjengelige, avhenger av den bestemte lagringsleverandøren.

StorageClasses gir administratorer en måte å beskrive «klasser» av lagring på (f.eks. «fast-ssd» og «slow-hdd»).

• I stedet for å opprette PVs manuelt kan en StorageClass klargjøre et PV dynamisk når en PVC ber om det.
• Dette automatiserer opprettelsen av PVs basert på forhåndsdefinerte maler.
• Det skiller klargjøringen av lagring fra bruken av den, noe som gjør det enklere for brukerne.

La oss opprette en PVC som ber om 1 gigabyte lagring med ReadWriteOnce-tilgang. Denne PVC-en søker etter et eksisterende PV eller utløser dynamisk klargjøring via en 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

Lagre dette som pvc.yaml, og bruk kubectl apply -f pvc.yaml for å ta det i bruk.

Når en PVC er bundet, kan en Pod bruke den ved å referere til PVC-ens navn i volumkonfigurasjonen. Pod-en trenger ikke å kjenne til det underliggende PV-et, bare PVC-en.

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

Denne Pod-en skriver en fil til det monterte persistente volumet.

De kan overvåke ressursene for persistent lagring ved hjelp av kubectl:

• Se alle PVs: kubectl get pv
• Se alle PVCs i namespace-et Deres: kubectl get pvc
• Hent detaljert informasjon, inkludert status og hendelser:
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

Kontroller at PVs har status Bound, og at PVCs er Bound til riktig PV.

Vi har gått gjennom hvordan Kubernetes administrerer varig lagring for applikasjonene Deres:

• PersistentVolumes (PVs) er klyngeressurser som representerer faktisk lagring.
• PersistentVolumeClaims (PVCs) er brukernes forespørsler om lagring.
• Kubernetes binder PVCs til egnede PVs basert på kravene.
• Tilgangsmoduser definerer hvordan lagring kan brukes (RWO, ROX og RWX).
• StorageClasses muliggjør dynamisk klargjøring av PVs og automatiserer oppsettet.

Dette systemet sikrer at applikasjonsdataene bevares selv om Pods kommer og går, og gir pålitelighet for tilstandsfulle applikasjoner.