Hardcoding configuration values — database hostnames, API endpoints, feature flags — directly into container images is an anti-pattern that makes images environment-specific: the same image cannot be deployed to development and production without rebuilding. Kubernetes solves this with two purpose-built objects: ConfigMaps store non-sensitive configuration data (environment variables, config files, command-line arguments) as key-value pairs that are injected into Pods at runtime. Secrets store sensitive data (passwords, API keys, TLS certificates) with base64 encoding and restricted access controls. Together, they implement the twelve-factor app principle of strict separation between configuration and code — the same container image runs everywhere; only the injected configuration differs by environment.
30 minintermediate
ConfigMaps and Secrets
Analogy🏏Cricket
🏏 Think of it like cricket: A well-run cricket board has distinct departments with clear responsibilities: the selection committee chooses players, the grounds department prepares venues, the scheduling department assigns matches to grounds, the operations department manages logistics, and the referees enforce the rules. No department does another's job, and all communication flows through the central secretariat. Just as the ICC's effectiveness comes from each department having a clear mandate and working through a central coordination system, Kubernetes' reliability comes from each component (API server, scheduler, controller manager, etcd, kubelet, kube-proxy) having a single responsibility and communicating only through the API server as the central hub. The insight is that this architecture makes the system resilient: a failure in the scheduling department doesn't stop ongoing matches, just as a failing scheduler doesn't kill running Pods.
Lesson 13 of 24
0% complete