Configuring Containers in Pods

In the previous lessons, you created Pods using YAML manifests and learned the declarative workflow with Kubernetes. You applied manifests, verified Pods were running, and troubleshot common failures like image pull errors and crash loops. You worked with simple nginx Pods, but they used default configurations.

Real applications usually need more than just an image. They often need environment-specific settings (development, staging, production), database connection strings, API keys, feature flags, and clear documentation of which ports they listen on. Sometimes they also need a different startup command from the image's default.

Kubernetes gives you several ways to configure the containers inside your Pods without rebuilding images. In this lesson, you'll learn three core techniques: passing environment variables to containers, declaring container ports, and overriding the default startup command. You'll also use kubectl exec to verify that your configuration actually took effect.

Environment variables are a standard way to configure applications. They're simple key–value pairs available to processes at runtime. Applications read them to decide how to behave — for example, which database to connect to or which environment they're running in.

The major benefit is that you can use the same container image in multiple environments and change only the environment variables, not the code or image.

In Kubernetes, you configure environment variables in the Pod spec under the container's env field:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-configured
spec:
  containers:
    - name: nginx
      image: nginx:1.25
      env:
        - name: APP_ENV
          value: "dev"
      ports:
        - containerPort: 80
      command: ["nginx", "-g", "daemon off;"]

env is a list. Each entry has a name, which is the environment variable name inside the container (here, APP_ENV), and a value, which is the value as a string (here, "dev"). Kubernetes injects these variables into the container before it starts, and any process inside the container can read them.

In a real app you might define multiple variables like DATABASE_URL, API_KEY, LOG_LEVEL, or feature flags such as FEATURE_FLAG_NEW_UI. All environment variable values are strings; if your app needs a number or boolean, it parses the string itself.

Environment variables are set when the container starts and don't change while it's running. To change them, you need to restart the container (in practice: recreate the Pod, or update higher-level resources like Deployments, which you'll see later). By separating configuration from code, environment variables make your images reusable and your deployments more flexible.