Creating ConfigMaps from literals in Kubernetes - Mechanics & Internals

Overview - Creating ConfigMaps from literals

What is it?

A ConfigMap in Kubernetes is a way to store configuration data as key-value pairs. Creating ConfigMaps from literals means defining these key-value pairs directly in the command line or manifest without using files. This allows you to quickly inject configuration settings into your applications running in Kubernetes.

Why it matters

Without ConfigMaps, you would have to bake configuration data directly into your application images or manage them manually inside containers, which is inflexible and error-prone. ConfigMaps let you separate configuration from code, making updates easier and safer without rebuilding images or restarting containers unnecessarily.

Where it fits

Before learning this, you should understand basic Kubernetes concepts like pods and containers. After mastering ConfigMaps from literals, you can learn about ConfigMaps from files, environment variables, and how to mount them as volumes for more complex configurations.

Mental Model

Core Idea

A ConfigMap from literals is like a small dictionary you create on the spot to pass configuration settings directly into your Kubernetes pods.

Think of it like...

Imagine writing a quick note with instructions on a sticky note and handing it directly to a friend instead of printing a whole manual. The sticky note is your literal ConfigMap—simple, direct, and easy to change.

┌─────────────────────────────┐
│ kubectl create configmap    │
│ ┌─────────────────────────┐ │
│ │ key1=value1             │ │
│ │ key2=value2             │ │
│ └─────────────────────────┘ │
│          ↓                  │
│ ConfigMap object created    │
│ with key-value pairs        │
└─────────────────────────────┘

Build-Up - 6 Steps

1

Foundation

What is a ConfigMap in Kubernetes

Concept: Introduce the basic idea of ConfigMaps as Kubernetes objects to hold configuration data separately from application code.

A ConfigMap stores configuration data as key-value pairs. It lets you keep settings outside your container images. This way, you can change configuration without rebuilding or redeploying your app. ConfigMaps are used by pods to get configuration data.

Result

You understand ConfigMaps are separate objects holding config data for Kubernetes pods.

Understanding ConfigMaps as separate config holders is key to managing app settings flexibly in Kubernetes.

2

Foundation

Basics of Creating ConfigMaps

Concept: Learn the simplest way to create a ConfigMap using kubectl with literal key-value pairs.

You can create a ConfigMap using the command: kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2 This command creates a ConfigMap named 'my-config' with two keys: key1 and key2.

Result

A ConfigMap named 'my-config' is created with the specified key-value pairs.

Knowing how to create ConfigMaps from literals lets you quickly inject config without files.

3

Intermediate

Using ConfigMaps in Pods

🤔Before reading on: do you think ConfigMaps from literals can be used as environment variables or mounted as files? Commit to your answer.

Concept: Learn how to use ConfigMaps created from literals inside pods as environment variables or mounted files.

Once you create a ConfigMap, you can use it in pod specs: 1. As environment variables: containers: - name: app image: myapp envFrom: - configMapRef: name: my-config 2. As files by mounting the ConfigMap as a volume: volumes: - name: config-volume configMap: name: my-config containers: - name: app volumeMounts: - name: config-volume mountPath: /etc/config This lets your app read config from environment or files.

Result

Pods can access ConfigMap data as environment variables or files.

Understanding how ConfigMaps integrate with pods is essential to applying configuration dynamically.

4

Intermediate

Overwriting ConfigMap Keys with Multiple Literals

🤔Before reading on: if you specify the same key twice with different values in literals, which value will Kubernetes keep? Commit to your answer.

Concept: Learn how Kubernetes handles duplicate keys when creating ConfigMaps from multiple literals.

If you run: kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key1=value2 Kubernetes will keep the last value specified for 'key1', which is 'value2'. Duplicate keys are overwritten by the last occurrence.

Result

ConfigMap 'my-config' has key1 with value 'value2'.

Knowing how duplicate keys behave prevents unexpected config overwrites in production.

5

Advanced

Editing and Updating ConfigMaps from Literals

🤔Before reading on: do you think you can update a ConfigMap created from literals by re-running the create command? Commit to your answer.

Concept: Learn how to update existing ConfigMaps created from literals and the difference between create and apply commands.

The 'kubectl create configmap' command fails if the ConfigMap already exists. To update, you can: 1. Use 'kubectl apply' with a manifest file. 2. Use 'kubectl create configmap --from-literal=... --dry-run=client -o yaml > config.yaml' to generate YAML, edit it, then apply. 3. Or delete and recreate the ConfigMap. Directly re-running create won't update existing ConfigMaps.

Result

You can update ConfigMaps safely using manifests or delete/recreate, avoiding errors.

Understanding update methods avoids downtime and errors when changing ConfigMaps.

6

Expert

Limitations and Best Practices for Literal ConfigMaps

🤔Before reading on: do you think ConfigMaps from literals are suitable for large or complex configurations? Commit to your answer.

Concept: Explore the limits of using literals for ConfigMaps and when to prefer other methods.

ConfigMaps from literals are great for small, simple key-value pairs. But for large or structured configs (like JSON or YAML), using files or manifests is better. Also, literals are less maintainable for many keys. Best practice is to use literals for quick tests or small configs, and files for production-grade setups.

Result

You know when to avoid literals and choose better ConfigMap creation methods.

