Introduction

Kubernetes ConfigMaps exist so application settings do not have to be baked into container images. When people talk about "externalising" ConfigMap values, they usually mean moving configuration into files, environment-specific inputs, or deployment templates so the same image can be reused across development, staging, and production.

Why Externalize ConfigMap Values

Inline YAML works for a quick test, but it becomes fragile as soon as values differ by environment. A deployment manifest with copied blocks of data: values is hard to review, easy to drift, and awkward to update in a controlled way.

Externalizing the data solves three practical problems:

• the image stays environment-agnostic
• configuration changes can be reviewed without rebuilding
• different environments can supply different values from separate files

For example, this inline ConfigMap is valid, but not ideal once you have more than one environment:

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: app-config
5data:
6  LOG_LEVEL: info
7  FEATURE_X_ENABLED: "false"
8  API_BASE_URL: https://api.example.com

The problem is not that the YAML is wrong. The problem is that the manifest itself has become the source of truth for values that will eventually vary.

Generate ConfigMaps from Files

The simplest externalization pattern is to store configuration in a normal file and generate the ConfigMap from that file. That keeps values readable and easy to update.

An environment file is often enough:

1cat > app.env <<'EOF'
2LOG_LEVEL=info
3FEATURE_X_ENABLED=false
4API_BASE_URL=https://api.example.com
5EOF
6
7kubectl create configmap app-config \
8  --from-env-file=app.env \
9  --dry-run=client -o yaml

If the application expects a full config file, use --from-file instead:

1cat > application.yaml <<'EOF'
2server:
3  port: 8080
4featureFlags:
5  featureX: true
6EOF
7
8kubectl create configmap app-config \
9  --from-file=application.yaml \
10  --dry-run=client -o yaml

This pattern is usually better than editing a large multiline YAML literal directly in the manifest. The source file can also be validated by the application locally before it ever reaches the cluster.

Consume ConfigMaps as Environment Variables or Files

After the ConfigMap exists, a Pod can consume it in two main ways. The first option is env or envFrom, which is a good fit for flat key-value settings.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: demo-app
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: demo-app
10  template:
11    metadata:
12      labels:
13        app: demo-app
14    spec:
15      containers:
16        - name: demo-app
17          image: nginx:stable
18          envFrom:
19            - configMapRef:
20                name: app-config

The second option is mounting the ConfigMap as a file. That is the better choice when the application already reads a configuration file from disk.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: demo-app
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: demo-app
10  template:
11    metadata:
12      labels:
13        app: demo-app
14    spec:
15      containers:
16        - name: demo-app
17          image: nginx:stable
18          volumeMounts:
19            - name: app-config-volume
20              mountPath: /etc/demo
21      volumes:
22        - name: app-config-volume
23          configMap:
24            name: app-config

Choosing between those two styles matters. Environment variables are easy to use but usually require a restart to pick up changes. Mounted files can refresh on disk, but your application still needs a reload strategy if it should react without a restart.

Use Kustomize or Helm for Environment-Specific Values

Manual kubectl create configmap commands are fine for a local cluster, but teams usually want the configuration expressed declaratively in source control. Kustomize and Helm are both common ways to do that.

With Kustomize, the configMapGenerator block can generate the ConfigMap from a file per environment:

1configMapGenerator:
2  - name: app-config
3    envs:
4      - app.env

Now overlays/dev/app.env and overlays/prod/app.env can differ without changing the base Deployment. That is a cleaner separation than copying complete ConfigMap objects into multiple folders and editing them by hand.

Helm solves the same problem with values files. The important idea is the same in both tools: keep the workload template stable and feed it different configuration inputs.

Treat Reload Behavior as a Separate Concern

Externalization often gets confused with dynamic reloading. They are not the same thing. Externalization means the values come from outside the image. It does not guarantee the running process will notice changes immediately.

If your Pod reads values from environment variables, a Deployment rollout is usually required after the ConfigMap changes. A common operational pattern is:

kubectl apply -f configmap.yaml
kubectl rollout restart deployment/demo-app

For mounted files, Kubernetes can update the projected files, but the application has to re-read them. Some applications support that natively; others need a sidecar or a manual restart.

Common Pitfalls

The first mistake is putting secrets into a ConfigMap. Externalized configuration is still configuration, not secret storage, so passwords and API tokens belong in Secret objects or a dedicated secret manager. Another common problem is duplicating the same data: block across many manifests instead of using a generator or a values file. Teams also assume that changing a ConfigMap automatically updates process environment variables in already-running containers, which is usually false. Finally, storing large application config inline inside one long YAML literal often makes reviews worse, not better, because the real source content is hidden inside deployment plumbing.

Summary

• Externalizing ConfigMap values means keeping configuration outside the image and outside copied inline YAML blocks.
• '--from-env-file works well for simple key-value settings, and --from-file works better for full config files.'
• Pods can consume ConfigMaps as environment variables or mounted files, depending on how the application reads config.
• Kustomize and Helm are useful when different environments need different values with the same deployment shape.
• Updating a ConfigMap does not automatically solve application reload behavior, so plan restarts or reload logic separately.