Last modified September 22, 2020
Using Persistent Volumes on Azure
If your cluster is running in the cloud on Azure, it comes with four dynamic storage provisioners using different flavours of Azure Disks and Azure File shares. This enables you to store data beyond the lifetime of a Pod.
Storage Classes are:
- managed-premium (the default one): Provisions a
Managed diskand thus can be used only on kubernetes nodes that run on supported VM types (those with an
sin their name).
- managed-standard: Provisions a
Managed diskand can be used on any VM instance type.
- af-premium: Provisions a volume backed by the
Azure File Shareservice within a
Premium LRSstorage account.
- af-standard: Provisions a volume backed by the
Azure File Shareservice within a
Standard LRSstorage account.
Creating Persistent Volumes
The most straight forward way to create a Persistent Volume is to create a Persistent Volume Claim object.
Please ensure to specify the right
Storage Class to have the desired type of volume automatically provisioned for you.
Alternatively, to be able to set more specific parameters on your PV you can first create a Persistent Volume object and then claim that PV using a Persistent Volume Claim (PVC).
Under the hood, the Dynamic Storage Provisioner will take care that a corresponding
Azure File Share or
Managed Disk gets created.
The Volume and its data will persist as long as the corresponding PV resource exists. Deleting the resource will also delete the corresponding volume, which means that all stored data will be lost at that point.
Using Persistent Volumes in a Pod
Once you have a Persistent Volume Claim you can claim it as a Volume in your Pods.
Note that an
Azure Disk volumes can only be used by a single Pod at a time. Thus, the access mode of your PVC can only be
This limitation doesn’t apply to
Azure File Share volumes, that can be attached with the
First we create a PVC:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 6Gi storageClassName: managed-standard
Now we can create a Pod that uses our PVC:
kind: Pod apiVersion: v1 metadata: name: mypod spec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: myclaim
Now we have an NGINX Pod which serves the contents of our Azure Managed Disk Volume.
Expanding Persistent Volume Claims
Starting with volumes created on Giantswarm release 13.0.0
Persistent Volume Claims can be expanded by simply editing the claim and requesting a larger size.
It will trigger an update in the underlying Persistent Volume and Azure Volume (Kubernetes always uses the existing one).
Please note that for
Managed Disk-based volumes, it is mandatory to release the PVC (i.e. stop the Pod that is mounting it) before the resize operation begins.
This is a limitation of Azure Cloud that does not apply to
Azure File Share-based volumes.
Deleting Persistent Volumes
By default the Reclaim Policy of Persistent Volumes in your cluster is set to
Delete. Thus, deleting the
PersistentVolume resource will also delete the respective Azure Disk or Azure File Share.
Similarly, by default if you delete a
PersistenVolumeClaim resource the respective Persistent Volume and Azure resource will get deleted.
Note that deleting an application that is using Persistent Volumes might not automatically also delete its storage, so in most cases you will have to manually delete the
PersistenVolumeClaim resources to clean up.