Recognizing the limits of literals helps maintain clean, scalable Kubernetes configurations.

Under the Hood

When you create a ConfigMap from literals, Kubernetes stores the key-value pairs in etcd, the cluster's database, as part of the ConfigMap object. The API server validates and saves this data. When pods reference the ConfigMap, the kubelet fetches the data and injects it as environment variables or mounts it as files inside containers. This separation allows dynamic config updates without changing container images.

Why designed this way?

Kubernetes designed ConfigMaps to decouple configuration from container images to enable flexibility and easier updates. Using literals allows quick creation without needing files, which is convenient for simple or temporary configs. The design balances ease of use with the power of declarative configuration stored in etcd.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ kubectl CLI   │──────▶│ API Server    │──────▶│ etcd Storage  │
│ create config │       │ validates &   │       │ stores Config │
│ from literals │       │ stores Config │       │ Map object    │
└───────────────┘       └───────────────┘       └───────────────┘
         │                                         ▲
         │                                         │
         ▼                                         │
┌───────────────┐       ┌───────────────┐         │
│ kubelet on    │◀──────│ Pod references│─────────┘
│ node fetches  │       │ ConfigMap     │
│ injects env/  │       └───────────────┘
│ mounts files  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does creating a ConfigMap from literals require files? Commit yes or no.

Common Belief: You must always create ConfigMaps from files, not literals.

Reality: You can create ConfigMaps directly from literals using kubectl without any files.

Why it matters: Believing files are always needed slows down quick testing and simple config changes.

Quick: If you create a ConfigMap with duplicate keys in literals, will Kubernetes keep both? Commit yes or no.

Common Belief: Kubernetes keeps all duplicate keys separately in a ConfigMap.

Reality: Kubernetes overwrites duplicate keys, keeping only the last value specified.

Why it matters: Assuming duplicates are kept can cause unexpected config values and bugs.

Quick: Can you update a ConfigMap by re-running the create command with literals? Commit yes or no.

Common Belief: Running 'kubectl create configmap' again updates the existing ConfigMap.

Reality: The create command fails if the ConfigMap exists; you must use apply or delete first.

Why it matters: Trying to update with create causes errors and confusion in deployment workflows.

Quick: Are ConfigMaps from literals suitable for large, complex configurations? Commit yes or no.

Common Belief: Literals are fine for any size or complexity of configuration.

Reality: Literals are best for small configs; large or structured configs should use files or manifests.

Why it matters: Using literals for big configs leads to messy, hard-to-maintain setups.

Expert Zone

1

Literal ConfigMaps do not support multiline values well; you must encode or use files for complex data.

2

When multiple ConfigMaps are mounted as volumes, key conflicts can cause unexpected overwrites inside pods.

3

Using --from-literal is convenient but can lead to secrets accidentally stored in ConfigMaps if not careful.

When NOT to use

Avoid using literals for large or structured configuration data; instead, use ConfigMaps created from files or manifests. For sensitive data, use Secrets instead of ConfigMaps. When configuration changes frequently, consider using external config management tools integrated with Kubernetes.

Production Patterns

In production, ConfigMaps are often managed declaratively with YAML manifests and version-controlled. Teams use CI/CD pipelines to apply ConfigMaps safely. Literal creation is mostly for quick tests or demos. ConfigMaps are combined with Secrets and mounted as volumes or environment variables for flexible app configuration.

Connections

Environment Variables

ConfigMaps from literals often provide environment variables to pods.

Understanding ConfigMaps helps grasp how environment variables can be managed dynamically in containerized apps.

Infrastructure as Code (IaC)

Creating ConfigMaps from literals is a simple form of declarative configuration management.

Knowing this connects Kubernetes config management to broader IaC practices for reproducible infrastructure.

Key-Value Stores

ConfigMaps store configuration as key-value pairs, similar to databases like Redis or etcd.

Recognizing ConfigMaps as key-value stores helps understand their role in distributed system configuration.

Common Pitfalls

#1 Trying to update a ConfigMap by re-running the create command causes failure.

Wrong approach:

kubectl create configmap my-config --from-literal=key1=newvalue

Correct approach:

kubectl create configmap my-config --from-literal=key1=newvalue --dry-run=client -o yaml > config.yaml
kubectl apply -f config.yaml

Root cause:

Misunderstanding that 'create' cannot overwrite existing ConfigMaps; 'apply' or delete/recreate is needed.

#2 Specifying duplicate keys in literals expecting both to be stored.

Wrong approach:

kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key1=value2

Correct approach:

kubectl create configmap my-config --from-literal=key1=value2

Root cause:

Not knowing Kubernetes overwrites duplicate keys with the last value.

#3 Using literals for large or multiline configuration data.

Wrong approach:

kubectl create configmap big-config --from-literal=config='line1
line2
line3'

Correct approach:

kubectl create configmap big-config --from-file=config=./config-file.txt

Root cause:

Literals do not handle multiline or complex data well; files are better suited.

Key Takeaways

ConfigMaps from literals let you quickly create simple key-value configurations in Kubernetes without files.

They are best for small, straightforward settings and not suited for large or complex data.

You cannot update ConfigMaps by re-running create; use apply or delete and recreate instead.

Duplicate keys in literals overwrite previous values, keeping only the last one.

Using ConfigMaps separates configuration from code, making your applications more flexible and easier to manage.