ConfigMap Theory

Kubernetes has an API resource called a ConfigMap (CM) that lets us store configuration data outside of Pods and inject it at run time.

ConfigMaps are first-class objects in the core API group. They’re also v1. This tells us a few things:

1. They’re stable (v1)

2. They’ve been around for a while (new stuff never goes in the core API group)

3. We can define and deploy them in YAML files

4. We can manage them with kubectl

We’ll typically use ConfigMaps to store non-sensitive configuration data such as:

• Environment variables

• Configuration files such as web server configs and database configs

• Hostnames

• Service ports

• Account names

We should not use ConfigMaps to store sensitive data such as certificates and passwords, as Kubernetes makes no effort to protect their contents. For sensitive data, we should use a combination of Kubernetes Secrets and 3rd-party tools.

We’ll see how to use Secrets later in the chapter.

How ConfigMaps work

At a high level, a ConfigMap is a place to store configuration data that we can easily inject into containers at run time. They’re also transparent to applications, meaning we don’t have to change our applications to work with them.

Let’s look a bit closer.

Behind the scenes, ConfigMaps are Kubernetes objects that hold a map of key-value pairs:

• Keys are an arbitrary name that can include alphanumerics, dashes, dots, and underscores

• Values can include anything, including full configuration files with multiple lines and carriage returns

• We separate keys and values with a colon – key:value

• They’re also limited to 1MiB (1,048,576 bytes) in size

Here’s a ConfigMap with three simple entries.