🏗️ [Kubernetes] Why You Shouldn’t Directly Attach Disks to Pods (The Necessity of PV, PVC, SC)

Dec 17, 2025

—

Hello everyone! Today, we’re going to dive deep into why PV (PersistentVolume), PVC (PersistentVolumeClaim), and SC (StorageClass), which can be called the “flower” of Kubernetes storage, are absolutely necessary.

When you first start learning Kubernetes, you might have this question:

> _”Wouldn’t it be easier to just directly write the AWS EBS ID or NFS path in the Pod configuration file (YAML)?

> Why bother creating and connecting PVs and PVCs separately in such a complex way?”_

To get straight to the point, it’s because “direct connection might seem convenient, but it’s a shortcut to hell.” We’ll explain why, and how the PV/PVC system saves us, with 4 key reasons. 🚀

1. ☁️ Destruction of Portability: “My Pod can only live on AWS!”

Let’s assume you directly wrote a specific cloud’s volume ID in your Pod YAML file.

YAML

# ❌ Bad example (direct attachment)
volumes:
  - name: my-data
    awsElasticBlockStore: # Dependent on AWS!
      volumeID: 
      fsType: ext4

The biggest problem with this approach is dependency (Lock-in).

Problem: This Pod only works in an AWS environment. What if your company moves to Google Cloud (GCP) or an on-premise (IDC) environment? This YAML file becomes garbage. You’d have to modify everything manually.
Solution (PVC): With PVCs, developers only make an abstract request like “I need 10GB of storage”. They don’t need to care whether the actual storage is AWS, Azure, or a local disk.

2. 👨‍💻 Separation of Roles (DevOps Philosophy): “Developers don’t need to know infrastructure”

Kubernetes aims to clearly separate the roles of Developer and Operator (Admin/Ops).

With direct attachment: To launch a Pod, a developer would need to know detailed information such as the storage server’s IP address, disk ID, and file system type. This creates a burden for developers to learn complex infrastructure details.
With PV/PVC:
Operator (Admin): Sets up the storage infrastructure and configures PVs (resources) or SCs (StorageClasses).
Developer (User): Can create a PVC (request) without knowing the infrastructure details. It’s like submitting a ticket saying, “Admin, please give me 50GB of fast disk!”

3. ⚡ The Magic of Dynamic Provisioning

One of the most powerful reasons is the ‘automation’ made possible by StorageClass (SC).

Direct attachment/Manual management: If you need 100 Pods, an operator would have to go into the cloud console, manually click to create 100 disks, and then retrieve their IDs. Horrible, right? 😱
With SC: If a StorageClass is defined, the moment a developer creates a PVC, Kubernetes automatically commands the cloud to create the disk and attach it to the Pod.

This process happens automatically in just a few seconds.

4. 🛡️ Resource Management and Security

Storage is an expensive resource. We shouldn’t let just anyone use it indiscriminately, right?

With direct attachment: There’s a risk that developers might arbitrarily connect very expensive high-performance disks or make configurations that don’t align with company policies.
PV/PVC pattern: Operators can restrict the types of disks that can be created via StorageClass or control the total amount of storage a specific team can use via ResourceQuota. This enables systematic resource management.

📝 Summary: PV, PVC, SC Relationship Diagram

To help with understanding, let’s use a restaurant analogy. 🍽️

Kubernetes Concept	Analogy (Restaurant)	Explanation
Pod	Customer	The entity that wants to consume food (data space)
PVC (Claim)	Order Slip	“One bowl of rice (10GB) please!” (Request)
StorageClass	Chef/Menu Policy	How to cook rice and policies when an order comes in
PV (Volume)	Actual Bowl of Rice	The prepared rice (provisioned storage resource)
Actual Disk	Rice Grains	The raw material for making rice (AWS EBS, NFS, etc.)

The Customer (Pod) places an Order (PVC).
The Chef (StorageClass) sees the order and cooks Rice (PV) using Rice Grains (Actual Disk). (Dynamic Provisioning)
The prepared Rice (PV) is matched (Bound) with the Order (PVC) and served to the customer.

💡 Conclusion

Directly attaching disks to Pods is like hammering in every single nail when pitching a tent by yourself. On the other hand, using PV, PVC, and SC is like “checking into a hotel.”

We simply say, “I need a room (PVC)”, and the hotel system (K8s) automatically handles it by saying, “Here’s your key (PV binding)”.

To properly use Kubernetes in a production environment, you must understand and utilize this Abstraction Layer! 😊