Feature flags in Kubernetes - Mini Project: Build & Apply

Feature Flags in Kubernetes

📖 Scenario: You are managing a Kubernetes deployment for a web application. You want to control a new feature rollout using feature flags. This means you can turn the feature on or off without changing the application code or redeploying.Feature flags will be stored as environment variables in the deployment manifest. You will create a ConfigMap to hold the feature flag, then update the deployment to use this flag.

🎯 Goal: Build a Kubernetes ConfigMap to store a feature flag, then update a Deployment to use this flag as an environment variable. Finally, check the pod environment to confirm the flag is set.

📋 What You'll Learn

Create a ConfigMap named feature-flags with a key NEW_FEATURE_ENABLED set to "false"

Update the Deployment named web-app to add an environment variable NEW_FEATURE_ENABLED from the ConfigMap

Verify the pod environment variable NEW_FEATURE_ENABLED is set correctly

💡 Why This Matters

🌍 Real World

Feature flags help teams release new features safely by enabling or disabling them dynamically in Kubernetes environments.

💼 Career

DevOps engineers often manage feature flags via ConfigMaps and environment variables to control application behavior without redeploying.

1

Create the ConfigMap for feature flags

Create a Kubernetes ConfigMap named feature-flags with a key NEW_FEATURE_ENABLED set to the string "false". Use the kubectl create configmap command with the literal flag.

Kubernetes

# Your command here to create the ConfigMap
# Example: kubectl create configmap feature-flags --from-literal=NEW_FEATURE_ENABLED=false

Hint

Use kubectl create configmap feature-flags --from-literal=NEW_FEATURE_ENABLED=false to create the ConfigMap.

2

Add environment variable from ConfigMap to Deployment

Edit the Deployment named web-app to add an environment variable NEW_FEATURE_ENABLED that gets its value from the ConfigMap feature-flags. Use kubectl patch deployment web-app with a JSON patch to add the environment variable under spec.template.spec.containers[0].env.

Kubernetes

kubectl create configmap feature-flags --from-literal=NEW_FEATURE_ENABLED=false
# Your command here to patch the deployment to add the env var

Hint

Use a JSON patch to add the environment variable from the ConfigMap to the first container in the deployment.

3

Check the pod environment variable

Get the name of one pod from the web-app deployment using kubectl get pods with a label selector. Then use kubectl exec to run printenv NEW_FEATURE_ENABLED inside the pod to check the environment variable value.

Kubernetes

kubectl create configmap feature-flags --from-literal=NEW_FEATURE_ENABLED=false
kubectl patch deployment web-app --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/env", "value": [{"name": "NEW_FEATURE_ENABLED", "valueFrom": {"configMapKeyRef": {"name": "feature-flags", "key": "NEW_FEATURE_ENABLED"}}}]}]'
# Your commands here to get a pod name and print the environment variable

Hint

Use kubectl get pods -l app=web-app -o jsonpath='{.items[0].metadata.name}' to get the pod name, then kubectl exec to run printenv NEW_FEATURE_ENABLED.

4

Display the feature flag value

Print the output of the environment variable NEW_FEATURE_ENABLED from the pod. This should show false as the current feature flag value.

Kubernetes

kubectl create configmap feature-flags --from-literal=NEW_FEATURE_ENABLED=false
kubectl patch deployment web-app --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/env", "value": [{"name": "NEW_FEATURE_ENABLED", "valueFrom": {"configMapKeyRef": {"name": "feature-flags", "key": "NEW_FEATURE_ENABLED"}}}]}]'
POD_NAME=$(kubectl get pods -l app=web-app -o jsonpath='{.items[0].metadata.name}')
kubectl exec $POD_NAME -- printenv NEW_FEATURE_ENABLED
# Run the command above and observe the output

Hint

The output should be exactly false, showing the feature flag is off.

Practice

1. What is the main purpose of feature flags in Kubernetes?

easy

A. To manage Kubernetes cluster nodes

B. To monitor cluster health

C. To schedule pods across nodes

D. To enable or disable application features without changing code

Solution

1. Step 1: Understand feature flags concept

   Feature flags allow toggling features on or off without modifying the application code.

2. Step 2: Relate to Kubernetes usage

   In Kubernetes, feature flags help control app behavior dynamically, often via ConfigMaps or environment variables.

3. Final Answer:

   To enable or disable application features without changing code -> Option D

