ConfigMap Consumption Methods
A ConfigMap is one object, but a Pod can consume it three ways at once - as an environment variable, as a mounted directory, and as a single file placed with subPath. Change the ConfigMap and the three stop agreeing. One updates after a delay you can measure, one never updates at all, and one is only fixed by replacing the Pod. This is the reason a config change appears to work in testing and does nothing in production.
Kubernetes Fundamentals Guide 7 of 46 Beginner
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- Cluster4 nodes
- TimeAbout 14 min
- Reviewed23 August 2026
Written against the versions above. The propagation delay here is the kubelet's own sync period, not a fixed constant: it is configurable through `syncFrequency` and the `configMapAndSecretChangeDetectionStrategy` in the kubelet config. The 95 seconds measured below is what a default kubeadm cluster produced on the day, not a number to quote back.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A cluster and kubectl. Nothing is installed - ConfigMap, Deployment and volumes are all built in.
- The session creates a namespace
kx-cfg, a ConfigMapappcfgholding one key, and a Deploymentreaderthat consumes that key three different ways at once.
-
One ConfigMap, consumed three ways
-
They agree, which is what hides the problem
-
Change it once, and nothing happens
-
Ninety-five seconds later, one of them moves
-
The only thing that moves an environment variable