Kubernetes Configuration & Secrets
ConfigMaps — Externalizing Application Configuration
Mounting configurations as files or environment parameters.
Interview: Interviewers check if you know how to decouple config from images. Be ready to explain how ConfigMaps are created (from files, directories, or literal values), how they are mounted (as env vars or files in a volume), and the 1MB resource size limitation in etcd.
Introduction to ConfigMaps
Hardcoding configuration parameters into container images is an anti-pattern: it forces you to rebuild images when changing trivial settings (like API endpoints or feature flags) across development, staging, and production.
A **ConfigMap** allows you to externalize configuration values, storing them as key-value pairs directly in the cluster registry (etcd). ConfigMaps have a maximum object size limit of **1MB** and are designed for non-sensitive data.
ConfigMap Creation Patterns
You can create ConfigMaps imperatively using the CLI or declaratively using YAML manifests:
Mounting ConfigMaps into Workloads
Kubernetes supports two primary methods for injecting ConfigMaps into containers:
- Environment Variables: Maps ConfigMap keys directly to environment variables inside the container, making them accessible to application startup logic.
- Volume Mounts: Mounts ConfigMap keys as files inside a directory. Each key becomes a filename, and its value becomes the file content.
YAML Manifest Examples
Here is a ConfigMap configuration and a Pod that mounts it as both environment variables and files: