Injecting Environment Variables in Kubernetes Pods

Previously in this course, we explored creating your first Pod manifest and applying those manifests to the cluster. While those lessons focused on getting a static container running, real-world applications rarely exist in a vacuum; they need external configuration. This lesson adds the ability to pass dynamic runtime data into your containers without rebuilding your images.

Why Use Environment Variables for Config?

If you've followed Managing Environment Variables: A Docker Configuration Guide, you know that hardcoding settings like database URLs, API keys, or feature flags into your container image is a recipe for disaster. It forces you to build a new image for every environment (dev, staging, production).

By using Environment Variables in Kubernetes, you decouple your application logic from its configuration. This makes your Pods portable—the same container image can run in your local minikube cluster or a production cloud environment, simply by changing the configuration injected at Runtime via the Manifest.

Adding Variables to the Pod Manifest

In Kubernetes, you define environment variables within the containers spec of your Pod YAML. The env field is a list where each item consists of a name and a value.

Here is a concrete example of a Pod manifest configured with custom environment variables:

YAML
apiVersion: v1
kind: Pod
metadata:
  name: config-demo-pod
spec:
  containers:
  - name: demo-container
    image: nginx:latest
    env:
    - name: APP_ENVIRONMENT
      value: "production"
    - name: LOG_LEVEL
      value: "debug"

In this snippet, we are explicitly setting APP_ENVIRONMENT and LOG_LEVEL. When the Kubelet starts this container, it injects these key-value pairs directly into the container's process environment.

Verifying Injection Inside the Container

Once you have applied this manifest using kubectl apply -f pod.yaml, you need to confirm that the variables are actually available to your application. The most direct way to check is by executing a command inside the running container.

Run the following command to print the environment variables:

Bash
kubectl exec config-demo-pod -- printenv

You should see your custom variables (APP_ENVIRONMENT=production and LOG_LEVEL=debug) listed among the standard system variables. If you need to troubleshoot a specific variable, you can grep the output:

Bash
kubectl exec config-demo-pod -- printenv | grep APP_

Hands-on Exercise: Configure Your App

1. Take the Pod manifest you created in our previous lessons.
2. Modify the spec to include an env block.
3. Add at least two variables: DATABASE_URL and MAX_RETRIES.
4. Apply the updated manifest to your cluster.
5. Use kubectl exec to verify the variables are present inside the container.

Common Pitfalls

• Case Sensitivity: Environment variable names are case-sensitive. Ensure your application code looks for APP_PORT if you defined it as APP_PORT in your YAML.
• Static vs. Dynamic: Remember that environment variables are set when the container starts. If you change the YAML file and apply it to a running Pod, the changes will not take effect until the Pod is deleted and recreated.
• Secret Handling: While simple configuration works great in the env field, never put sensitive data (passwords, tokens) in plain text in your YAML files. We will cover how to handle sensitive data securely in a later lesson using Kubernetes Secrets.

FAQ

Can I use environment variables to override Dockerfile defaults? Yes. If your Dockerfile sets ENV PORT=80 and your Kubernetes manifest sets an environment variable with the same name, the value in the Kubernetes manifest will take precedence.

Do I need to restart the pod to see new environment variable values? Yes, environment variables are injected at the moment of container creation. Updating the manifest does not update the process environment of a currently running container.

Can I reference one environment variable within another? Yes, Kubernetes supports variable expansion using $(VAR_NAME) syntax. For example, you could define LOG_PATH: "/var/log/$(APP_NAME)/app.log".

Recap

We have successfully moved from static containers to configurable ones. By defining environment variables in your Manifest, you've gained the ability to alter Runtime behavior without modifying your code. This is a foundational skill for building production-ready systems that behave differently across development, staging, and production environments.

Up next: We’ll explore how to centralize these settings using ConfigMaps so you can manage configuration for multiple pods at once without duplicating your YAML code.