4. Quick Check:

   Feature flags = toggle features without code change [OK]

Hint: Feature flags toggle features without code edits [OK]

Common Mistakes:

• Confusing feature flags with cluster management
• Thinking feature flags manage pods or nodes
• Mixing feature flags with monitoring tools

2. Which Kubernetes resource is commonly used to store feature flags for an application?

easy

A. Service

B. Pod

C. ConfigMap

D. Ingress

Solution

1. Step 1: Identify resource types

   Pods run containers, Services expose them, Ingress manages external access, ConfigMaps store configuration data.

2. Step 2: Match feature flags storage

   Feature flags are configuration data, so ConfigMaps are the right resource to store them.

3. Final Answer:

   ConfigMap -> Option C

4. Quick Check:

   Feature flags stored in ConfigMap [OK]

Hint: ConfigMaps hold config data like feature flags [OK]

Common Mistakes:

• Choosing Pod instead of ConfigMap
• Confusing Service or Ingress with config storage
• Thinking feature flags are stored in Secrets

3. Given this ConfigMap YAML snippet for feature flags:

apiVersion: v1
kind: ConfigMap
metadata:
  name: feature-flags
data:
  FEATURE_X_ENABLED: "true"
  FEATURE_Y_ENABLED: "false"

What will be the value of FEATURE_Y_ENABLED when accessed as an environment variable in a pod?

medium

A. false

B. true

C. null

D. undefined

Solution

1. Step 1: Read ConfigMap data values

   The ConfigMap sets FEATURE_Y_ENABLED to the string "false" explicitly.

2. Step 2: Understand environment variable mapping

   When injected as env vars, values are strings exactly as in ConfigMap, so FEATURE_Y_ENABLED will be "false".

3. Final Answer:

   false -> Option A

4. Quick Check:

   ConfigMap value "false" = env var "false" [OK]

Hint: Env vars get exact string values from ConfigMap [OK]

Common Mistakes:

• Assuming boolean false instead of string "false"
• Thinking missing keys return null or undefined
• Confusing string values with boolean types

4. You have this environment variable setup in a pod spec:

- name: FEATURE_Z_ENABLED
  valueFrom:
    configMapKeyRef:
      name: feature-flags
      key: FEATURE_Z_ENABLED

If the ConfigMap 'feature-flags' does not have the key FEATURE_Z_ENABLED, what will happen when the pod starts?

medium

A. Pod will fail to start with an error

B. Pod will start with FEATURE_Z_ENABLED set to an empty string

C. Pod will start with FEATURE_Z_ENABLED set to null

D. Pod will ignore the environment variable

Solution

1. Step 1: Understand configMapKeyRef behavior

   If the specified key is missing in the ConfigMap, Kubernetes treats it as an error.

2. Step 2: Effect on pod startup

   The pod will fail to start because the environment variable cannot be resolved from the ConfigMap key.

3. Final Answer:

   Pod will fail to start with an error -> Option A

4. Quick Check:

   Missing ConfigMap key causes pod start failure [OK]

Hint: Missing ConfigMap key breaks pod start [OK]

Common Mistakes:

• Assuming empty string or null is set silently
• Thinking pod ignores missing keys
• Confusing with optional environment variables

5. You want to enable a new feature only for 10% of users using feature flags in Kubernetes. Which approach best supports this scenario?

hard

A. Use a ConfigMap with a boolean flag set to true or false

B. Store a percentage value in ConfigMap and let the app decide feature enablement per user

C. Use a Secret to store the feature flag and update it daily

D. Deploy two versions of the app and route 10% traffic to the new version

Solution

1. Step 1: Understand percentage-based feature flags

   To enable a feature for a subset of users, the flag must support partial enablement, not just true/false.

2. Step 2: Evaluate options

   Store a percentage value in ConfigMap and let the app decide feature enablement per user stores a percentage in ConfigMap; the app reads it and enables the feature for that percent of users dynamically.

3. Final Answer:

   Store a percentage value in ConfigMap and let the app decide feature enablement per user -> Option B

4. Quick Check:

   Percentage flags need app logic with ConfigMap value [OK]

Hint: Use percentage value in ConfigMap for partial rollout [OK]

Common Mistakes:

• Using boolean flags for partial user enablement
• Relying on Secrets for feature flags
• Thinking traffic routing replaces feature flags