ConfigMaps in Kubernetes

Hey there, Kubernetes newbie! So, you’ve stumbled across ConfigMaps, and you’re probably wondering, “What’s this all about?” Don’t sweat it—I’m here to break it down like I’m explaining it over a cup of chai. 😊 ConfigMaps are like the settings screen in your favorite app, letting you tweak things without rewriting the whole program. In this blog, we’ll explore ConfigMaps using example of Swiggy, the go-to food ordering app in India, to make it super relatable. By the end, you’ll be ready to manage configurations like a pro. Let’s jump in!

What Are ConfigMaps? A Dead-Simple Explanation#

Imagine you’re using the Swiggy app to order a paneer tikka pizza. The app needs to know stuff like the database URL to store your order or the maximum delivery distance (say, 8 km in Mumbai). If Swiggy’s developers hardcoded these settings into the app’s code, they’d have to rebuild the entire app just to change the delivery distance to 10 km. That’s a nightmare! 😫

Here’s where ConfigMaps come in. They’re Kubernetes objects that store configuration data—like settings or files—separately from your app’s code. You can then feed this data to your app’s containers at runtime, making it easy to update settings without touching the code. Think of a ConfigMap as the “Edit Profile” page in Swiggy, where you can change your address without rewriting the app.

Why to use ConfigMaps#

• No Hardcoding: Keep settings out of your code for cleaner apps.
• Easy Updates: Change a setting without redeploying your app.
• Flexibility: Store simple values (like “8 km”) or entire config files.

When I first started with Kubernetes, I thought hardcoding was fine. Then I had to redeploy an app at midnight to fix a URL. Trust me, ConfigMaps saved my sanity! 😅 Let’s see how they work.

Creating a ConfigMap: Two Beginner-Friendly Ways#

You can create a ConfigMap in two ways: using a YAML file (like writing a detailed note) or the kubectl command (like a quick text).

Option 1: Creating a ConfigMap with YAML#

Let’s create a ConfigMap for Swiggy to store settings like the database URL and delivery distance. Here’s the YAML file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: swiggy-config
  namespace: default
data:
  database_url: "mysql://db.swiggy.com:3306/orders"
  delivery_distance_km: "8"
  max_items_per_order: "10"

YAML file breakdown#

• data: This is where you list your settings, like:
  • database_url: The database Swiggy uses to save orders.
  • delivery_distance_km: How far Swiggy delivers in km.
  • max_items_per_order: The max items you can order (because 10 biryanis might be enough!).

Save this as swiggy-config.yaml and run:

kubectl apply -f swiggy-config.yaml

Output:

configmap/swiggy-config created

Congrats! You’ve created a ConfigMap. You can check it with:

kubectl get configmap swiggy-config -o yaml

Option 2: Creating a ConfigMap with kubectl#

Not into YAML? You can create a ConfigMap with a single kubectl command. Let’s say Swiggy needs a config for its notification system.

kubectl create configmap swiggy-notifications \\
  --from-literal=notification_url="<https://notify.swiggy.com>" \\
  --from-literal=max_retries="3"

What’s Going On?#

• kubectl create configmap swiggy-notifications: Creates a ConfigMap named swiggy-notifications.
• -from-literal: Adds settings directly, like the notification URL and retry limit.

Output:

configmap/swiggy-notifications created

Check it with:

kubectl describe configmap swiggy-notifications

Output (shortened):

Name:         swiggy-notifications
Namespace:    default
Data
====
notification_url:  <https://notify.swiggy.com>
max_retries:      3

YAML or kubectl? Use YAML for complex configs or when you want to save them in Git. Use kubectl for quick, one-time setups. Both are beginner-friendly!

Using ConfigMaps in a Deployment#

You’ve got your ConfigMap—now let’s use it in a Deployment, which is what most devs use. Deployments manage multiple copies of your app, keeping them running and scalable. We’ll show two ways to feed ConfigMap data to a Swiggy Deployment: as environment variables (like app settings) and as a volume (like a config file).

Example 1: ConfigMap as Environment Variables#

Let’s say Swiggy’s Deployment needs the database URL and delivery distance as environment variables. Here’s the YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: swiggy-deployment
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: swiggy
  template:
    metadata:
      labels:
        app: swiggy
    spec:
      containers:
      - name: swiggy-app
        image: swiggy:latest
        env:
        - name: DATABASE_URL
          valueFrom:
            configMapKeyRef:
              name: swiggy-config
              key: database_url
        - name: DELIVERY_DISTANCE
          valueFrom:
            configMapKeyRef:
              name: swiggy-config
              key: delivery_distance_km

Deployment YAML Explained#

This YAML might look like a lot, but think of it as a recipe for your app. Here’s what each part does:

• apiVersion: apps/v1: Uses the Deployment rulebook.
• kind: Deployment: Says, “I’m creating a Deployment.”
• metadata: Names the Deployment.
  • name: swiggy-deployment: The Deployment’s name.
  • namespace: default: Keeps it in the default folder.
