Introduction

In Kubernetes, environment variables defined in the container spec are part of the Pod template. You cannot change them inside a running container and expect Kubernetes to treat that as configuration state. To override them, you update the higher-level workload definition, such as a Deployment, or use a more maintainable source like a ConfigMap or Secret.

How Environment Values Are Set

A container can receive environment variables from several places:

• 'ENV instructions baked into the image'
• explicit env entries in the Pod or container spec
• 'envFrom references to a ConfigMap or Secret'

Values in the Kubernetes container spec override environment values baked into the image.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: demo
5spec:
6  containers:
7    - name: app
8      image: myapp:latest
9      env:
10        - name: LOG_LEVEL
11          value: "debug"

If the image already contains LOG_LEVEL=info, the Pod spec value wins.

Overriding The Value In A Deployment

If the variable is already defined in a Deployment, override it by editing the Pod template and applying the change.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: demo
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: demo
10  template:
11    metadata:
12      labels:
13        app: demo
14    spec:
15      containers:
16        - name: app
17          image: myapp:latest
18          env:
19            - name: LOG_LEVEL
20              value: "info"

Change info to the new value and run kubectl apply -f deployment.yaml. Kubernetes creates new Pods from the updated template.

For a quick command-line override, kubectl set env is convenient.

kubectl set env deployment/demo LOG_LEVEL=debug

That updates the deployment template and triggers a rollout.

Using ConfigMap Or Secret For Cleaner Overrides

Hard-coding environment values in the container spec is workable for small cases, but environment-specific configuration is easier to manage through ConfigMap or Secret references.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: demo-config
5data:
6  LOG_LEVEL: "warn"

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: demo
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: demo
10  template:
11    metadata:
12      labels:
13        app: demo
14    spec:
15      containers:
16        - name: app
17          image: myapp:latest
18          envFrom:
19            - configMapRef:
20                name: demo-config

Now the override lives in the ConfigMap, not in a copied container spec block.

What You Cannot Do

You cannot mutate environment variables for a running container in place and expect the process to see a managed Kubernetes configuration update. Environment variables are fixed at container start.

If the variable changes, the Pod must be recreated or rolled out again so the process starts with the new environment.

That is why Kubernetes configuration changes are usually expressed declaratively at the workload level.

Common Pitfalls

A common mistake is editing the environment inside the container shell and expecting the change to persist or affect future Pods. It will not.

Another mistake is changing a generated Pod directly instead of changing the owning Deployment or StatefulSet. The controller will recreate Pods from its template, not from your one-off Pod edits.

Developers also often repeat the same env block across environments when a ConfigMap, Secret, or Helm values file would make the override cleaner.

Finally, remember the precedence rules. A value in the container spec overrides the image's ENV, but conflicting keys across env and envFrom should be designed carefully so the intended source is obvious.

Summary

• Environment variables in a Kubernetes container spec are fixed when the container starts.
• Override them by changing the owning workload definition, not by editing a running container.
• 'kubectl set env is a quick way to update a deployment template.'
• 'ConfigMap and Secret references are cleaner for environment-specific overrides.'
• Container-spec env values override image-level ENV defaults.
• Recreate or roll out Pods after changing environment configuration.