How to Provision and Bind Kubernetes Persistent Volume Claims

Introduction

This tutorial will guide you through the process of understanding Kubernetes Persistent Volumes, provisioning and binding Persistent Volume Claims, and mounting them to your containers. Kubernetes Persistent Volumes provide a way to abstract the underlying storage implementation, allowing your applications to use durable storage without needing to know the details of how that storage is provisioned and managed.

Skills Graph

Understanding Kubernetes Persistent Volumes

Kubernetes Persistent Volumes (PVs) are a way to provide durable storage to your applications running in a Kubernetes cluster. PVs are abstracted from the underlying storage implementation, allowing your applications to use storage without needing to know the details of how that storage is provisioned and managed.

PVs are a Kubernetes resource, just like Pods, Services, and Deployments. They represent a piece of storage in your cluster, such as a local disk, an NFS share, or a cloud storage volume. PVs have a lifecycle independent of any individual Pod that uses the storage.

Persistent Volume Types

Kubernetes supports several types of persistent volumes, including:

• Local: A volume that is backed by a directory on the node where the Pod is running. This is useful for applications that need fast, low-latency storage, but it has the downside of being tied to a specific node.
• NFS: A network-attached storage volume that can be accessed by multiple Pods.
• AWS EBS: A volume backed by an Amazon Elastic Block Store (EBS) volume.
• Azure Disk: A volume backed by an Azure Disk.
• GCP PersistentDisk: A volume backed by a Google Compute Engine persistent disk.

The choice of persistent volume type depends on the needs of your application, such as performance, durability, and availability requirements.

Persistent Volume Access Modes

Persistent volumes can be accessed in different ways, called "access modes". The available access modes are:

• ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node.
• ReadOnlyMany (ROX): The volume can be mounted as read-only by multiple nodes.
• ReadWriteMany (RWX): The volume can be mounted as read-write by multiple nodes.

The access mode of a persistent volume determines how it can be used by Pods.

Persistent Volume Example

Here's an example of a persistent volume definition in a Kubernetes manifest:

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

This persistent volume is backed by a directory on the node where the Pod is running. It has a capacity of 5 gigabytes and can be accessed in read-write mode by a single node.

Provisioning and Binding Persistent Volume Claims

Persistent Volume Claims (PVCs) are the way that Pods request storage in a Kubernetes cluster. A PVC specifies the size, access mode, and other parameters of the storage that an application needs. The Kubernetes control plane then finds a suitable Persistent Volume (PV) to bind to the PVC.

Persistent Volume Provisioning

Persistent volumes can be provisioned in two ways:

1. Static Provisioning: The cluster administrator creates PVs manually, and then Pods can claim those PVs using PVCs.
2. Dynamic Provisioning: Kubernetes can automatically create PVs when a PVC is created, using a Storage Class. Storage Classes specify the type of storage to provision and other parameters.

Here's an example of a Storage Class definition:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
  fstype: ext4
  encrypted: "true"

This Storage Class provisions Google Compute Engine persistent disks with the pd-standard type, the ext4 filesystem, and encryption enabled.

Persistent Volume Binding

When a Pod creates a PVC, Kubernetes will find a suitable PV to bind to the claim. The binding process follows these steps:

1. The PVC requests storage with specific parameters (size, access mode, etc.).
2. Kubernetes searches for a PV that matches the PVC's requirements.
3. If a matching PV is found, it is bound to the PVC.
4. If no matching PV is found, and dynamic provisioning is enabled, a new PV is created and bound to the PVC.

Here's an example of a Persistent Volume Claim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

This PVC requests a 5 gigabyte volume that can be accessed in read-write mode by a single node.

Mounting Persistent Volumes to Containers

Once a Persistent Volume Claim (PVC) has been bound to a Persistent Volume (PV), the next step is to mount the storage to the containers in your Pods. This is done using the volumeMounts field in the Pod specification.

Mounting Volumes in Pods

Here's an example of a Pod that mounts a PVC to a container:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-container
    image: my-app:v1
    volumeMounts:
    - name: my-storage
      mountPath: /data
  volumes:
  - name: my-storage
    persistentVolumeClaim:
      claimName: my-pvc

In this example, the Pod has a single container that mounts the storage from the my-pvc PVC to the /data directory in the container.

The volumes section of the Pod spec defines the volume sources that can be mounted, in this case a PersistentVolumeClaim. The volumeMounts section in the container spec tells Kubernetes where to mount the volume inside the container.

Volume Lifecycle

Persistent volumes have a lifecycle independent of the Pods that use them. When a Pod is deleted, the underlying PV is not automatically deleted. This allows the data to persist even if the Pod is recreated or rescheduled to a different node.

However, when a PVC is deleted, the associated PV can be automatically deleted, retained, or recycled, depending on the reclaim policy set on the PV.

Volume Permissions

By default, Kubernetes mounts volumes with the same permissions as the underlying storage. In some cases, you may need to set specific permissions on the mounted volume, such as the user or group that can access the data. This can be done using the fsGroup and runAsUser fields in the Pod spec.

Overall, mounting Persistent Volumes to containers in Kubernetes provides a way to persist data beyond the lifecycle of individual Pods, allowing your applications to maintain state and access necessary data.

Summary

In this tutorial, you learned about Kubernetes Persistent Volumes, the different types of persistent volumes supported, and the access modes available. You also learned how to provision and bind Persistent Volume Claims, and mount them to your containers. By understanding and utilizing Persistent Volumes, you can ensure your applications have access to durable storage, regardless of the underlying storage implementation in your Kubernetes cluster.