All diagrams
Storage: Volumes & Claimsk8s 1.36

Access Modes

ReadWriteOnce sounds like one Pod, so why can two Pods share the same volume? Because the mode is per Node, not per Pod: once a block disk is attached to a Node, any Pod there can mount it, while the attach and detach controller refuses a Pod elsewhere with Waiting for detach, formerly Multi-Attach error. ReadWriteOncePod narrows it to one Pod, and ReadWriteMany needs a backend like NFS. ReadOnlyMany is matched at binding and does not make the mount read-only.

Play the animation 7 steps, animated, best on a wide screen

Access Modes diagram: Access modes decide who can mount a volume at once

Access Modes, step by step

  1. Pod app-1 mounts the volume. The disk is attached to one Node, Node-1, and ReadWriteOnce lets a Pod there read and write it. So far this looks exactly like a per-Pod lock, but that is not what ReadWriteOnce actually means.

    Play from step 1

  2. Pod app-2 sits on the same Node and it can mount the volume too. ReadWriteOnce is per Node, not per Pod. Once the disk is attached to Node-1, any number of Pods scheduled onto Node-1 can share it.

    Play from step 2

  3. Pod app-3 lives on Node-2 and asks for the same volume. This one is refused. The volume is ReadWriteOnce and already attached to Node-1, so the attach and detach controller will not attach it to Node-2 as well. Pod app-3 gets a Waiting for detach warning and cannot start while Node-1 holds the disk.

    Play from step 3

  4. ReadWriteOncePod is the only mode that limits access to one Pod, so now even app-2 on Node-1 is refused. Kubernetes enforces it itself: the Scheduler will not place a second Pod that uses the claim, though a higher-priority one can preempt the holder, and Kubelet refuses the mount to a Pod that lands on the Node anyway.

    Play from step 4

  5. ReadWriteMany asks for the volume on many Nodes at once, and this block disk cannot attach to more than one Node, so nobody gets it. Kubernetes accepts the mode on the claim but binds it only to a volume that offers ReadWriteMany, and the driver of this disk refuses to create one.

    Play from step 5

  6. Point the claim at a shared filesystem instead, PV nfs on NFS or CephFS, and ReadWriteMany works: Kubernetes lets it be used on both Nodes at once, and all three Pods mount it together, with nobody refused. The mode was always allowed by Kubernetes, what changed is a backend that can deliver it.

    Play from step 6

  7. ReadOnlyMany lets PV nfs be used on both Nodes too, but it does not make the mount read-only. Kubernetes uses the mode to match the claim to a volume at binding, and app-1 and app-3 still mount it read/write. A read-only mount comes from readOnly: true, on the claim in the Pod volumes or on a volumeMount.

    Play from step 7

Sources

Commands for this