Introduction

On GKE, you do not usually “copy files into a persistent volume” as a standalone infrastructure step. Instead, you mount a PersistentVolumeClaim into a pod and then write files through that mounted path from a container, an init container, or a maintenance job. The persistent storage lives behind the claim, but file placement still happens from inside Kubernetes workloads.

Start with a PersistentVolumeClaim

The normal first step is to request storage with a PVC.

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

On GKE, a default storage class often provisions the backing disk automatically. The important point is that your application or job talks to the claim, not directly to a raw disk resource.

Mount the Claim into a Pod

Once the claim exists, mount it into a pod or deployment.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: file-writer
5spec:
6  containers:
7    - name: writer
8      image: busybox
9      command: ["sh", "-c", "echo hello > /data/example.txt && sleep 3600"]
10      volumeMounts:
11        - name: storage
12          mountPath: /data
13  volumes:
14    - name: storage
15      persistentVolumeClaim:
16        claimName: app-data

This is one of the cleanest ways to put a file onto the persistent volume: start a pod that mounts the claim and writes the file to the mounted directory.

Use an Init Container for Seed Data

If you want files to appear before the main app starts, an init container is often the best pattern.

1initContainers:
2  - name: seed-data
3    image: busybox
4    command: ["sh", "-c", "cp /seed/* /data/"]
5    volumeMounts:
6      - name: storage
7        mountPath: /data
8      - name: seed-volume
9        mountPath: /seed

That way the main application starts with the expected files already present on the persistent volume.

Copy Files into a Running Pod

For one-off manual tasks, kubectl cp can work if the target pod already mounts the PVC.

kubectl cp ./local-file.txt default/file-writer:/data/local-file.txt

This does not copy directly into the volume abstraction. It copies into the pod’s mounted filesystem path, which persists because that path is backed by the PVC.

Prefer Jobs for Repeatable File Loading

If the file placement is part of a deployment workflow, use a Kubernetes Job or init container instead of relying on manual kubectl cp steps. Manual copying is fine for debugging, but repeatable automation is better for production.

Understand Access Mode Limits

If the claim is backed by a disk that supports only ReadWriteOnce, only one node may be able to mount it read-write at a time. That matters if you try to write files from one pod while another workload is using the same volume in a different scheduling context.

On GKE, the underlying storage class and access mode determine what kind of file-placement workflow is practical.

Common Pitfalls

A common mistake is treating the persistent volume like a standalone filesystem you can manipulate outside the pod model. Another is copying files into a container path that is not actually backed by the PVC. Developers also often rely on manual kubectl cp for production initialization, which is fragile compared with init containers or Jobs. Finally, access-mode limitations can surprise you if you assume multiple writers can mount the same claim freely.

Summary

• On GKE, place files onto persistent storage by mounting a PVC into a pod and writing through the mounted path.
• Use init containers or Jobs for repeatable initialization.
• 'kubectl cp is acceptable for manual one-off tasks when the target path is truly on the mounted claim.'
• The PVC is the Kubernetes-facing interface; the pod filesystem path is where your code writes files.
• Always check the storage class and access mode before designing a multi-writer workflow.