如何无需创建新镜像，修改容器及Kubernetes Pod中的应用源码？

Great question! This is a super common need during development or debugging, so let's break down practical solutions for both standalone containers and Kubernetes Pods.

针对普通Docker容器的方案 #

1. 直接进入容器临时修改 #

If you just need to tweak code quickly for debugging, you can jump straight into the running container:

docker exec -it <container-id-or-name> /bin/bash

Once inside, use whatever editor is available (like vi, nano, or install one with apt update && apt install vim if the base image allows). Just remember: all changes will be lost when the container restarts—this is only for short-term testing.

2. 绑定挂载本地源码目录 #

For active development, mount your local code directory into the container so changes on your machine sync instantly to the container:

docker run -v /path/to/your/local/code:/path/to/code/in/container -p 8080:8080 your-image

This way, you can edit code locally with your favorite IDE, and the container will pick up changes immediately (you might need to restart the app inside the container if it doesn't auto-reload, like with kill -HUP <process-id>).

针对Kubernetes Pod的方案 #

Kubernetes adds some extra layers, but there are still ways to skip rebuilding/pushing images during development:

1. 直接进入Pod修改（临时调试） #

Similar to Docker, you can exec into a running Pod to tweak code:

kubectl exec -it <pod-name> -c <container-name> -- /bin/bash

Again, changes vanish when the Pod restarts, so this is best for quick debugging fixes. If the container doesn't have an editor, you can copy a binary into it with kubectl cp:

kubectl cp /usr/bin/vim <pod-name>:/usr/bin/vim -c <container-name>

2. 用ConfigMap挂载单个/少量源码文件 #

If you're only changing one or two files, store the code in a ConfigMap and mount it into the Pod over the original file.

First, create the ConfigMap from your local file:

kubectl create configmap app-source --from-file=app.py=/path/to/your/local/app.py

Then update your Pod spec to mount this ConfigMap:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app-container
    image: your-app-image
    volumeMounts:
    - name: source-volume
      mountPath: /app/app.py  # Overwrites the original file in the container
  volumes:
  - name: source-volume
    configMap:
      name: app-source

When you need to update the code, edit the ConfigMap:

kubectl edit configmap app-source

The change will sync to the Pod within a minute—you just need to restart the app process inside the Pod (e.g., kubectl exec <pod-name> -- pkill python for a Python app) to pick up the new code.

3. 用PersistentVolumeClaim（PVC）挂载整个源码目录 #

For larger codebases, use a PVC to mount a persistent volume into the Pod's code directory.

First, create a PVC (you'll need a StorageClass set up in your cluster):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: source-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Then update your Pod spec to mount the PVC:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app-container
    image: your-app-image
    volumeMounts:
    - name: source-volume
      mountPath: /app  # Overwrites the entire app directory in the container
  volumes:
  - name: source-volume
    persistentVolumeClaim:
      claimName: source-pvc

Now you can copy your local code into the PVC:

kubectl cp /path/to/your/local/code <pod-name>:/app -c <container-name>

Changes will persist even if the Pod restarts, and you can re-copy updated code whenever needed.

4. 使用临时容器（Ephemeral Containers） #

If the main container is locked down (no shell, no editor), you can attach a temporary container that shares the main container's filesystem:

kubectl debug -it <pod-name> --image=busybox:latest --target=<container-name>

This gives you a shell where you can modify files in the main container's filesystem—perfect for debugging when you can't access the main container directly.

Important Notes #

All these methods are for development/debugging only. In production, you should always use version-controlled images—modifying running containers/Pods breaks reproducibility and makes it impossible to track changes. If you need a permanent fix, building a new image is still the right approach.

内容的提问来源于stack exchange，提问作者Arun