Why configuration separation matters in Kubernetes - Why It Works

Introduction

When you run applications, mixing code and settings can cause confusion and mistakes. Separating configuration from code helps you change settings without touching the app itself, making updates safer and easier.

When you want to change app settings like database addresses without rebuilding the app

When you deploy the same app to different environments like testing and production with different settings

When multiple team members manage app settings separately from developers

When you want to keep sensitive data like passwords out of your app code

When you need to update configuration quickly without restarting or changing the app code

Config File - configmap.yaml

configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-config
  namespace: default
data:
  APP_MODE: production
  LOG_LEVEL: info
  MAX_CONNECTIONS: "100"

This ConfigMap stores app settings separately from the app code.

apiVersion and kind define this as a ConfigMap resource.

metadata names the ConfigMap and sets its namespace.

data holds key-value pairs for configuration like mode, log level, and max connections.

Commands

This command creates or updates the ConfigMap in Kubernetes, making the configuration available to pods.

Terminal

kubectl apply -f configmap.yaml

Expected Output

configmap/example-config created

This command retrieves the ConfigMap details to verify it was created correctly.

Terminal

kubectl get configmap example-config -o yaml

Expected Output

apiVersion: v1

kind: ConfigMap

metadata:

  name: example-config

  namespace: default

data:

  APP_MODE: production

  LOG_LEVEL: info

  MAX_CONNECTIONS: "100"

→

-o yaml - Outputs the ConfigMap in YAML format for easy reading

This command creates a pod that uses the ConfigMap values as environment variables, showing how configuration is separated from the app image.

Terminal

kubectl run example-pod --image=nginx --env-from=configmap/example-config --restart=Never

Expected Output

pod/example-pod created

→

--env-from=configmap/example-config - Loads all ConfigMap entries as environment variables in the pod

→

--restart=Never - Creates a single pod instead of a deployment

This command checks the environment variables inside the pod to confirm the ConfigMap values are applied.

Terminal

kubectl exec example-pod -- printenv APP_MODE LOG_LEVEL MAX_CONNECTIONS

Expected Output

production

info

100

Key Concept

If you remember nothing else from this pattern, remember: separating configuration from code lets you change settings safely without rebuilding or redeploying your app.

Common Mistakes

Putting configuration values directly inside the app container image

This makes changing settings slow and error-prone because you must rebuild and redeploy the image for every change.

Use ConfigMaps or environment variables to keep configuration separate from the app code.

Not updating pods after changing ConfigMaps

Pods do not automatically reload ConfigMap changes, so they keep using old settings until restarted.

Restart pods or use rollout strategies to apply new configuration changes.

Storing sensitive data like passwords in ConfigMaps

ConfigMaps are not encrypted and can be viewed by anyone with access to the cluster.

Use Kubernetes Secrets for sensitive information instead of ConfigMaps.

Summary

Create a ConfigMap file to hold app settings separately from code.

Apply the ConfigMap to Kubernetes with kubectl apply.

Use pods that load configuration from the ConfigMap as environment variables.

Verify configuration inside pods to ensure separation works.

Remember to restart pods to apply ConfigMap changes.