Manage PV and PVC Binding in Helm Templates: From Challenges to Solutions

4 min readSep 24, 2024

Intro to Helm

Helm is a powerful package manager for Kubernetes, enabling developers to automate the deployment, scaling, and management of applications.
It uses “charts” — pre-configured templates of Kubernetes resources — to simplify the installation of complex applications.
Helm streamlines Kubernetes deployments by allowing users to version, share, and reuse configurations across different environments.

Importance of Helm Templates in Simplifying Kubernetes Deployments:

Helm templates provide a dynamic way to manage Kubernetes resources, avoiding the need for repetitive and error-prone YAML writing.
Templates allow users to define variables and conditions, making it easy to customize deployments for various environments (dev, staging, production).
With Helm, teams can deploy and upgrade applications with minimal manual intervention, ensuring consistency across deployments.

PV and PVC are the Kubernetes resources available. Let’s understand what they are ? and how they are used within Kubernetes:

What are Persistent Volumes (PV) and Persistent Volume Claims (PVC)?

Persistent Volumes (PV): PVs are storage resources in Kubernetes that exist independently of pods, offering a way to store data beyond the lifecycle of individual containers. That means even if the containers removed, they can again access the data that they have stored previously.
Persistent Volume Claims (PVC): PVCs are requests by applications (or pods) for storage. They specify the storage size and access modes required. When a PVC is created, Kubernetes finds a PV to bind it to.

Why PV and PVC are Critical for Data Persistence in Kubernetes:

Kubernetes pods are ephemeral by nature, meaning they can be restarted or terminated at any time, which would result in data loss without persistent storage.
PV and PVC ensure that data persistency is maintained independently of the pods, allowing applications to store data that is maintained outside the lifecycle of containers.
They provide a layer of abstraction between the application and the underlying storage infrastructure, making it easier to manage storage across cloud platforms or on-premise systems.

Use Case Scenario

Scenario 1:

Suppose we have a deployment that is going to use a PVC to access a PV. Below is the definition for PV and PVC:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: shared-volume
spec:
  storageClassName: shared-storage
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: "/mnt/shared-volume"

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-volume-claim
  namespace: monitoring
spec:
  storageClassName: shared-storage
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

With this definition, it will create a PV and PVC and bind them together within current helm release. That’s an ideal case by the way.

Scenario 2:

Suppose we have a deployment that is going to use 2 PVCs to access two different PVs. Below is the definition for PVs and PVCs:

PV 1 and PVC 1 are defined below:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: shared-volume-1
spec:
  storageClassName: shared-storage
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: "/mnt/shared-volume"

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-volume-claim-1
  namespace: monitoring
spec:
  storageClassName: shared-storage
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

Here is the details about PV 2 and PVC 2:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: shared-volume-2
spec:
  storageClassName: shared-storage
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: "/mnt/shared-volume"

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-volume-claim-2
  namespace: monitoring
spec:
  storageClassName: shared-storage
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

What you suggest ? Will it behave the same as per the ideal case in this scenario?

The answer is no!!! Because it create both the PVs and both the PVCs but at the time of binding them they can be mismatched as they don’t have any proper mechanism to match the perfect PV for a PVC. So the scenario can be visualized like:

This scenario can change the whole architecture of the application and hamper the functionality of the same.

Resolution to the problem:

To achieve the ideal state of the same, we have to use labels and selectors in PV and PVCs respectively so that they can find a perfect match of PV and PVC on the basis of these labels.
Here is an example of their definitions with labels and selectors:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: shared-volume
  labels:
    type: volume
spec:
  storageClassName: shared-storage
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  hostPath:
    path: "/mnt/shared-volume"

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-volume-claim
  namespace: monitoring
spec:
  storageClassName: shared-storage
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  selector:
    matchLabels:
      type: volume

Here it for first PV and PVC. Create yours for the second one and also for more number of PV and PVCs as per the requirements.

Hope this will help you managing persistent storage in a scenario where you have n number of PV and PVCs.

Stay tuned for more such concepts of Kubernetes!!😄

🌟 Keep Learning, Keep Sharing 🌟