Wat is een Kubernetes persistent volume?

Het beheer van opslag voor stateful applicaties is een cruciaal aspect van containerorkestratie. Kubernetes Persistent Volume (PV ) is een fundamentele functie die deze behoefte aanpakt door een mechanisme te bieden om opslagresources onafhankelijk van de levenscyclus van individuele pods te beheren. In dit artikel gaan we in op het concept van Kubernetes Persistent Volume, de functies en best practices om het effectief te gebruiken in uw Kubernetes-clusters.

Wat is Kubernetes persistent volume?

Een Kubernetes Persistent Volume (PV ) is een opslagresource in een Kubernetes-cluster dat de onderliggende opslagtechnologie abstractiseert. In tegenstelling tot tijdelijke opslag, die is gekoppeld aan de levenscyclus van een pod en verdwijnt wanneer de pod wordt beëindigd, bieden PV's een manier om persistente opslag te beheren en toe te wijzen aan toepassingen. Dit zorgt ervoor dat data intact blijven, zelfs als de pods die er toegang toe hebben, worden beëindigd of opnieuw worden gepland.

Het gebruik van persistente volumes biedt voordelen zoals:

• Storage abstractie: PV's verbergen de details van de fysieke opslag (bijv. lokale schijven, SAN, cloudopslag) voor de pods. Gebruikers kunnen opslag aanvragen zonder de specifieke implementatiedetails te hoeven kennen.
• Persistentie: PV's garanderen datapersistentie, zelfs bij herstarts of herplanning van pods. Stelt u zich een webserverpod voor die vluchtige opslag gebruikt om tijdelijke logs op te slaan. Wanneer de pod opnieuw opstart, gaan die logs verloren. Permanente opslag daarentegen zorgt ervoor dat data, zoals applicatiedata die door een databasepod worden onderhouden, intact blijven.
• Opslag loskoppelen van pods: Deze scheiding zorgt voor meer flexibiliteit en controle over opslagresources. Pods kunnen gemakkelijk worden opgeschaald of verlaagd zonder de onderliggende opslag te beïnvloeden.

Belangrijkste kenmerken van Kubernetes Persistent Volumes

Kubernetes Persistent Volumes bieden verschillende belangrijke functies die ze krachtig en aanpasbaar maken voor diverse opslagbehoeften:

Opslagklassen

Opslagklassen werken als sjablonen die verschillende niveaus of categorieën van opslag definiëren die in een cluster beschikbaar zijn. Ze kunnen kenmerken specificeren zoals prestaties (bijv. SSD vs. HDD), capaciteit, duurzaamheid en kosten. Hierdoor kunnen beheerders opslag aanbieden die is afgestemd op de specifieke vereisten van applicaties.

Toegangsmodi

Toegangsmodi definiëren hoe pods kunnen interageren met de opslag die door een PV wordt geleverd. Hier is een overzicht van de algemene modi:

• ReadWriteOnce (RWO): Slechts één pod tegelijk kan het volume met lees-schrijfrechten monteren. Dit zorgt voor data-integriteit voor applicaties die exclusieve schrijftoegang vereisen, zoals een primaire databasereplica.
• ReadOnlyVeel (ROX): Meerdere pods kunnen het volume tegelijkertijd monteren, maar alleen in de alleen-lezenmodus. Dit is nuttig voor scenario's waarin applicaties zonder wijziging toegang moeten hebben tot gedeelde data, zoals een configuratiebestand of logopslagplaats.
• ReadWriteMany (RWX): Meerdere pods kunnen het volume monteren met lees-schrijfmachtigingen. Deze toegangsmodus moet met voorzichtigheid worden gebruikt vanwege potentiële data-inconsistenties als meerdere pods gelijktijdig schrijven. Het is ideaal voor specifieke gebruikssituaties zoals gedeelde caches of gezamenlijke bewerkingstools.

Terugvorderingsbeleid

