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.