Persistent Volume Claims in Kubernetes Explained

-

 

Understand how Persistent Volume Claims work in Kubernetes, including static vs dynamic provisioning, access modes, and reclaim policies.

Persistent Volume Claims (PVCs)

Persistent Volume Claims (PVCs) are the only supported way to consume durable storage inside Kubernetes Pods.

Pods cannot mount Persistent Volumes (PVs) directly. Instead, they request storage through a PVC, and Kubernetes takes care of binding that claim to a suitable volume.

What Is a Persistent Volume Claim?

A PersistentVolumeClaim is an abstraction that:

  • Reserves an existing PersistentVolume (static provisioning), or
  • Triggers the creation of a new PersistentVolume (dynamic provisioning)

In both cases, the PVC becomes the contract between your Pod and the storage backend.

Important rule:
The relationship between a PVC and a PV is strictly 1-to-1.

  • One PVC → one PV
  • One PV → at most one PVC

Static vs Dynamic Provisioning

Static Provisioning

With static provisioning:

  1. You manually create PersistentVolumes first
  2. A PVC is created later
  3. Kubernetes performs a best-effort match based on:
    • Requested size
    • Access mode
    • Storage class (if specified)

⚠️ If no matching PV exists, the PVC will remain Pending.

Example pitfall

If a PV has 10Gi and a PVC requests 1Gi:

  • The PVC binds successfully
  • The remaining 9Gi cannot be reused
  • This unused capacity is lost to other claims

This is why static provisioning requires careful capacity planning.

Dynamic Provisioning

With dynamic provisioning:

  1. You create a PVC
  2. Kubernetes automatically provisions a PV behind the scenes
  3. The volume matches the exact request

As long as the backend supports:

  • The requested size
  • The requested access mode

…the claim will always be fulfilled.

This is why dynamic provisioning is strongly recommended, especially in cloud environments.

Reclaim Policies

When a PVC is deleted, Kubernetes must decide what to do with the underlying PV.

Available reclaim policies

PolicyBehavior
DeleteDeletes the underlying storage (default for dynamic provisioning)
RetainKeeps the volume and its data
RecycleDeprecated

When to use Retain

  • Auditing or forensic analysis
  • Manual data recovery
  • Controlled cleanup workflows

Access Modes Explained

Access modes define how a volume can be mounted, not how many Pods use it.

Common access modes

  • ReadWriteOnce (RWO)

    • Mounted read-write by a single node
    • Multiple Pods on that node may use it

  • ReadOnlyMany (ROX)

    • Mounted read-only by many nodes

  • ReadWriteMany (RWX)

    • Mounted read-write by many nodes
    • Requires shared storage (e.g. NFS, CephFS)

  • ReadWriteOncePod (RWOP)

    • Mounted read-write by exactly one Pod
    • Strongest isolation guarantee

If you need to restrict a volume to a single Pod, you must use ReadWriteOncePod.
ReadWriteOnce alone does not guarantee this.

How Pods Use PVCs

From the Pod’s perspective:

  • A PVC is just a volume reference
  • It doesn’t matter whether the PV is:
    • Statically provisioned
    • Dynamically provisioned

A single Pod can mount multiple PVCs, and each PVC may come from a different storage backend.

Summary

  • PVCs are mandatory for using persistent storage in Pods
  • PVC ↔ PV is always a 1-to-1 relationship
  • Static provisioning is best-effort
  • Dynamic provisioning is predictable and safer
  • Access modes control where and how volumes can be mounted
  • Reclaim policies determine what happens to data after deletion



Comments

Post a Comment

Popular posts from this blog

Highlights from the 2025 Stack Overflow Developer Survey

-
Image
Introduction The  15th Annual Stack Overflow Developer Survey  is now out. With over  49,000 responses  from  177 countries , the 2025 findings offer a rich view into how developers work—and how they feel—amid rising AI adoption ( survey.stackoverflow.co ,  survey.stackoverflow.co ). Dev & AI Trends at a Glance Widespread AI Adoption Coupled with Waning Trust A whopping  84%  of developers now use—or plan to use—AI tools in their workflows, up from  76%  last year ( survey.stackoverflow.co ). Yet trust in AI is falling dramatically:  46%  say they do  not trust  AI output, compared to just  31%  in 2024 ( itpro.com ). Positive sentiment toward AI tools dropped from over 70% to roughly  60%  this year ( survey.stackoverflow.co ). The top frustration? Developers cite “ AI solutions that are almost right, but not quite ” as a pain point—leading to increased time spent debugging ( survey.stackoverf...
Read more

Mastering Caddy Logging: A Complete Guide to Access, Error, and Structured Logs

-
Image
  Mastering Logging in Caddy Caddy is a modern, lightweight, and secure web server that’s rapidly gaining popularity thanks to its simplicity, automatic HTTPS, and powerful configuration options. One of the most important aspects of managing a Caddy-powered application is  logging . Proper logging ensures you have visibility into your system, can debug issues efficiently, and monitor performance in real-time. In this article, we’ll break down how logging works in Caddy, why it matters, and how you can configure it for your own projects. What is Logging in Caddy? Logging in Caddy refers to the process of capturing details about requests, errors, and internal server behavior. With logs, you can: Track incoming requests and responses Debug configuration or runtime issues Monitor server performance and health Meet compliance and audit requirements Caddy uses a structured logging system, making logs easier to parse and integrate with external monitoring tools like  Better Stac...
Read more

psql: error: connection to server at "localhost" (127.0.0.1), port 5433 failed: ERROR: failed to authenticate with backend using SCRAM DETAIL: valid password not found

-
Image
ERROR psql: error: connection to server at "localhost" (127.0.0.1), port 5433 failed: ERROR: failed to authenticate with backend using SCRAM DETAIL: valid password not found Since Pgpool-II is a PostgreSQL proxy that works between clients and PostgreSQL servers, the authentication comprises two steps: Authentication between client and Pgpool-II Authentication between Pgpool-II and PostgreSQL servers Starting with Pgpool-II 4.0, Pgpool-II supports scram-sha-256 authentication. scram-sha-256 authentication method is strongly recommended because it is the most secure password-based authentication method. Solution 1 If PostgreSQL servers require  MD5  or  SCRAM  authentication for some user’s authentication but the password for that user is not present in  pool_passwd , then enabling  allow_clear_text_frontend_auth  will allow the  Pgpool-II  to use clear-text-password authentication with user to get the password in plain text form from the user ...
Read more