Why configuration separation matters in Kubernetes - See It in Action

Why Configuration Separation Matters in Kubernetes

📖 Scenario: You are managing a simple web application deployed on Kubernetes. You want to keep your application code separate from its configuration settings, such as environment variables and resource limits. This helps you update configuration without changing the application container image.

🎯 Goal: Learn how to separate configuration from application code by creating a Kubernetes Deployment and a ConfigMap, then link them together. Finally, display the configuration inside the running container.

📋 What You'll Learn

Create a ConfigMap with specific configuration data

Create a Deployment that uses the ConfigMap as environment variables

Verify the configuration is accessible inside the container

💡 Why This Matters

🌍 Real World

Separating configuration from code is a best practice in Kubernetes to manage settings independently and securely.

💼 Career

DevOps engineers and SREs often create and manage ConfigMaps and Secrets to configure applications in production environments.

1

Create a ConfigMap with app configuration

Create a Kubernetes ConfigMap named app-config with these exact key-value pairs: APP_MODE=production and LOG_LEVEL=info.

Kubernetes

# Your code here to create the ConfigMap named app-config with APP_MODE and LOG_LEVEL keys

Hint

Use kind: ConfigMap and put your key-value pairs under data:.

2

Create a Deployment using the ConfigMap

Create a Kubernetes Deployment named web-app with one replica. Use the image busybox and set environment variables APP_MODE and LOG_LEVEL from the ConfigMap app-config.

Kubernetes

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: "production"
  LOG_LEVEL: "info"

# Your code here to create Deployment named web-app using busybox image and env from app-config

Hint

Use envFrom: with configMapRef: to load all keys as environment variables.

3

Add a command to print environment variables

Modify the Deployment's container command to print the environment variables APP_MODE and LOG_LEVEL using sh -c and then sleep. Use the command: sh -c "echo APP_MODE=$APP_MODE LOG_LEVEL=$LOG_LEVEL && sleep 3600".

Kubernetes

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: "production"
  LOG_LEVEL: "info"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: busybox-container
        image: busybox
        # Your code here to change command to print env vars and sleep
        envFrom:
        - configMapRef:
            name: app-config

Hint

Use command: ["sh", "-c", "..."] to run multiple shell commands.

4

Display the configuration output

Run kubectl apply -f on your YAML file and then run kubectl logs on the pod created by the web-app Deployment to display the output showing APP_MODE=production and LOG_LEVEL=info.

Kubernetes

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: "production"
  LOG_LEVEL: "info"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: busybox-container
        image: busybox
        command: ["sh", "-c", "echo APP_MODE=$APP_MODE LOG_LEVEL=$LOG_LEVEL && sleep 3600"]
        envFrom:
        - configMapRef:
            name: app-config

# Your code here to print the output from the pod logs

Hint

Use kubectl logs on the pod to see the printed environment variables.

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