Multi-Container Pod with RWX Storage

Core Concepts

Shared mounted path

Two containers can mount the same claim and see the same files from inside the Pod.

ReadWriteMany intent

RWX asks for a backend that supports concurrent read and write access instead of exclusive node ownership.

Tightly coupled design

This pattern works best when one container produces files and another container reads, serves, or transforms them.

Shared PVC Pod Flow

1

Provision RWX-capable storage

Create or choose a backend that supports shared writable access.

2

Bind with a PVC

The claim requests RWX so the Pod can mount it with shared intent.

3

Mount into multiple containers

Each container mounts the same claim as a shared volume path.

4

Exchange data through files

One container writes content and the other consumes it without extra networking.

Key point: Use this pattern when the containers are operationally one unit and should stay together in the same Pod.

Representative YAML

PV and PVC

apiVersion: v1
kind: PersistentVolume
metadata:
  name: multi-container-pv
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /mnt/nfs_share
    server: 192.168.1.100
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: multi-container-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

Multi-Container Pod

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: app-container-1
    image: nginx
    volumeMounts:
    - name: shared-storage
      mountPath: /usr/share/nginx/html
  - name: app-container-2
    image: busybox
    command: ["sh", "-c", "while true; do echo Logging data > /usr/share/nginx/html/log.txt; sleep 5; done"]
    volumeMounts:
    - name: shared-storage
      mountPath: /usr/share/nginx/html
  volumes:
  - name: shared-storage
    persistentVolumeClaim:
      claimName: multi-container-pvc

Shared Volume Patterns

Pattern	Lifecycle	Best Fit
emptyDir in one Pod	Ephemeral for the Pod lifecycle	Temporary sharing and scratch data
PVC in one Pod	Persistent beyond container restarts	Shared state or logs that must survive
PVC across many Pods	Persistent and potentially multi-node	Shared data across replicas or workers

Design hint: Start with emptyDir for temporary collaboration and move to a PVC only when the data itself needs durability.

How To Use It In Practice

Producer and consumer sidecars

One container writes files while another container serves, ships, or transforms them.

Persistent shared state

Keep content available even if one of the collaborating containers restarts.

Backend validation

Use the pattern to prove whether the chosen backend truly behaves like shared writable storage.