Skip to content

volume vs volumeClaim

1. The "What & Where" (Volume vs. VolumeMount)

To get data into a container, you have to define it twice in your YAML:

The Volume (spec.volumes)

  • Purpose: Tells Kubernetes, "Hey, I need to bring some data into this Pod."

  • Scope: The entire Pod. All containers in this Pod can see this volume.

  • Analogy: This is the Source. Like a specific book on a shelf.

The VolumeMount (spec.containers.volumeMounts)

  • Purpose: Tells a specific container, "Take that volume I just defined and stick it at this specific folder path."

  • Scope: The Container. You decide exactly where the data appears inside the container's file system.

  • Analogy: This is the Destination. Like deciding which desk in the room the book should be placed on.

2. Why do we need both?

The main reason is flexibility. By separating them:

  1. Multiple containers in one Pod can mount the same Volume at different paths.

  2. You can mount a Volume as read-only in one container but read-write in another.

  3. The container doesn't need to know where the data comes from (Cloud, ConfigMap, or Local Disk); it just knows it has a folder at /app/config.

3. Concrete Example (ConfigMap)

Let’s say you have a ConfigMap called app-settings. You want your app to read it from /etc/config.

YAML

kind: Pod
metadata:
  name: my-pod
spec:
  # 1. DEFINE THE VOLUME (The Source)
  volumes:
    - name: config-volume      # Give it a name to reference later
      configMap:
        name: app-settings     # Use this specific ConfigMap

  containers:
    - name: my-container
      image: nginx
      # 2. MOUNT THE VOLUME (The Destination)
      volumeMounts:
        - name: config-volume  # Must match the name above
          mountPath: /etc/config
          readOnly: true

4. Common "Local" Use Cases

Since we aren't talking about external disks (PVs), here are the most common ways people use volumes:

  • emptyDir: A blank folder that is created when the Pod starts and deleted when it dies. Great for scratch space or passing data between a "helper" container and your "main" app.

  • configMap / secret: Turning your K8s configuration objects into actual files inside the container so your app can read them like a standard .yaml or .json file.

  • hostPath: (Use with caution!) Directly mounting a folder from the Node's physical hard drive into the container. Usually used for system-level tools (like log collectors).