Introduction

Persistent storage in Kubernetes is not attached directly to a ReplicationController as a special storage concept. Instead, the pod template inside the controller mounts a volume, and the usual modern way to do that is through a PersistentVolumeClaim. On Google Cloud, that claim is typically backed by a GCE Persistent Disk, Filestore, or a storage class that provisions the volume dynamically.

The Modern Storage Pattern

Even though the question mentions a ReplicationController, the storage model is the same as for other workload controllers:

• define or dynamically provision persistent storage
• create a PersistentVolumeClaim
• mount the claim in the pod template

That is the important conceptual answer.

Also note that ReplicationControllers are an older workload primitive. In current Kubernetes, a Deployment or StatefulSet is usually the better choice. But the PVC mounting principle is the same.

Define a PersistentVolumeClaim

In many clusters, dynamic provisioning via a storage class is the normal approach.

1apiVersion: v1
2kind: PersistentVolumeClaim
3metadata:
4  name: app-data
5spec:
6  accessModes:
7    - ReadWriteOnce
8  resources:
9    requests:
10      storage: 10Gi

If your Google Cloud environment is configured for dynamic provisioning, Kubernetes binds this claim to a suitable persistent disk automatically.

Mount the Claim in the Pod Template

Inside the ReplicationController's pod template, reference the claim as a volume and mount it into the container.

1apiVersion: v1
2kind: ReplicationController
3metadata:
4  name: my-app
5spec:
6  replicas: 1
7  selector:
8    app: my-app
9  template:
10    metadata:
11      labels:
12        app: my-app
13    spec:
14      containers:
15        - name: my-app
16          image: nginx:1.27
17          volumeMounts:
18            - name: data
19              mountPath: /data
20      volumes:
21        - name: data
22          persistentVolumeClaim:
23            claimName: app-data

That is the actual answer to "how do I specify a persistent volume with this controller."

Google Cloud Backing Storage

On Google Cloud, the backing storage is often a persistent disk exposed through Kubernetes storage abstractions. In older setups you might define the PersistentVolume manually with a GCE disk reference. In more typical modern clusters, a storage class handles provisioning for you when the PVC is created.

The key operational benefit is that your pod can be recreated without losing data, as long as the claim remains bound to persistent storage.

Know the Access Mode Constraints

A common design mistake is combining multi-replica controllers with storage that only supports single-writer mounting semantics.

For example, ReadWriteOnce is common for block storage and usually means one node can mount the volume read-write at a time. That can be fine for a single replica, but it becomes a design constraint for scaled workloads.

If the application needs stable per-replica storage identity, a StatefulSet is usually a better fit than a ReplicationController.

Why PVCs Are Better Than Container-Only Paths

Writing to /data inside a container without a mounted persistent volume only writes into the container's writable layer. That data is not durable in the way most applications expect.

The PVC approach makes the storage lifecycle more explicit and separate from the pod lifecycle.

That is the main reason Kubernetes storage is modeled through claims and volumes instead of just filesystem paths.

Common Pitfalls

The most common mistake is trying to express persistence only with a container path such as /data and forgetting to mount any persistent volume at that path.

Another issue is using an old controller type for a workload that really wants stable identity and storage, where StatefulSet would be more appropriate.

Developers also often ignore access mode constraints. A single writable disk is not automatically compatible with many replicas.

Finally, do not hardcode Google Cloud specifics into the application container. Keep storage concerns in Kubernetes volume and claim definitions.

Summary

• Mount persistence through a PersistentVolumeClaim in the pod template.
• The controller itself does not have a special storage mechanism beyond the pod's volume definition.
• On Google Cloud, the PVC is usually backed by persistent cloud storage through Kubernetes storage abstractions.
• Watch access mode limitations when using block-style storage.
• Prefer newer workload types such as Deployment or StatefulSet unless you specifically need a ReplicationController.