What is a Pod Environment Variable

 An environment variable is just a key-value pair that you pass into a container at runtime, so the application inside can read it without you hardcoding values in code or image.

In Kubernetes, Pods support environment variables through the container spec:

env:

  - name: DB_USER

    value: admin

echo $DB_USER

# admin

2. Why use environment variables in Pods?

They help you:

1. Make apps configurable without rebuilding the image
   → You can change DB_HOST or API_KEY by updating YAML, no code change.

2. Separate secrets & configs from code
   → Avoid hardcoding credentials in the container image.

3. Control behavior for different environments (dev, staging, prod)
   → Same image, different environment variables.

4. Read runtime data from Kubernetes
   → Pull Pod metadata (name, namespace, IP, etc.) into your app automatically.

3. Ways to set Environment Variables in Pods

A. Hardcoded values

Good for small static values.

env:
  - name: MODE
    value: production

---

B. From a ConfigMap

Best for non-secret config that you might reuse across multiple Pods.

envFrom:
  - configMapRef:
      name: app-config

Example ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_HOST: mysql.svc.cluster.local
  DB_PORT: "3306"

---

C. From a Secret

Best for passwords, API tokens.

envFrom:
  - secretRef:
      name: db-secret

Example Secret:

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQ=   # base64 for 'password'

D. From Kubernetes Downward API
Pull Pod/Node metadata dynamically.
env:
  - name: POD_NAME
    valueFrom:
      fieldRef:
        fieldPath: metadata.name
  - name: POD_IP
    valueFrom:
      fieldRef:
        fieldPath: status.podIP

E. From another env variable
Useful for combining or referencing existing vars.
env:
  - name: BASE_URL
    value: "https://example.com"
  - name: FULL_API
    value: "$(BASE_URL)/api"

5. Best Practices
✅ Use ConfigMap for non-sensitive config

✅ Use Secrets for passwords/tokens (and enable encryption at rest)

✅ Avoid hardcoding in YAML unless it’s truly constant

✅ Use envFrom for bulk imports and env for overrides

✅ Inject Pod/Node metadata with Downward API for logging or debugging

✅ Keep sensitive data out of Git — use kubectl create secret instead of writing in YAML directly

✅ For big configs, consider mounting files instead of too many env vars

6. When Env Vars Shine in Real Projects


Multi-environment deployments (One image, many configs)


API keys & credentials management


Feature toggles (FEATURE_X_ENABLED=true)


Dynamic service discovery (using POD_IP, NODE_NAME)


Debugging (print env vars on startup to see what’s injected)


Injecting build/version info for monitoring



If you want, I can make you a Kubernetes lab example where:


We create a ConfigMap & Secret


Inject them into a Pod


Show how the app reads them dynamically


Prove that no image rebuild is required to change behavior


Do you want me to set up that full step-by-step lab next?