Introduction

In normal production workflows, you do not put raw source code directly into Kubernetes. You build a container image from the source code, push that image to a registry, and then tell Kubernetes to run containers from that image.

Understand the Separation of Responsibilities

Kubernetes is an orchestration system. Its job is to run containers, restart them, scale them, and connect them to networking and storage. It is not a source code hosting system and it is not usually the place where your application is built.

A standard workflow looks like this:

1. write source code in your repository
2. build an image from that source code
3. push the image to a registry
4. deploy the image with Kubernetes manifests

That separation is important because source code changes do not become runtime changes until a new image is built and deployed.

Build an Image From Your Source

The image packages your application code together with the runtime it needs. For a simple Python app, the Dockerfile might look like this:

1FROM python:3.12-slim
2
3WORKDIR /app
4COPY requirements.txt .
5RUN pip install --no-cache-dir -r requirements.txt
6
7COPY . .
8CMD ["python", "app.py"]

Then build and tag the image:

docker build -t registry.example.com/myapp:1.0.0 .

At this stage, your source code has been turned into a deployable artifact. That is what Kubernetes needs.

Push the Image to a Registry

Your cluster needs a place to pull the image from. Push the image to a registry your cluster can access:

docker push registry.example.com/myapp:1.0.0

The registry might be Docker Hub, Amazon ECR, Google Artifact Registry, GitHub Container Registry, or a private internal registry.

Using an immutable version tag such as 1.0.0 is usually better than relying on latest, because it makes deployments easier to reason about and roll back.

Deploy the Image With Kubernetes

Once the image is published, reference it in a Deployment:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: myapp
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: myapp
10  template:
11    metadata:
12      labels:
13        app: myapp
14    spec:
15      containers:
16        - name: myapp
17          image: registry.example.com/myapp:1.0.0
18          ports:
19            - containerPort: 8000

Apply it with:

kubectl apply -f deployment.yaml

That is the normal answer to the question. Kubernetes runs images, not repositories.

What About Config or Scripts

There are special cases where small text files, startup scripts, or templates are injected with ConfigMaps or Secrets. That can be useful for configuration, but it is not the same thing as shipping the whole application source tree into the cluster.

For example, a shell script may come from a ConfigMap, but the main application still usually comes from the container image.

There are also development workflows that mount source code into a running container for rapid iteration. Those are useful for local dev, but they are not the normal production model for Kubernetes.

CI and CD Make This Repeatable

In a real team setup, a CI pipeline usually automates the process:

1. commit source code
2. run tests
3. build an image
4. push the image
5. update the Kubernetes deployment

This pipeline keeps your cluster aligned with a versioned build artifact instead of whatever happens to be in a working directory.

Common Pitfalls

The biggest mistake is trying to treat Kubernetes like a remote server where you copy code and run it directly. That bypasses the container build process and fights the platform instead of using it correctly.

Another common issue is deploying images with the latest tag and then losing track of what code is actually running. Versioned tags make debugging and rollback much easier.

Some teams also put too much mutable state into the container startup path, such as cloning a Git repository on pod startup. That can work for special cases, but it adds network dependencies and makes deployments less deterministic.

Finally, do not confuse configuration with code. ConfigMaps and Secrets are good for runtime settings, not for replacing your normal build and image workflow.

Summary

• In normal Kubernetes workflows, you deploy container images, not raw source code.
• Build the image from your repository and push it to a registry first.
• Reference that image in a Deployment or other Kubernetes workload.
• Use ConfigMaps and Secrets for configuration, not as a substitute for packaging the app.
• Prefer versioned image tags so you know exactly what code the cluster is running.