We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Kubernetes & Containers
A K8s resource that stores non-sensitive configuration data as key-value pairs. Pods read ConfigMaps as environment variables or mounted files, decoupling config from code.
In short
A Kubernetes ConfigMap is a built-in resource that stores non-sensitive configuration as key-value pairs, so you can keep settings like database hosts, feature flags, and log levels out of your container image. Pods consume a ConfigMap as environment variables, command-line arguments, or files mounted into a volume, which lets you change configuration without rebuilding the container image.
In short
A Kubernetes ConfigMap is a built-in resource that stores non-sensitive configuration as key-value pairs, so you can keep settings like database hosts, feature flags, and log levels out of your container image. Pods consume a ConfigMap as environment variables, command-line arguments, or files mounted into a volume, which lets you change configuration without rebuilding the container image.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Kubernetes ConfigMap across a run of lessons, not one page. These 4 alone are about 84 minutes of step-by-step reading, every one with a quiz.
Separating configuration from code, the key to running the same application in development, staging, and production.
Decoupling storage from pods so data survives container restarts, rescheduling, and failures.
Toggle features on and off without deployment, kill switches for problematic features.
Deploying code to production without releasing features to users, decoupling deployment from release.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Environment Variablespay once,
yours for life
A ConfigMap is a Kubernetes API object whose whole job is to hold configuration data separately from the code that uses it. You define it once, store key-value pairs in it (for example LOG_LEVEL=info or a full nginx.conf file), and then point one or more Pods at it. The container image stays generic and the environment-specific values live in the cluster.
This solves a real problem. Without ConfigMaps you end up baking config into the image, which means a separate image per environment, or you pass dozens of flags at deploy time and lose track of them. With a ConfigMap, the same image runs in dev, staging, and production, and only the ConfigMap differs.
ConfigMaps are for non-sensitive data only. Anyone with read access to the namespace can read them in plain text, and they are not encrypted at rest by default. Passwords, API keys, and TLS certificates belong in a Secret, which has the same shape but is treated as confidential.
There are three ways a Pod reads a ConfigMap. First, as environment variables: you map individual keys to env vars, or pull every key in at once with envFrom. Second, as command-line arguments built from those env vars. Third, mounted as a volume, where each key becomes a file and the value becomes the file contents inside the container.
The mount method matters because of how updates behave. Environment variables are read once when the container starts, so changing the ConfigMap does nothing to a running Pod, you have to restart it. A mounted volume is different: the kubelet periodically syncs the files, and an updated ConfigMap propagates into the volume on its own, typically within about 60 to 90 seconds. Your application still has to notice the changed file and reload, since Kubernetes only updates the bytes on disk.
One sharp edge: if you mount a single key using subPath, that file will not update when the ConfigMap changes. Only full-volume mounts get live updates. ConfigMap data is also stored in etcd and is capped at 1 MiB per object, because etcd is built for small metadata, not large blobs.
Reach for a ConfigMap whenever a value would differ between environments or might need changing without a code release: service endpoints, timeouts, feature flags, log verbosity, or an entire config file like prometheus.yml. It is the standard Kubernetes way to externalize configuration and keep the twelve-factor separation of config from code.
The main trade-off is around updates. A mutable ConfigMap means Kubernetes watches it, which adds a little API server and kubelet load, and live volume updates can surprise an app that does not expect its config file to change underneath it. Setting immutable: true on a ConfigMap blocks all edits (you must delete and recreate to change it) and in return reduces watch load and protects against accidental changes. This is valuable in large clusters with thousands of ConfigMaps.
A common pattern to force a clean rollout is to put a hash of the ConfigMap contents in an annotation on the Deployment's Pod template, so the annotation changes whenever the ConfigMap does. That makes Kubernetes do a normal rolling update and restart Pods with the new config, instead of relying on the slow and partial volume sync.
Say you run a web API that reads DATABASE_HOST, CACHE_TTL_SECONDS, and a logging.json file. You create a ConfigMap named api-config with those three keys. In the Deployment you set DATABASE_HOST and CACHE_TTL_SECONDS as env vars from the ConfigMap, and you mount logging.json into /etc/app/ as a volume.
To move from staging to production you do not touch the image at all. You apply a different api-config in the production namespace pointing DATABASE_HOST at the production database. The same container image runs in both places. If you later raise CACHE_TTL_SECONDS, you edit the ConfigMap and trigger a rolling restart so the env var change takes effect, while the logging.json file would refresh on its own through the mounted volume.
Kubernetes
Ships ConfigMap as a core API object; kubelet syncs mounted ConfigMap files into running Pods and the API server enforces the 1 MiB etcd limit.
Helm
Templates ConfigMaps per release so the same chart deploys with different values across dev, staging, and production environments.
Prometheus Operator
Stores scrape and alerting configuration in ConfigMaps that the operator mounts into Prometheus Pods, letting you change monitoring rules without rebuilding the image.
NGINX Ingress Controller
Reads a single ConfigMap to tune global settings like proxy buffer sizes and timeouts, applying them to the NGINX process without a new container build.
Both store key-value configuration and are consumed the same way, but a Secret is meant for sensitive data like passwords and tokens. Secret values are base64-encoded and can be encrypted at rest and access-controlled more tightly, while ConfigMap values are stored in plain text. Use a ConfigMap for non-sensitive config and a Secret for anything confidential.
Only partially. Values mounted as a volume refresh on their own, usually within about 60 to 90 seconds, but your app still has to reload the file. Values injected as environment variables are read once at container start and never change until you restart the Pod. To be safe, trigger a rolling restart after editing a ConfigMap.
Yes. A single ConfigMap cannot exceed 1 MiB because it is stored in etcd, which is built for small metadata. If you need more, split the data across multiple ConfigMaps or mount large files from a PersistentVolume or an init container instead.
Setting immutable: true blocks all future edits to that ConfigMap; to change it you must delete and recreate it. In return, the kubelet and API server stop watching it for changes, which lowers load in clusters with many ConfigMaps and prevents accidental updates. ConfigMaps are mutable by default.
subPath mounts are resolved once at Pod start and are not kept in sync, so changes to the ConfigMap never reach a subPath-mounted file. To get live updates, mount the whole ConfigMap as a directory volume instead, or restart the Pod after each change.
Kubernetes
An orchestration platform that automates deploying, scaling, and managing containerized applications. K8s is the operating system for your cloud.
Kubernetes Pod
The smallest deployable unit in Kubernetes: one or more containers sharing network and storage. Pods are ephemeral; if one dies, K8s creates a replacement.
Kubernetes Secret
A K8s resource for storing sensitive data like passwords, tokens, and certificates. Base64-encoded by default; use encryption at rest and RBAC to properly secure them.
Docker
A platform for packaging applications into lightweight, portable containers. 'Works on my machine' becomes 'works everywhere.'
Container
A lightweight, isolated environment that packages an application with its dependencies. Shares the host OS kernel, unlike VMs. Starts in milliseconds.
Kubernetes Service
A stable network endpoint that load-balances traffic across a set of pods. Pods come and go, but the Service's IP and DNS name stay constant.
This page explains the idea. The course covers it step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
See the System Design Masterclass coursecourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Kubernetes ConfigMap in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
