Introduction

You can copy files directly into a running Kubernetes container, but it is usually a debugging or emergency workflow, not a durable deployment strategy. On Google Cloud environments running Kubernetes, the same rule applies as anywhere else: direct file injection is ephemeral unless the file comes from a mounted volume, ConfigMap, Secret, or rebuilt image.

The Fast Ad Hoc Method: kubectl cp

For one-off debugging, the simplest method is kubectl cp.

kubectl cp ./myfile.txt my-pod:/app/myfile.txt

If the pod has multiple containers, specify the container name:

kubectl cp ./myfile.txt my-pod:/app/myfile.txt -c my-container

This is useful when you need to inspect behavior quickly without rebuilding the image, but the copied file is not part of the pod spec. If the pod is rescheduled or recreated, the change disappears.

Use kubectl exec for Small Inline Changes

If the file is tiny, you can also write it through a shell session.

kubectl exec -i my-pod -- sh -c 'cat > /tmp/config.txt' < ./config.txt

This is still an ad hoc runtime modification. It can help in troubleshooting, but it should not become the normal way code or configuration reaches production containers.

ConfigMaps and Secrets for Managed Injection

If the data is configuration rather than application code, use a ConfigMap or Secret and mount it into the container.

Example ConfigMap:

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: app-config
5---
6data:
7  settings.json: |
8    {"mode": "debug"}

Mounted into a pod:

1volumeMounts:
2  - name: config-volume
3    mountPath: /app/config
4volumes:
5  - name: config-volume
6    configMap:
7      name: app-config

This is much better than copying files manually because the configuration becomes part of the declared Kubernetes state.

Use a Secret instead of a ConfigMap when the file contains credentials or other sensitive values.

Persistent Volumes for Data Files

If the file needs to survive pod restarts, use a persistent volume rather than copying into the container filesystem.

A mounted volume is the right solution when the container should read or update files that outlive the pod itself.

This matters because the writable layer inside the container is not durable in the way many people expect. The pod may restart on another node and the injected file is simply gone.

Rebuild the Image for Real Code Changes

If the thing you are injecting is actual application code, the right long-term answer is almost always to rebuild the image and redeploy.

Directly copying code into a running container creates drift between:

• the image in the registry
• the container currently running
• the deployment specification

That drift makes incidents and rollbacks much harder to reason about. For production systems, immutable images are the safer discipline.

Init Containers and Sidecars Can Prepare Files

If the requirement is “files must appear in the main container before it starts,” an init container can place them into a shared volume.

That is a good fit when:

• files are generated at startup
• files are fetched from another source before the app starts
• the main container should remain simple and immutable

This is more maintainable than logging into a pod and copying files manually after the fact.

A Good Debugging Workflow on GKE or Similar Setups

If you are on Google Cloud Kubernetes and need a quick patch, a sensible workflow is:

1. use kubectl cp or kubectl exec only for short-lived debugging
2. confirm the change fixes the problem
3. move the fix into the image, ConfigMap, Secret, or volume definition
4. redeploy through the normal pipeline

That preserves the speed of ad hoc debugging without normalizing configuration drift.

Common Pitfalls

• Treating kubectl cp as a permanent deployment method.
• Injecting real application code into a live container and forgetting to rebuild the image.
• Storing secrets in copied plain files instead of using Kubernetes Secret resources.
• Assuming files copied into the container filesystem survive pod recreation.
• Using manual runtime file edits when a mounted ConfigMap, Secret, or volume would be the declared solution.

Summary

• 'kubectl cp and kubectl exec are useful for ad hoc file injection, especially during debugging.'
• Those changes are usually ephemeral and disappear when the pod is recreated.
• Use ConfigMaps and Secrets for managed configuration injection.
• Use persistent volumes for data that must survive pod restarts.
• For real code changes, rebuild the image and redeploy instead of patching the running container.