Creating ConfigMaps from literals in Kubernetes - Visual Walkthrough

Process Flow - Creating ConfigMaps from literals

Start

↓

Run kubectl create configmap with --from-literal

↓

kubectl parses literals

↓

ConfigMap object created in memory

↓

ConfigMap stored in Kubernetes cluster

↓

ConfigMap ready to be used by pods

↓

End

This flow shows how a ConfigMap is created from literal key-value pairs using kubectl, stored in the cluster, and made available for pods.

Execution Sample

Kubernetes

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

Creates a ConfigMap named 'my-config' with two keys and their literal values.

Process Table

Step	Action	Input/Command	Result
1	Start command	kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2	Command accepted by kubectl
2	Parse literals	--from-literal=key1=value1, --from-literal=key2=value2	Parsed key1=value1 and key2=value2
3	Create ConfigMap object	Keys and values parsed	ConfigMap object with data {key1: value1, key2: value2} created in memory
4	Send to Kubernetes API	ConfigMap object	ConfigMap stored in cluster
5	Confirm creation	kubectl output	configmap/my-config created
6	End	N/A	ConfigMap 'my-config' ready for use

💡 ConfigMap creation completes successfully and is stored in the cluster.

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
Command Input	N/A	kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2	N/A	N/A
Parsed Literals	Empty	{key1: value1, key2: value2}	{key1: value1, key2: value2}	{key1: value1, key2: value2}
ConfigMap Object	None	None	Created with data	Stored in cluster

Key Moments - 3 Insights

Why do we use --from-literal instead of a file?

Using --from-literal lets you quickly create ConfigMaps with small key-value pairs directly from the command line, as shown in step 2 of the execution_table.

What happens if you repeat the same key with different values?

kubectl will use the last value provided for that key when creating the ConfigMap object, as the parsed literals overwrite previous keys (see step 3).

How do we know the ConfigMap was created successfully?

kubectl outputs 'configmap/my-config created' at step 5, confirming the ConfigMap is stored and ready.

Visual Quiz - 3 Questions

Look at the execution_table, what is the result after parsing literals at step 2?

A Parsed key1=value1 and key2=value2

B ConfigMap stored in cluster

C Command accepted by kubectl

D ConfigMap object created in memory

💡 Hint

Check the 'Result' column at step 2 in the execution_table.

At which step does the ConfigMap object get created in memory?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Action' column for when the ConfigMap object is created.

If you add another --from-literal=key1=newvalue, what changes in the variable_tracker?

A ConfigMap Object will be deleted

B Command Input will be empty

C Parsed Literals will have key1 with value 'newvalue' replacing 'value1'

D No change in Parsed Literals

💡 Hint

Refer to the 'Parsed Literals' row in variable_tracker and how keys overwrite previous values.

Concept Snapshot

kubectl create configmap <name> --from-literal=key=value [--from-literal=key2=value2 ...]
Creates a ConfigMap with literal key-value pairs.
Each --from-literal adds one key and value.
ConfigMap is stored in the cluster and can be used by pods.
Use this for quick small configs without files.

Full Transcript

This visual execution shows how to create a Kubernetes ConfigMap from literal key-value pairs using the kubectl command. The process starts by running the command with --from-literal flags. Kubectl parses these literals into key-value pairs, then creates a ConfigMap object in memory with this data. The object is sent to the Kubernetes API server and stored in the cluster. Kubectl confirms creation by outputting a success message. The ConfigMap is then ready to be used by pods. Key points include understanding that literals are parsed and stored as keys and values, and that repeated keys overwrite previous values. This method is useful for quick configuration without needing files.

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