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.

Practice

1. Why is it important to separate configuration from application code in Kubernetes?

easy

A. It allows changing settings without modifying the application code.

B. It makes the application run faster.

C. It reduces the size of the application container.

D. It automatically fixes bugs in the application.

Solution

1. Step 1: Understand configuration separation

   Separating configuration means keeping settings outside the app code so they can be changed independently.

2. Step 2: Benefits in Kubernetes context

   This allows updates to settings without rebuilding or redeploying the app container.

3. Final Answer:

   It allows changing settings without modifying the application code. -> Option A

4. Quick Check:

   Configuration separation = Change settings without code change [OK]

Hint: Think: Can I change settings without touching app code? [OK]

Common Mistakes:

• Confusing configuration separation with performance improvements
• Thinking it reduces container size
• Assuming it fixes bugs automatically

2. Which Kubernetes resource is used to store non-sensitive configuration data separately from application code?

easy

A. ConfigMap

B. Deployment

C. Pod

D. Secret

Solution

1. Step 1: Identify resource types

   ConfigMap stores non-sensitive configuration data; Secret stores sensitive data.

2. Step 2: Match resource to question

   The question asks for non-sensitive data storage, which is ConfigMap.

3. Final Answer:

   ConfigMap -> Option A

4. Quick Check:

   Non-sensitive config = ConfigMap [OK]

Hint: ConfigMap = non-sensitive config, Secret = sensitive data [OK]

Common Mistakes:

• Choosing Secret for non-sensitive data
• Confusing Pod or Deployment as config storage
• Mixing up ConfigMap and Secret

3. Given this Kubernetes Pod spec snippet using a ConfigMap:

envFrom:
  - configMapRef:
      name: app-config

What happens if you update the ConfigMap 'app-config' while the Pod is running?

medium

A. The Pod crashes immediately.

B. The Pod automatically reloads the new configuration without restart.

C. The Pod continues using the old configuration until restarted.

D. The Pod deletes the ConfigMap.

Solution

1. Step 1: Understand envFrom with ConfigMap

   Using envFrom loads ConfigMap data as environment variables at Pod start.

2. Step 2: Effect of ConfigMap update on running Pod

   Environment variables do not update dynamically; Pod must restart to see changes.

3. Final Answer:

   The Pod continues using the old configuration until restarted. -> Option C

4. Quick Check:

   Env vars from ConfigMap update only after Pod restart [OK]

Hint: Env vars from ConfigMap update only after Pod restart [OK]

Common Mistakes:

• Assuming automatic reload without restart
• Thinking Pod crashes on ConfigMap change
• Believing ConfigMap is deleted by Pod

4. You created a Secret in Kubernetes but your Pod fails to access the secret data. Which is the most likely cause?

medium

A. Secrets cannot be used with Pods.

B. The Secret was not mounted or referenced correctly in the Pod spec.

C. The Secret data is stored in plain text and rejected.

D. The Pod must be restarted twice to access Secrets.

Solution

1. Step 1: Check how Secrets are used in Pods

   Secrets must be explicitly mounted as volumes or environment variables in Pod spec.

2. Step 2: Identify common error

   Failing to reference or mount the Secret correctly causes Pod to not see the data.

3. Final Answer:

   The Secret was not mounted or referenced correctly in the Pod spec. -> Option B

4. Quick Check:

   Secret access requires correct Pod spec reference [OK]

Hint: Always verify Secret is mounted or env referenced in Pod spec [OK]

Common Mistakes:

• Believing Secrets can't be used with Pods
• Thinking Secret data must be plain text
• Assuming multiple restarts fix Secret access

5. You want to deploy the same application to development and production environments with different database URLs. How does separating configuration help achieve this in Kubernetes?

hard

A. By embedding the URLs directly in the Pod spec containers' command lines.

B. By building separate container images for each environment with hardcoded URLs.

C. By manually editing the application code before each deployment.

D. By using different ConfigMaps or Secrets for each environment without changing the app code.

Solution

1. Step 1: Understand environment-specific configuration

   Different environments need different settings like database URLs.

2. Step 2: Use Kubernetes configuration separation

   Using ConfigMaps or Secrets per environment allows changing settings without code changes.

3. Step 3: Avoid rebuilding or editing code

   This approach avoids building multiple images or manual code edits.

4. Final Answer:

   By using different ConfigMaps or Secrets for each environment without changing the app code. -> Option D

5. Quick Check:

   Separate config per environment = different ConfigMaps/Secrets [OK]

Hint: Use separate ConfigMaps/Secrets per environment, no code change needed [OK]

Common Mistakes:

• Building separate images for each environment
• Hardcoding URLs in Pod commands
• Editing app code manually for each deploy