What does Spring Cloud Kubernetes do with a ConfigMap, and how does its data reach your beans?
answer
- ConfigMap -> ConfigMapPropertySource in Environment
- name defaults to spring.application.name
- spring.config.import=kubernetes: (modern) vs bootstrap (legacy)
- read once at startup unless reload enabled
- RBAC: get on configmaps
basics
~10 sSpring Cloud Kubernetes reads a Kubernetes ConfigMap (named after your app) and adds its key/value entries to the Spring Environment as a PropertySource, so @Value and @ConfigurationProperties see them like any other property.
solid answer
~40 sA ConfigMap is a Kubernetes object holding non-secret config as key/value pairs. Spring Cloud Kubernetes contributes a `ConfigMapPropertySource` into the Spring `Environment` during startup, so those keys become ordinary Spring properties resolvable by `@Value`, `@ConfigurationProperties`, and `Environment.getProperty`. By default it looks up the ConfigMap whose name equals `spring.application.name` in the pod's namespace. You wire it in either via `spring.config.import=kubernetes:` (modern, non-bootstrap) or the legacy bootstrap starter. It supports flat keys and embedded `application.yaml`/`.properties` blobs inside a single ConfigMap key. This removes the need to bake config into the image or pass everything as env vars; ops changes the ConfigMap, not the container.
code
yaml · 21 lines# application.yml — modern (non-bootstrap) wiring
spring:
application:
name: orders-service # -> looks up ConfigMap named 'orders-service'
config:
import: "kubernetes:" # pulls ConfigMap (+ Secrets) into the Environment
cloud:
kubernetes:
config:
enabled: true
# name: orders-service # optional override
# namespace: prod # optional; defaults to pod namespace
---
# The ConfigMap itself
apiVersion: v1
kind: ConfigMap
metadata:
name: orders-service
data:
logging.level.root: INFO
orders.max-items: "50"go deeper
Know that a ConfigMap becomes a normal Spring property source and the ConfigMap name defaults to the app name.
Explain modern spring.config.import=kubernetes: vs legacy bootstrap, config.sources, and RBAC needs.
Contrast Fabric8 vs official-client starters, embedded application.yaml blobs, fail-fast, and namespace resolution.
Position it as a Config-Server-free config strategy and reason about startup ordering, RBAC blast radius, and multi-source precedence.
**What a ConfigMap is.** A Kubernetes `ConfigMap` is a cluster object that stores non-confidential configuration as key/value pairs (`data:`). Pods normally consume it as environment variables or mounted files. Spring Cloud Kubernetes offers a third path: pull it straight into the Spring `Environment`. **PropertySource contribution.** The Spring `Environment` is an ordered list of `PropertySource` objects (system props, `application.yml`, env vars, …). Spring Cloud Kubernetes adds a `ConfigMapPropertySource` (Fabric8 impl) / `KubernetesClientConfigMapPropertySource` (official-client impl). Once present, ConfigMap entries are indistinguishable from any other property to `@Value("${...}")`, `@ConfigurationProperties`, and `Environment#getProperty`. **Which ConfigMap.** Controlled by `spring.cloud.kubernetes.config.*`: - `name` — ConfigMap name; defaults to `spring.application.name`. - `namespace` — defaults to the pod's own namespace (read from the service-account token mount). - `sources` — an explicit list of `{name, namespace}` when you need several ConfigMaps. - `enabled` — default `true`. **Two shapes of ConfigMap data.** (1) Flat entries: `data: { logging.level.root: DEBUG }` become individual properties. (2) A single key holding a whole file, e.g. `application.yaml: |` … — Spring Cloud Kubernetes parses that YAML/properties blob and flattens it. Profile-specific documents inside that blob are honored. **How you enable it.** Two eras: - **Modern (Spring Cloud 2020.0+):** the bootstrap context is off by default. You add `spring.config.import=kubernetes:` to `application.yml` (optionally `kubernetes:my-config`). This uses the `ConfigData` API. - **Legacy bootstrap:** add `spring-cloud-starter-bootstrap` (or `spring.cloud.bootstrap.enabled=true`); the property source is loaded in the bootstrap phase before the main context. **Implementations.** Two starters exist: `spring-cloud-starter-kubernetes-fabric8-config` (Fabric8 client) and `spring-cloud-starter-kubernetes-client-config` (official Kubernetes Java client). Same behavior, different underlying client. **RBAC.** The pod's service account must have `get` (and `list`/`watch` if you enable reload) permission on `configmaps` in the namespace, granted via a `Role` + `RoleBinding`. Missing RBAC → the property source is silently empty or the app fails, depending on `fail-fast`. **When to use.** You want cluster-managed config that ops can change without rebuilding the image, and you want it to look like normal Spring config. It replaces a Config Server for teams already standardized on Kubernetes. **Gotcha:** without reload enabled, editing the ConfigMap does NOT update a running app — the property source is read once at startup.
- If I edit the ConfigMap in the cluster, does my running app pick up the change automatically?No. The property source is read once at context startup. You must enable `spring.cloud.kubernetes.reload.enabled=true` for a running app to rebind to changed values; otherwise the change is seen only on the next restart.
- What happens if the ConfigMap doesn't exist?By default the app starts anyway with an empty property source. Set `spring.cloud.kubernetes.config.fail-fast=true` to fail startup instead when the ConfigMap can't be read.
saying these in an interview costs you the question
- Thinking ConfigMap changes hot-reload automatically without enabling reload
- Believing a ConfigMap can only be consumed as env vars or mounted files
- Confusing this with the git-backed Config Server