A five-minute read — no prior Kubernetes experience needed.
Why I am Writing This
Because I am learning DevOps and cloud infrastructure step by step, and I want to document each small win along the way, both to remember it myself and to help other beginners who are exactly where I was a few weeks ago.
Today's lab: creating something called a ConfigMap in Kubernetes. It is actually a simple, useful idea once you break it down.
First, What Is Kubernetes?
If you are brand new to this: Kubernetes is a tool that helps run applications inside small, self-contained packages called containers. Think of a container like a lunchbox; it holds everything an app needs to run (code, tools, settings) so it works the same way no matter where you open it.
Kubernetes manages lots of these lunchboxes at once, starting them, stopping them, replacing broken ones, and so on.
The Problem I Was Solving
Apps usually need small settings to run properly — things like:
Which "port" (a kind of digital doorway) the app should listen on.
Whether "debug mode" (extra troubleshooting messages) should be on or off.
The problem? Every time you want to change a setting, you have to rewrite and rebuild the whole app. That is slow and unnecessary.
The better way: keep your settings in a separate, small file completely apart from your app's code. In Kubernetes, that separate file is called a ConfigMap.
Setting Up My Environment (Azure)
I did this lab inside Azure Cloud Shell, A terminal that runs right in the browser, already connected to my Azure account. Before running any commands, Cloud Shell confirmed which account and subscription I was using. Once that was confirmed, I created a resource group.
bash
az group create --name rg-devops-lab --location eastus
rg-devops-lab — the name I chose for my project folder.
eastus — the physical data center region in the US where my resources live.
Creating the ConfigMap File
Next, I created a small text file describing my settings. Instead of opening a text editor, I typed the file directly into the terminal using a shortcut called a heredoc — it just means "everything I type until I type EOF becomes the file":
apiVersion: v1
kind: ConfigMap
metadata:
name: app-settings
data:
PORT: "8080"
DEBUG: "false"
Then I printed it back out to double-check it saved correctly:
bash
cat app-config.yaml
Breaking Down What I Just Wrote (Line by Line)
This file is written in YAML — a simple, readable way to organize information using indentation (spacing), rather than symbols like { } or < >.
apiVersion: v1 — tells Kubernetes which "rulebook version" to follow. You don't need to worry about this much as a beginner.
kind: ConfigMap — tells Kubernetes what type of thing this file describes. In this case: a settings file.
metadata: / name: app-settings — gives this ConfigMap a name, so other parts of Kubernetes can refer to it later.
data: — this is the actual content. Underneath it, I listed my two settings:
PORT: "8080" — the doorway number my app should use.
DEBUG: "false" — troubleshooting messages are turned off.
Think about a mobile game you play. The game itself — how it looks, how it plays — is built once by the developers. But you probably have settings you can change: sound on/off, difficulty, language.
Those settings live separately from the actual game code. If developers want to change a default setting for everyone, they do not rebuild the whole game; they just update a small settings file.
That is basically what I did in this lab. I created a small file that says:
"Run this on port 8080" (like picking which channel a broadcast plays on)
"Debug mode: off" (do not show extra behind-the-scenes info)
That settings file is separate from the app itself, so changing it later is quick and doesn't require rebuilding anything.
Why This Actually Matters
This might look like a tiny exercise, but it teaches a big idea used everywhere in software: keep your settings separate from your code.
Once I understood this, a lot of other things started clicking too — like why companies can run the exact same app in "testing" and "production" versions just by swapping out a settings file, without touching a single line of code.
My Takeaway as a Beginner
A few weeks ago, terms like "ConfigMap" and "YAML" felt like a wall of jargon. Breaking this down slowly, line by line, with real analogies made it click. If you are a beginner reading this, you don't need to understand everything at once. Just understand one small piece really well, and the next piece gets easier.
This post is part of my hands-on journey learning DevOps, Kubernetes, and Azure. Documenting labs as I go.
Top comments (0)