Het terugvorderingsbeleid bepaalt hoe Kubernetes omgaat met een PV nadat deze niet langer aan een pod is gebonden. Het belangrijkste beleid omvat:

• Behouden: De PV blijft na het ontbinden van de pod, waardoor handmatig beheer mogelijk is voor mogelijk toekomstig gebruik of migratie.
• Recyclen: Kubernetes recyclet de PV. Dit omvat meestal het wissen van bestaande data en het beschikbaar stellen van de opslag voor toekomstige podtoewijzingen.
• Verwijderen: Het PV-object en de onderliggende opslagresource worden volledig verwijderd. Gebruik dit voorzichtig, omdat data recovery misschien niet mogelijk is.
  

Volume plug-ins

Kubernetes maakt gebruik van volumeplug-ins om de kloof tussen het platform en verschillende opslagaanbieders te overbruggen. Deze plug-ins stellen Kubernetes in staat om diverse backends voor opslag te begrijpen en ermee te communiceren, waaronder lokale opslag, network attached storage (NAS)-oplossingen zoals NFS of iSCSI en cloudprovider-specifieke opslagdiensten zoals AWS EBS of GCE Persistent Disk. Deze plug-in-architectuur biedt aanzienlijke flexibiliteit bij het kiezen en integreren van opslagoplossingen met uw Kubernetes-cluster.

Voortdurende volumes leveren

