Why PersistentVolumeClaim (PVC) definition in Kubernetes? - Purpose & Use Cases

The Big Idea

What if your app's important data vanished every time it restarted? PVCs stop that nightmare.

The Scenario

Imagine you have a container running an app that needs to save files. You try to store data inside the container itself.

But when the container stops or restarts, all your saved files vanish!

The Problem

Saving data inside containers is like writing notes on a whiteboard that gets erased every time you clean the room.

Manually managing storage for containers is slow and risky because data can be lost or hard to share between containers.

The Solution

PersistentVolumeClaim (PVC) lets you ask Kubernetes for storage space that stays safe even if containers restart.

This means your app can save files reliably without worrying about losing them.

Before vs After

✗ Before

docker run myapp
# Data lost when container stops

✓ After

kubectl apply -f pvc.yaml
# Storage stays even if pod restarts

What It Enables

With PVCs, your apps can keep important data safe and share it easily across containers.

Real Life Example

A photo-sharing app stores user pictures on a persistent volume so photos don't disappear when the app updates or restarts.

Key Takeaways

Storing data inside containers is temporary and risky.

PersistentVolumeClaim requests stable storage from Kubernetes.

PVCs keep data safe across container restarts and enable sharing.

Practice

1. What is the main purpose of a PersistentVolumeClaim (PVC) in Kubernetes?

easy

A. To configure network policies

B. To define a container image for a pod

C. To schedule pods on specific nodes

D. To request storage resources from the cluster

Solution

1. Step 1: Understand PVC role

   A PVC is used to request storage resources in Kubernetes, separating storage use from storage details.

2. Step 2: Compare options

   Options A, B, and D relate to other Kubernetes features, not storage requests.

3. Final Answer:

   To request storage resources from the cluster -> Option D

4. Quick Check:

   PVC = Storage request [OK]

Hint: PVC always requests storage, not images or network [OK]

Common Mistakes:

• Confusing PVC with Pod or Deployment definitions
• Thinking PVC schedules pods
• Mixing PVC with network policies

2. Which of the following is the correct minimal YAML snippet to define a PVC requesting 5Gi of storage with ReadWriteOnce access mode?

easy

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

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

C. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteMany
resources:
limits:
storage: 5Gi

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

Solution

1. Step 1: Check accessModes and storage request

   apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi correctly uses ReadWriteOnce and requests 5Gi storage under resources.requests.

2. Step 2: Identify errors in other options

   apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadOnlyMany resources: requests: storage: 5Gi uses ReadOnlyMany (not requested). apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteMany resources: limits: storage: 5Gi uses limits instead of requests. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: cpu: 5Gi incorrectly requests cpu instead of storage.

3. Final Answer:

   Correct minimal PVC YAML with 5Gi and ReadWriteOnce -> Option B

4. Quick Check:

   accessModes + storage request = apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi [OK]

Hint: Use resources.requests.storage for size, accessModes for access [OK]

Common Mistakes:

• Using limits instead of requests for storage
• Wrong accessModes value
• Requesting cpu instead of storage

3. Given this PVC YAML snippet, what will be the requested storage size and access mode?

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-storage

medium

A. 10Gi storage with ReadWriteMany access

B. 10Gi storage with ReadWriteOnce access

C. 5Gi storage with ReadWriteMany access

D. 10Gi storage with ReadOnlyMany access

Solution

1. Step 1: Read storage size

   The YAML requests 10Gi storage under resources.requests.storage.

2. Step 2: Read access mode

   Access mode is ReadWriteMany as specified under accessModes.

3. Final Answer:

   10Gi storage with ReadWriteMany access -> Option A

4. Quick Check:

   storage=10Gi, access=ReadWriteMany [OK]

Hint: Check resources.requests.storage and accessModes list [OK]

Common Mistakes:

• Confusing ReadWriteOnce with ReadWriteMany
• Misreading storage size
• Ignoring storageClassName as it doesn't affect size or access

4. Identify the error in this PVC YAML snippet:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2GB

medium

A. metadata name is missing

B. accessModes should be ReadOnlyMany

C. storage size unit should be Gi, not GB

D. apiVersion should be apps/v1

Solution

1. Step 1: Check storage size unit

   Kubernetes expects storage size units like Gi, Mi, not GB. '2GB' is invalid.

2. Step 2: Verify other fields

   accessModes and metadata name are correct. apiVersion for PVC is v1, not apps/v1.

3. Final Answer:

   storage size unit should be Gi, not GB -> Option C

4. Quick Check:

   Use Gi for storage size units [OK]

Hint: Use Gi, Mi units for storage size, not GB [OK]

Common Mistakes:

• Using GB instead of Gi for storage size
• Wrong apiVersion for PVC
• Changing accessModes unnecessarily

5. You want to create a PVC that requests 20Gi storage with ReadWriteOnce access and uses a storage class named "premium-ssd". Which YAML snippet correctly defines this PVC?

hard

A. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: premium-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
storageClassName: premium-ssd

B. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: premium-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi
storageClassName: premium-ssd

C. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: premium-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
limits:
storage: 20Gi
storageClassName: premium-ssd

D. apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: premium-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20GB
storageClassName: premium-ssd

Solution

1. Step 1: Verify accessModes and storage size

   apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: premium-ssd uses ReadWriteOnce and requests 20Gi storage correctly.

2. Step 2: Check storageClassName and units

   apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: premium-ssd correctly sets storageClassName to premium-ssd and uses Gi units. Other options have wrong accessModes, use limits instead of requests, or wrong units (GB).

3. Final Answer:

   Correct PVC with 20Gi, ReadWriteOnce, and premium-ssd storage class -> Option A

4. Quick Check:

   accessModes=ReadWriteOnce + requests.storage=20Gi + storageClassName= premium-ssd [OK]

Hint: Use requests.storage with Gi units and correct accessModes [OK]

Common Mistakes:

• Using limits instead of requests for storage
• Wrong accessModes value
• Using GB instead of Gi for storage size