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.

Practice

1. What does the kubectl create configmap command with the --from-literal option do?

easy

A. Lists all ConfigMaps in the current namespace

B. Deletes an existing ConfigMap by specifying literal values

C. Updates a ConfigMap with values from a file

D. Creates a ConfigMap with key-value pairs directly from command line literals

Solution

1. Step 1: Understand the command purpose

   The kubectl create configmap command is used to create a new ConfigMap resource in Kubernetes.

2. Step 2: Role of --from-literal

   The --from-literal option allows adding key-value pairs directly from the command line as literals, without needing a file.

3. Final Answer:

   Creates a ConfigMap with key-value pairs directly from command line literals -> Option D

4. Quick Check:

   Creating ConfigMap from literals = Creates a ConfigMap with key-value pairs directly from command line literals [OK]

Hint: Remember: --from-literal adds key=value pairs directly [OK]

Common Mistakes:

• Confusing create with delete commands
• Thinking --from-literal reads from files
• Assuming it lists ConfigMaps

2. Which of the following is the correct syntax to create a ConfigMap named app-config with two literals: mode=production and debug=false?

easy

A. kubectl create configmap app-config --from-literal=mode=production --from-literal=debug=false

B. kubectl create configmap app-config --from-literal mode=production debug=false

C. kubectl create configmap app-config --from-literal mode=production --from-literal debug false

D. kubectl create configmap app-config --from-literal=mode production --from-literal=debug false

Solution

1. Step 1: Check correct option format for literals

   The correct syntax requires each literal to be passed with --from-literal=key=value format.

2. Step 2: Validate kubectl create configmap app-config --from-literal=mode=production --from-literal=debug=false

   kubectl create configmap app-config --from-literal=mode=production --from-literal=debug=false uses --from-literal=mode=production and --from-literal=debug=false, which is the correct syntax.

3. Final Answer:

   kubectl create configmap app-config --from-literal=mode=production --from-literal=debug=false -> Option A

4. Quick Check:

   Correct literal syntax uses '=' after --from-literal [OK]

Hint: Use '=' immediately after --from-literal for each key=value pair [OK]

Common Mistakes:

• Omitting '=' after --from-literal
• Passing multiple literals without repeating --from-literal
• Using spaces instead of '=' between key and value

3. What will be the output of the command?

kubectl create configmap test-config --from-literal=env=dev --from-literal=version=1.2

Then run:

kubectl get configmap test-config -o yaml

medium

A. A ConfigMap named 'test-config' with data keys 'env' and 'version' set to 'dev' and '1.2'

B. An error because multiple --from-literal options are not allowed

C. A ConfigMap with keys 'env=dev' and 'version=1.2' as single strings

D. Empty ConfigMap with no data

Solution

1. Step 1: Understand multiple literals usage

   The command uses two --from-literal options, which is valid to add multiple key-value pairs.

2. Step 2: Output of kubectl get configmap -o yaml

   The output YAML will show a ConfigMap named 'test-config' with a data section containing keys 'env' and 'version' with their respective values.

3. Final Answer:

   A ConfigMap named 'test-config' with data keys 'env' and 'version' set to 'dev' and '1.2' -> Option A

4. Quick Check:

   Multiple literals create multiple keys in ConfigMap data [OK]

Hint: Multiple --from-literal options add multiple keys [OK]

Common Mistakes:

• Thinking multiple literals cause errors
• Expecting keys to include '=' sign
• Assuming ConfigMap data is empty

4. You run this command:

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

But it fails with an error. What is the likely cause?

medium

A. The command does not support any literals

B. Missing '=' after --from-literal for the second key-value pair

C. ConfigMap name 'my-config' is invalid

D. You must use --from-file instead of --from-literal

Solution

1. Step 1: Analyze command syntax

   The command uses --from-literal=key1=value1 correctly but then adds key2=value2 without --from-literal=.

2. Step 2: Understand correct usage

   Each literal must be preceded by its own --from-literal= option. Omitting it causes a syntax error.

3. Final Answer:

   Missing '=' after --from-literal for the second key-value pair -> Option B

4. Quick Check:

   Each literal needs its own --from-literal= [OK]

Hint: Repeat --from-literal= for each key=value pair [OK]

Common Mistakes:

• Passing multiple literals without repeating --from-literal
• Assuming one --from-literal can take multiple pairs
• Confusing --from-literal with --from-file

5. You want to create a ConfigMap named app-settings with these key-value pairs:
env=production, debug=false, and timeout=0. You run:

kubectl create configmap app-settings --from-literal=env=production --from-literal=debug=false --from-literal=timeout=0

Later, you mount this ConfigMap as environment variables in a Pod. What should you be careful about regarding the timeout value?

hard

A. The timeout key will be converted to boolean false automatically

B. The value '0' will be ignored because it is falsy

C. The value '0' is a string and will be passed as "0", not as a number zero

D. The ConfigMap will fail to create because '0' is invalid

Solution

1. Step 1: Understand ConfigMap data types

   ConfigMaps store all values as strings, so '0' is stored as the string "0".

2. Step 2: Effect when used as environment variable

   When mounted as environment variables, the value will be "0" (string), not a numeric zero or boolean false.

3. Final Answer:

   The value '0' is a string and will be passed as "0", not as a number zero -> Option C

4. Quick Check:

   ConfigMap values are strings, even '0' [OK]

Hint: ConfigMap values are always strings, watch for '0' as string [OK]

Common Mistakes:

• Assuming '0' is treated as false or ignored
• Expecting automatic type conversion
• Thinking ConfigMap creation fails with '0' value