Kubernetes biedt twee primaire methoden voor het leveren van persistente volumes (PV's): statische provisioning en dynamische provisioning. Elke aanpak is geschikt voor verschillende gebruikssituaties en biedt verschillende voordelen.

Statische provisioning

Bij statische provisioning maken en configureren clusterbeheerders handmatig PV's vooraf. Deze aanpak biedt gedetailleerde controle over de opslagconfiguratie en is geschikt voor scenario's met goed gedefinieerde opslagvereisten die niet vaak veranderen. Om statisch een PV te leveren:

1. Definieer de opslagdetails: Bepaal de opslagcapaciteit, de toegangsmodi (ReadWriteOnce, ReadOnlyMany, ReadWriteMany), het reclaimbeleid (Retain, Recycle, Delete) en de specifieke kenmerken van de volumeplugin (bijv. serveradres voor NFS).

2. Creëer het PV-object met YAML: Gebruik een YAML-manifestbestand om de PV-configuratie te definiëren. Hier is een voorbeeld van NFS-opslag:

apiVersion: v1
 kind: PersistentVolume
 metadata:
   name: my-pv-nfs
 spec:
   capacity:
     storage: 10Gi
   accessModes:
     - ReadWriteOnce
   persistentVolumeReclaimPolicy: Retain
   nfs:
     path: /path/to/nfs/share
     server: nfs-server.example.com

• naam : Unieke naam voor de PV .
• Opslag: Gewenste opslagcapaciteit (bijv. 10Gi voor 10 Gigabytes).
• ToegangModes: Kies de juiste toegangsmodus op basis van de vereisten van uw toepassing.
• persistentVolumeReclaimBeleid: Definieer hoe Kubernetes de PV moet verwerken nadat deze niet meer van een pod is gebonden.
• nfs.path : Pad naar het NFS-aandeel op de NFS-server.
• nfs.server : IP-adres of hostnaam van de NFS-server.

3. Pas het YAML-manifest toe: Gebruik de opdracht kubectl apply -f om het PV-object in uw Kubernetes-cluster te creëren.

Dynamische provisioning

Dynamische provisioning maakt gebruik van StorageClasses om PV-creatie te automatiseren. Beheerders definiëren StorageClasses die de gewenste opslagkenmerken specificeren en Kubernetes de PV-creatie on-demand laten afhandelen wanneer een PersistentVolumeClaim (PVC) om opslag vraagt. Om dynamische provisioning te gebruiken:

1. Definieer een StorageClass: Maak een StorageClass YAML-manifest aan met de provisioner, het storagetype (bijv. SSD, HDD) en eventuele aanvullende parameters die door de provisioner worden vereist. Hier is een voorbeeld voor AWS EBS:

apiVersion: storage.k8s.io/v1
 kind: StorageClass
 metadata:
   name: standard-ebs
 provisioner: kubernetes.io/aws-ebs
 parameters:
   type: gp2

• naam : Unieke naam voor de StorageClass.
• provisioner : Naam van de storage provisioner plug-in (bijv. kubernetes.io/aws-ebs voor AWS EBS).
• parameters.type: Opslagtype binnen de provisioner (bijv. gp2 voor een universeel SSD-volumetype in AWS EBS).

2. Pas het StorageClass-manifest toe: Gebruik kubectl apply -f om het StorageClass-object in uw cluster te creëren.

Blijvende volumes aan Pods

Het binden van een PV aan een pod stelt applicaties in staat om gebruik te maken van persistente opslag. Deze binding wordt doorgaans bereikt door een PersistentVolumeClaim (PVC).

Een PVC fungeert als een opslagverzoek dat door een pod wordt ingediend. Het specificeert de opslagvereisten die een pod heeft, waaronder:

• Toegangsmodi: Definieert hoe de pod kan communiceren met de opslag (bijv. ReadWriteOnce, ReadOnlyMany, ReadWriteMany).
• Opslagcapaciteit: De gewenste hoeveelheid opslag voor de pod.
• StorageClassName (optioneel): Verwijst naar een StorageClass voor dynamische provisioning.

Er zijn twee primaire methoden om PV's aan pods te binden:

• Statische binding: In statische binding maken beheerders handmatig een PVC dat expliciet verwijst naar een vooraf voorziene PV. De PVC en PV moeten compatibele kenmerken hebben, zoals overeenkomende toegangsmodi en voldoende opslagcapaciteit in de PV, om aan het verzoek van de PVC te voldoen.
• Dynamische binding: Dynamic binding maakt gebruik van StorageClasses voor geautomatiseerde PV-creatie. Wanneer een pod met een PVC die verwijst naar een StorageClass wordt ingezet, zoekt Kubernetes naar een geschikte PV (bestaand of nieuw ingericht op basis van de StorageClass) die voldoet aan de eisen van de PVC. Als een geschikte PV wordt gevonden, bindt Kubernetes de PV en PVC automatisch aan elkaar.

Hier is een voorbeeld van een pod genaamd "pod-voorbeeld" die gebruikmaakt van een PVC genaamd "pvc-voorbeeld":

apiVersion: v1
 kind: Pod
 metadata:
   name: pod-example
 spec:
   containers:
   - name: app
     image: nginx
     volumeMounts:
     - mountPath: "/usr/share/nginx/html"
       name: pvc-storage
   volumes:
   - name: pvc-storage
     persistentVolumeClaim:
       claimName: pvc-example

In dit voorbeeld monteert de pod het PVC genaamd "pvc-voorbeeld" op het pad "/usr/share/nginx/html" in de container. Hierdoor heeft de pod toegang tot zijn persistente data die in de onderliggende PV zijn opgeslagen en kan hij deze beheren.

Beheren van persistente volumes

Het is absoluut noodzakelijk om uw persistente volumes (PV's) effectief te beheren om een efficiënt en schaalbaar opslaggebruik in uw Kubernetes-cluster te behouden. Enkele belangrijke aspecten van PV-beheer zijn:

1. De grootte van persistente volumes aanpassen

Kubernetes v1.11 introduceerde de mogelijkheid om de grootte van PV's te wijzigen. Hierdoor kunt u de opslagcapaciteit die aan een PV is toegewezen dynamisch aanpassen, zodat u kunt voldoen aan de groeiende opslagvereisten van uw applicaties. 

Om de grootte van een PV te wijzigen, werkt u het opslagverzoek van de PVC bij: Bewerk het PVC dat verwijst naar de PV en wijzig de opslagwaarde binnen de resources.vraagt om sectie van de YAML-specificatie van het PVC. Om bijvoorbeeld de grootte van een PVC genaamd "pvc-voorbeeld" te vergroten naar 20Gi, moet u het YAML-manifest bijwerken:

apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name: pvc-example
 spec:
   resources:
     requests:
       storage: 20Gi

Zodra u het opslagverzoek van PVC bijwerkt, probeert Kubernetes de grootte van de onderliggende opslag die voor de PV is voorzien te wijzigen. Het aanpassen van de grootte van een PV is over het algemeen een eenrichtingsoperatie (uitbreiding van opslag). Het verkleinen van de omvang van een PV wordt niet ondersteund vanwege mogelijke problemen met dataverlies.

2. Permanente volumes verwijderen

Om een PV te verwijderen, moet u ervoor zorgen dat deze momenteel niet gebonden is aan PVC's. U kunt een PV die door een PVC wordt gebruikt niet verwijderen om dataverlies te voorkomen. Zo kunt u een PV verwijderen:

kubectl delete pv pv-example

Vervang pv-voorbeeld door de werkelijke naam van de PV die u wilt verwijderen.

3. Permanente volumes bijwerken

Hoewel de kernopslagcapaciteit niet direct kan worden gewijzigd binnen een PV-object, kunt u bepaalde Metadata veldenvan een PV bijwerken, zoals labels of annotaties. Deze labels en annotaties kunnen worden gebruikt om uw PV's binnen het cluster beter te organiseren, te identificeren en te beheren.

Best practices voor het gebruik van Kubernetes Persistent Volumes

Hieronder volgen enkele van de beste praktijken die u moet volgen om het meeste uit Kubernetes persistente volumes te halen:

• Selecteer de juiste opslagklassen: Kies opslagklassen die voldoen aan de prestatie- en duurzaamheidsvereisten van uw applicaties. Gebruik bijvoorbeeld SSD-backed opslag voor krachtige toepassingen en HDD-backed opslag voor archiveringsdoeleinden.
• Configureer toegangsmodi correct: Selecteer de juiste toegangsmodus voor uw PV op basis van hoe uw applicaties toegang moeten hebben tot de opslag. U kunt bijvoorbeeld RWX gebruiken voor gedeelde bestandssystemen en RWO voor single-instance databases.
• Implementeer het terugvorderingsbeleid verstandig: Stel terugvorderingsbeleid in dat overeenkomt met uw strategie voor data lifecycle management. Gebruik het bewaarbeleid voor kritieke data waarvoor handmatige tussenkomst vereist is vóór verwijdering.
• Monitoring en logging: Gebruik monitoring- en loggingtools om het PV-gebruik, de prestaties en de gezondheid te monitoren. Tools zoals Prometheus en Grafana kunnen waardevolle inzichten bieden in uw opslaginfrastructuur.
• Gebruik Portworx ® voor geavanceerd datamanagement: Voor geavanceerde datamanagement- en persistente opslagoplossingen in Kubernetes kunt u overwegen Portworx van Pure Storage te gebruiken. Portworx biedt functies zoals hoge beschikbaarheid, disaster recovery en back-up die speciaal zijn ontworpen voor gecontaineriseerde toepassingen.

Conclusie

Kubernetes Persistent Volumes (PV's) bieden een fundamenteel mechanisme voor het beheer van opslag in stateful applicaties. Door gebruik te maken van PV's kunt u zorgen voor datapersistentie, hoge beschikbaarheid en efficiënt opslaggebruik binnen uw Kubernetes-cluster. Oplossingen zoals Portworx van Pure Storage bieden een intuïtieve manier om de voordelen van Kubernetes' persistente volumes te benutten. Met functies zoals hoge beschikbaarheid, disaster recovery en back-up die kunstmatige intelligentie gebruiken voor verbeterde efficiëntie, is Portworx de ideale Kubernetes persistente opslagoplossing voor gecontaineriseerde toepassingen.