Kubernetes - ConfigMaps

A ConfigMap is a Kubernetes object used to store non-sensitive configuration data as key-value pairs. It separates application configuration from container images, allowing the same application to run with different settings across environments.

• Stores configuration such as application modes, log levels, and service URLs.
• Makes configuration available to containers through environment variables, command-line arguments, or mounted files.
• Helps manage application settings without rebuilding container images.
• Uses Kubernetes Secrets instead of ConfigMaps for sensitive information such as passwords and tokens.

Working

A ConfigMap stores configuration data in the Kubernetes API. Pods can reference this data and make it available to their containers in different ways.

• Kubernetes stores ConfigMap data in the cluster's backing data store, etcd.
• A Pod can reference a ConfigMap through its specification.
• Containers can consume the configuration as environment variables, command-line arguments, or mounted files.
• A ConfigMap must be available in the same namespace as the Pod that references it.

Ways to Use ConfigMaps

Kubernetes supports different methods for making ConfigMap data available to an application. The appropriate method depends on how the application reads its configuration.

Using Environment Variables

ConfigMap values can be exposed as environment variables inside a container. Applications can read these variables during startup or runtime, depending on their implementation.

• Suitable for individual configuration values such as application modes and log levels.
• Can expose selected keys or multiple values from a ConfigMap.
• Changes to the ConfigMap do not automatically update environment variables in running containers.
• Pods generally need to be recreated to receive updated environment variable values.

Using Mounted Volumes

A ConfigMap can be mounted as a volume inside a container. Its keys are exposed as files that an application can read.

• Suitable for configuration files and applications that read settings from files.
• Each key is generally represented as a file in the mounted directory.
• Updates to mounted ConfigMaps are eventually reflected in the volume.
• Applications may need to reload the configuration to apply changes. Mounts using subPath do not receive automatic updates.

Using Command-Line Arguments

ConfigMap values can be passed as command-line arguments when a container starts, often through environment variable references.

• Useful when applications accept configuration through startup arguments.
• Keeps configuration values separate from the container image.
• Changes to arguments generally require the container or Pod to be recreated.

Viewing ConfigMaps

The kubectl command-line tool can be used to list and inspect ConfigMaps in a Kubernetes cluster.

kubectl get configmaps

This command lists ConfigMaps in the current namespace.

kubectl describe configmap <configmap-name>

This command displays details about a specific ConfigMap, including its metadata and stored keys.

kubectl get configmap <configmap-name> -o yaml

This command displays the ConfigMap in YAML format, including its configuration data.

Updating ConfigMaps

ConfigMaps can be updated when application settings change. The update method depends on how the ConfigMap is managed.

• Use kubectl apply -f <file-name> to apply changes from a configuration file.
• Use kubectl edit configmap <configmap-name> to modify an existing ConfigMap interactively.
• Environment variables in existing containers do not automatically reflect updated ConfigMap values.
• Mounted ConfigMap volumes can receive updates eventually, but the application may need to reload the configuration.
• Restart or recreate Pods when the application cannot apply the updated configuration on its own.

Immutable ConfigMaps

An immutable ConfigMap cannot be modified after it is created. This feature helps prevent accidental changes to configuration data.

• Useful for configuration that should remain unchanged during an application's lifetime.
• Helps reduce unintended configuration changes.
• To change its data, create a new ConfigMap and update the workloads that reference it.
• The immutable field is set to true in the ConfigMap specification.

ConfigMap Limitations

ConfigMaps are designed for small, non-sensitive configuration data rather than large files or confidential information.

• A ConfigMap is limited to 1 MiB of data.
• ConfigMaps are not intended for passwords, access tokens, or other sensitive values.
• Updating a ConfigMap does not guarantee that an application immediately applies the changes.
• Access to ConfigMaps is controlled through Kubernetes permissions, including Role-Based Access Control (RBAC).

ConfigMaps vs Secrets

ConfigMaps and Secrets both store configuration data, but they serve different purposes.

Note: Base64 encoding does not provide encryption. Sensitive data should be protected using appropriate access controls and encryption settings.

Best Practices

Follow these practices to manage application configuration effectively in Kubernetes.

• Store only non-sensitive configuration data in ConfigMaps.
• Use descriptive names that indicate the purpose of the configuration.
• Keep configuration data small and avoid storing unnecessary files.
• Use immutable ConfigMaps when configuration should not change.
• Version configuration changes when predictable rollouts and rollbacks are important.
• Apply appropriate RBAC permissions to restrict access.
• Verify how the application handles configuration updates before changing a ConfigMap used by running Pods.