ConfigMap

A ConfigMap stores configuration data as simple key-value pairs. This data is entirely non-confidential (unlike a Secret). The keys must consist of alphanumeric characters, '-', '_', or '.'. Values can be arbitrary strings or structured text like JSON snippets.

• Example: database.host: "prod-db.internal"
• Use Case: Storing environment-specific variables like feature flags, external service endpoints, or UI configuration strings.

Pods can consume ConfigMap data through several mechanisms, providing flexibility for different application needs:

• Environment Variables: Inject individual keys or the entire ConfigMap as environment variables into a container.
• Configuration Files: Mount the ConfigMap as a read-only volume, where each key becomes a file and its value becomes the file's content. This is ideal for applications expecting config files (e.g., nginx.conf).
• Command-Line Arguments: Use ConfigMap data to populate a container's command arguments.

Changes to a mounted ConfigMap volume are eventually propagated to the running pods, though the update latency depends on the kubelet's sync period.

ConfigMaps can be marked as immutable. When immutable: true is set in the ConfigMap spec, its data cannot be updated after creation.

Benefits:

• Security: Prevents accidental or malicious runtime modifications that could affect application behavior.
• Performance: Significantly reduces load on the kube-apiserver as it stops watching for changes on these objects.
• Predictability: Ensures the configuration for a given pod revision is static, which is critical for canary deployments and rollback scenarios. To update an immutable ConfigMap, you must delete and recreate it, which typically requires a new pod deployment.

ConfigMaps are namespaced objects. They exist within a specific Kubernetes namespace and are only accessible to pods residing in that same namespace. This provides natural isolation for configuration between different environments (e.g., dev, staging, prod) or teams sharing a cluster.

Operational Implications:

• A pod can only reference a ConfigMap in its own namespace.
• Role-Based Access Control (RBAC) policies can be applied at the namespace level to control who can read or modify ConfigMaps.
• For configuration needed cluster-wide (e.g., a corporate CA certificate), the ConfigMap must be created in each namespace or alternative methods like a DaemonSet with a hostPath volume might be considered.

The primary architectural benefit of a ConfigMap is the separation of configuration from application code. This adheres to the Twelve-Factor App methodology.

Consequences:

• The same container image can be promoted through different environments (dev, prod) by binding it to environment-specific ConfigMaps.
• Configuration changes do not require rebuilding and repushing the container image, enabling faster and safer deployments.
• Configuration can be managed via the same GitOps workflows (e.g., using ArgoCD or Flux) as other Kubernetes manifests, providing versioning, audit trails, and rollback capabilities.

Understanding ConfigMap constraints is vital for production design:

• Size Limit: Individual ConfigMaps have a practical size limit of ~1 MiB. Larger configurations should be split or stored in a PersistentVolume.
• No Encryption: Data is stored as plaintext (base64 encoding is not encryption). Use a Secret for confidential data, though note Secrets are also base64-encoded by default.
• Update Propagation Delay: For ConfigMaps mounted as volumes, updates can take up to the kubelet's sync period (default 1 minute) plus cache propagation delay to reach the pod.
• Pod Dependency: A pod must be able to start even if its referenced ConfigMap is missing or invalid, or it will fail creation. Using optional references can mitigate this.

A single ConfigMap can be mounted into multiple pods across different deployments, providing a centralized source for common configuration. This is useful for microservices architectures where several services need the same baseline settings.

• Consistency: Ensures all related services use identical values for shared resources (e.g., the address of a central caching service like Redis).
• Centralized Management: A change to the shared ConfigMap can propagate to all consuming pods, though careful orchestration is required to manage rolling updates and avoid breaking changes.

A fundamental operating system mechanism for passing configuration to processes. In Kubernetes, ConfigMap and Secret data can be injected into a container's runtime environment.

• Direct Injection: ConfigMap key-value pairs can be set as container environment variables using env or envFrom fields in the pod spec.
• Dynamic vs. Static: Environment variables are set at pod startup. Changing a ConfigMap does not update environment variables in already-running pods; the pod must be restarted.
• Use Case: Setting agent parameters like model temperature, API endpoint URLs, or feature flags.

The method by which a ConfigMap (or Secret) is made available to a pod as a set of files within its filesystem. This is the primary alternative to using environment variables.

• Mechanism: The ConfigMap is mounted as a read-only volume. Each key becomes a filename, and its value becomes the file's content.
• Dynamic Updates: When a mounted ConfigMap is updated, Kubelet periodically synchronizes the updated files. Applications must watch the files for changes or restart to pick up new configuration.
• Use Case: Providing large configuration files (e.g., Prometheus scrape configs, logging profiles) to an observability sidecar container.