• spec: The plan for your Deployment.
  • replicas: 3: Runs 3 copies of your app for reliability.
  • selector: Links the Deployment to its pods using the app: swiggy label.
  • template: Describes the pods the Deployment creates.
    • metadata.labels: Labels pods with app: swiggy.
    • spec.containers: Defines the app’s container.
      • name: swiggy-app: Names the container.
      • image: swiggy:latest: The Docker image for Swiggy.
      • env: Adds environment variables from the ConfigMap.
        • name: DATABASE_URL: The variable name your app uses.
        • valueFrom.configMapKeyRef: Grabs the value from the ConfigMap.
          • name: swiggy-config: Points to our ConfigMap.
          • key: database_url: Uses the database_url value.

Apply it with:

kubectl apply -f swiggy-deployment.yaml

Output:

deployment.apps/swiggy-deployment created

Now, Swiggy’s app can use DATABASE_URL and DELIVERY_DISTANCE as environment variables. If Swiggy expands delivery to 10 km in Bengaluru, update the ConfigMap, and the Deployment picks it up without a redeploy. Magic! ✨

Real-World Scenario: Swiggy’s Mumbai team increases the delivery distance to 10 km during a festive season. Update the ConfigMap, and all pods in the Deployment get the new setting. Your users keep ordering dosas, and you’re the hero.

Example 2: ConfigMap as a Volume#

What if Swiggy needs a config file, like app.properties, instead of environment variables? You can mount a ConfigMap as a volume. Here’s a ConfigMap with a file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: swiggy-app-config
  namespace: default
data:
  app.properties: |
    database.url=mysql://db.swiggy.com:3306/orders
    max.items.per.order=10

Volume ConfigMap Explained#

• data.app.properties: This creates a file called app.properties with the settings, like a text file with key-value pairs.

Apply it:

kubectl apply -f swiggy-app-config.yaml

Now, use it in a Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: swiggy-file-deployment
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: swiggy-file
  template:
    metadata:
      labels:
        app: swiggy-file
    spec:
      containers:
      - name: swiggy-app
        image: swiggy:latest
        volumeMounts:
        - name: config-volume
          mountPath: "/etc/config"
      volumes:
      - name: config-volume
        configMap:
          name: swiggy-app-config

Volume Deployment Explained#

• spec.template.spec.volumes: Creates a volume named config-volume that uses the swiggy-app-config ConfigMap.
• spec.template.spec.containers.volumeMounts: Attaches the volume at /etc/config, so app.properties appears as a file in the container.

Apply it, and your container gets /etc/config/app.properties with the ConfigMap’s contents. Swiggy’s app can read it like any file.

Real-World Scenario:Let's say Swiggy’s backend team uses app.properties for database settings. If the database moves to a new server, update the ConfigMap, and the file updates across all pods. No downtime, just happy customers ordering butter chicken.

Avoiding Beginner Traps#

You might mess up the first time, and that’s okay! Here are common mistakes and how to dodge them:

• Typo in Keys: If your Deployment looks for database_url but the ConfigMap has db_url, it won’t work. Check your configMapKeyRef keys.
• Wrong Namespace: ConfigMaps and Deployments must be in the same namespace (e.g., default). Mismatched namespaces = no connection.
• Forgetting to Save: Always run kubectl apply after editing YAMLs.

Pro Tip: Run kubectl describe deployment swiggy-deployment to see if your ConfigMap data is linked correctly.

Example 3: Fixing a ConfigMap Mix-Up#

Suppose Swiggy’s Deployment isn’t getting the max_items_per_order value. Check the ConfigMap:

kubectl describe configmap swiggy-config

Output (shortened):

Name:         swiggy-config
Namespace:    default
Data
====
database_url:        mysql://db.swiggy.com:3306/orders
delivery_distance_km: 8
max_items_per_order: 10

All good! Now check a pod’s environment:

kubectl exec -it $(kubectl get pod -l app=swiggy -o name | head -n 1) -- env

If MAX_ITEMS_PER_ORDER is missing, you might’ve used the wrong key in the YAML. Fix it, reapply, and you’re back on track.

ConfigMaps vs Secrets: A Quick Note#

ConfigMaps are great for non-sensitive data like delivery distances or item limits. But don’t store sensitive stuff like passwords or API keys in them—they’re not encrypted by default, so anyone with cluster access can peek. For sensitive data, use Secrets (we’ll dive into those next!).

Real-World Scenario: Let's say Swiggy uses a ConfigMap for the delivery distance and max items but stores the database password in a Secret. This keeps orders flowing and data secure.

Conclusion#

In this blog, you learned all about ConfigMaps, the Kubernetes tool for managing app settings like a champ. We covered what ConfigMaps are, how to create them with YAML and kubectl, and how to use them in Deployments as environment variables or volumes, with clear examples from Swiggy. You also picked up tips to avoid beginner mistakes, all explained in a way that’s easy to grasp.

What’s Next? In the next blog, we’ll explore Secrets, the secure way to handle sensitive data like passwords and API keys. You’ll learn how to keep Swiggy’s data safe while keeping the app running smoothly.