Kubernetes provides a resource named ConfigMap to externalize the parameters to pass to your application in the form of key-value pairs or embedded application.properties or application.yaml files. The Spring Cloud Kubernetes Config project makes Kubernetes ConfigMap instances available during application startup and triggers hot reloading of beans or Spring context when changes are detected on observed ConfigMap instances.

Everything that follows is explained mainly referring to examples using ConfigMaps, but the same stands for Secrets, i.e.: every feature is supported for both.

The default behavior is to create a Fabric8ConfigMapPropertySource (or a KubernetesClientConfigMapPropertySource) based on a Kubernetes ConfigMap that has a metadata.name value of either the name of your Spring application (as defined by its spring.application.name property) or a custom name defined within the application.properties file under the following key: spring.cloud.kubernetes.config.name.

However, more advanced configuration is possible where you can use multiple ConfigMap instances. The spring.cloud.kubernetes.config.sources list makes this possible. For example, you could define the following ConfigMap instances:

In the preceding example, if spring.cloud.kubernetes.config.namespace had not been set, the ConfigMap named c1 would be looked up in the namespace that the application runs. See Namespace resolution to get a better understanding of how the namespace of the application is resolved.

Any matching ConfigMap that is found is processed as follows:

• Apply individual configuration properties.

• Apply as yaml (or properties) the content of any property that is named by the value of spring.application.name (if it’s not present, by application.yaml/properties)

• Apply as a properties file the content of the above name + each active profile.

An example should make a lot more sense. Let’s suppose that spring.application.name=my-app and that we have a single active profile called k8s. For a configuration as below:

These is what we will end-up loading:

• my-app.yaml treated as a file

• my-app-k8s.yaml treated as a file

• my-app-dev.yaml ignored, since dev is not an active profile

• someProp: someValue plain property

The single exception to the aforementioned flow is when the ConfigMap contains a single key that indicates the file is a YAML or properties file. In that case, the name of the key does NOT have to be application.yaml or application.properties (it can be anything) and the value of the property is treated correctly. This features facilitates the use case where the ConfigMap was created by using something like the following:

Assume that we have a Spring Boot application named demo that uses the following properties to read its thread pool configuration.

• pool.size.core

• pool.size.maximum

This can be externalized to config map in yaml format as follows:

Individual properties work fine for most cases. However, sometimes, embedded yaml is more convenient. In this case, we use a single property named application.yaml to embed our yaml, as follows:

The following example also works:

You can also define the search to happen based on labels, for example:

This will search for every configmap in namespace spring-k8s that has labels {letter : a}. The important thing to notice here is that unlike reading a configmap by name, this can result in multiple config maps read. As usual, the same feature is supported for secrets.

You can also configure Spring Boot applications differently depending on active profiles that are merged together when the ConfigMap is read. You can provide different property values for different profiles by using an application.properties or application.yaml property, specifying profile-specific values, each in their own document (indicated by the --- sequence), as follows:

In the preceding case, the configuration loaded into your Spring Application with the development profile is as follows:

However, if the production profile is active, the configuration becomes:

If both profiles are active, the property that appears last within the ConfigMap overwrites any preceding values.

Another option is to create a different config map per profile and spring boot will automatically fetch it based on active profiles

To tell Spring Boot which profile should be enabled see the Spring Boot documentation. One option for activating a specific profile when deploying to Kubernetes is to launch your Spring Boot application with an environment variable that you can define in the PodSpec at the container specification. Deployment resource file, as follows:

You could run into a situation where there are multiple configs maps that have the same property names. For example:

and

Depending on the order in which you place these in bootstrap.yaml|properties, you might end up with an un-expected result (the last config map wins). For example:

will result in property greetings.message being Say Hello from one.

There is a way to change this default configuration by specifying useNameAsPrefix. For example:

Such a configuration will result in two properties being generated:

• greetings.message equal to Say Hello from one.

• config-map-two.greetings.message equal to Say Hello from two

Notice that spring.cloud.kubernetes.config.useNameAsPrefix has a lower priority than spring.cloud.kubernetes.config.sources.useNameAsPrefix. This allows you to set a "default" strategy for all sources, at the same time allowing to override only a few.

If using the config map name is not an option, you can specify a different strategy, called : explicitPrefix. Since this is an explicit prefix that you select, it can only be supplied to the sources level. At the same time it has a higher priority than useNameAsPrefix. Let’s suppose we have a third config map with these entries:

A configuration like the one below:

will result in three properties being generated:

• greetings.message equal to Say Hello from one.

• two.greetings.message equal to Say Hello from two.

• config-map-three.greetings.message equal to Say Hello from three.

The same way you configure a prefix for configmaps, you can do it for secrets also; both for secrets that are based on name and the ones based on labels. For example:

The same processing rules apply when generating property source as for config maps. The only difference is that potentially, looking up secrets by labels can mean that we find more than one source. In such a case, prefix (if specified via useNameAsPrefix) will be the names of all secrets found for those particular labels.

One more thing to bear in mind is that we support prefix per source, not per secret. The easiest way to explain this is via an example:

Suppose that a query matching such a label will provide two secrets as a result: secret-a and secret-b. Both of these secrets have the same p