Hands-on Lab·Kubernetes and Cloud Native Associate

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
Cluster4 nodes
Runtimecontainerd 2.2.6
CNICalico v3.32.1
TimeAbout 14 min

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.

The Pod runs on whichever worker the scheduler picks - the propagation delay is the kubelet's on that node, so all four machines are listed.
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

This guide includes

Use this when a configuration change has been applied but the application is still serving the old value. This matters because the three ways a Pod can read a ConfigMap update at three different times, and one of them never updates at all.

consuming one ConfigMap three ways in a single Pod - environment variable, mounted directory, and a single file placed by subPath
confirming all three agree first, which is the state that hides the problem
patching the ConfigMap and seeing that nothing changes immediately
polling the mounted file until it updates, roughly ninety seconds later, while the other two do not move
using kubectl rollout restart as the only thing that moves an environment variable

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 ConfigMap appcfg holding one key, and a Deployment reader that 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

Official sources

← All KCNA guides

ConfigMap Consumption Methods

This guide includes

Before you start

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

Official sources