Feature flags in Kubernetes - Step-by-Step Execution

Process Flow - Feature flags in Kubernetes

Define Feature Flag ConfigMap

↓

Deploy Application with Flag Check

↓

App Reads Flag from ConfigMap

↓

Flag ON?

No→Run Default Behavior

Yes↓

Run Feature Enabled Behavior

↓

Update Flag in ConfigMap to Toggle Feature

↓

App Detects Change (via reload or watch)

↓

Feature Behavior Changes Dynamically

This flow shows how a Kubernetes app uses a ConfigMap as a feature flag, reads it at runtime, and changes behavior dynamically when the flag is updated.

Execution Sample

Kubernetes

apiVersion: v1
kind: ConfigMap
metadata:
  name: feature-flags
data:
  newFeature: "false"

This ConfigMap defines a feature flag named 'newFeature' set to false initially.

Process Table

Step	Action	ConfigMap 'newFeature' Value	App Behavior	Notes
1	Deploy ConfigMap with newFeature=false	false	Feature OFF: app runs default code	Initial flag set to false
2	Deploy app that reads ConfigMap	false	Reads flag as false	App starts with feature disabled
3	App runs with feature OFF	false	Default behavior executed	No feature code runs
4	Update ConfigMap newFeature=true	true	Still OFF	Admin enables feature
5	App reloads or watches ConfigMap	true	Reads flag as true	App detects flag change
6	App runs with feature ON	true	Feature enabled behavior executed	New feature active
7	Update ConfigMap newFeature=false	false	Still ON	Admin disables feature
8	App reloads or watches ConfigMap	false	Reads flag as false	App detects flag off
9	App runs with feature OFF	false	Default behavior executed	Feature turned off again
10	End of demo	false	Feature OFF	Execution stops

💡 Demo ends after toggling feature flag on and off with app reacting accordingly

Status Tracker

Variable	Start	After Step 4	After Step 7	Final
ConfigMap newFeature	false	true	false	false
App Feature State	OFF	ON	OFF	OFF

Key Moments - 3 Insights

How does the app know when the feature flag changes?

The app either reloads the ConfigMap periodically or uses a watch mechanism to detect changes, as shown in steps 5 and 8 in the execution table.

Why use a ConfigMap for feature flags instead of hardcoding?

ConfigMaps allow changing flags without redeploying the app, enabling dynamic feature toggling as seen in steps 4 and 7.

What happens if the app doesn't reload the ConfigMap after a change?

The app continues using the old flag value and behavior until restarted or reloaded, so feature toggling won't take effect immediately (refer to steps 5 and 8).

Visual Quiz - 3 Questions

Look at the execution table, what is the app's feature state after step 4?

A OFF

B ON

C Unknown

D Error

💡 Hint

Check the ConfigMap value and app behavior columns at step 4 and 5

At which step does the app detect the feature flag change to true?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Look for when the app reloads or watches the ConfigMap in the execution table

If the ConfigMap update at step 7 was not applied, what would be the app's feature state at step 9?

A OFF

B ON

C Unknown

D Error

💡 Hint

Refer to variable_tracker for ConfigMap and app feature state changes

Concept Snapshot

Feature flags in Kubernetes use ConfigMaps to toggle features dynamically.
Apps read flags from ConfigMaps at runtime.
Updating ConfigMaps changes feature behavior without redeploy.
Apps must reload or watch ConfigMaps to detect changes.
This enables safe, gradual feature rollout and quick rollback.

Full Transcript

Feature flags in Kubernetes are often implemented using ConfigMaps. A ConfigMap stores key-value pairs, like a flag named 'newFeature' set to 'false'. When the app starts, it reads this flag and runs default behavior. If an admin updates the ConfigMap to 'true', the app can detect this change by reloading or watching the ConfigMap. Then, the app switches to the new feature behavior dynamically. If the flag is set back to 'false', the app returns to default behavior. This method allows toggling features on and off without redeploying the app, making feature management flexible and safe.

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