20 ‐ Kubernetes ConfigMap - CloudScope/DevOpsWithCloudScope GitHub Wiki

Kubernetes ConfigMap: Overview

A ConfigMap in Kubernetes is an API object that allows you to store and manage configuration data in key-value pairs, which can then be consumed by Pods and other resources within a Kubernetes cluster. ConfigMaps help decouple configuration from application code, making applications easier to configure and manage without needing to modify their container images.

Key Concepts

Decoupling Configuration from Code: Instead of embedding configuration details (such as database credentials, service URLs, or feature flags) inside the application code or container images, you store them in a ConfigMap.
Dynamic Configuration: ConfigMaps allow you to update configurations dynamically. When a ConfigMap is updated, Pods that consume it can pick up the new configuration (depending on how they reference it).
Non-Sensitive Data: ConfigMaps are typically used for storing non-sensitive configuration information. For sensitive data (e.g., passwords, API keys), Kubernetes provides Secrets, which offer additional encryption and security features.

When to Use a ConfigMap

To store configuration data that is environment-specific or changes based on deployment.
For managing parameters or settings that need to be shared across multiple Pods or components within the cluster.
When you need to separate application logic from its configuration, enabling more flexible management.
When updating the configuration frequently, without rebuilding the application container images.

Key Features of ConfigMap

Key-Value Pairs: ConfigMaps store configuration data in the form of key-value pairs.
Consumption Methods:
- Environment Variables: You can reference a ConfigMap and use it to populate environment variables in Pods.
- Volume Mounts: ConfigMaps can be mounted as files inside a container, where each key becomes a file and the value is the content of that file.
- Command-Line Arguments: You can pass the values from a ConfigMap as arguments to a container when it starts.
Dynamic Updates: ConfigMaps can be updated while the application is running, though Pods consuming them may need to be reloaded for the changes to take effect (depending on the consumption method).

Creating a ConfigMap

From Literal Values: You can create a ConfigMap directly from key-value pairs using the kubectl command:
```
kubectl create configmap my-config \
  --from-literal=key1=value1 \
  --from-literal=key2=value2
```
From a File: You can create a ConfigMap from a file. Each file's content will be added as a key-value pair:
```
kubectl create configmap my-config --from-file=path/to/config-file
```
From a Directory: You can create a ConfigMap from an entire directory. Each file in the directory will be treated as a key, and the content of the file will be the value:
```
kubectl create configmap my-config --from-file=/path/to/config-dir/
```

From YAML Definition: You can also define a ConfigMap using a YAML file.

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  database_url: "mysql://localhost:3306"
  feature_flag: "enabled"

Apply the YAML to create the ConfigMap:

kubectl apply -f configmap.yaml

Consuming a ConfigMap

ConfigMaps can be consumed by Pods in the following ways:

1. As Environment Variables

You can inject the key-value pairs of a ConfigMap as environment variables inside a Pod's container. This is useful when the application needs to access the configuration values directly through the environment.

Example YAML for consuming a ConfigMap as environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: myapp:latest
    envFrom:
    - configMapRef:
        name: example-configmap

This will make all key-value pairs in the example-configmap available as environment variables in the container.

2. As Volumes

ConfigMaps can be mounted as files inside containers. Each key in the ConfigMap becomes a filename, and the value is the content of the file.

Example YAML for mounting a ConfigMap as a volume:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: myapp:latest
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: example-configmap

In this case, the contents of the example-configmap will be mounted into the /etc/config directory, and each key will become a file within that directory.

3. As Command-Line Arguments

You can reference the values in a ConfigMap and pass them as arguments to the application when the container starts.

Example YAML:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: myapp:latest
    args:
    - "--database-url=$(DATABASE_URL)"
    env:
    - name: DATABASE_URL
      valueFrom:
        configMapKeyRef:
          name: example-configmap
          key: database_url

Updating a ConfigMap

You can update an existing ConfigMap by modifying it directly with the kubectl apply command. When the ConfigMap is updated, you can force the Pods that use it to reload the new configuration.

Example:

kubectl apply -f updated-configmap.yaml

However, config updates are not automatically reflected in running Pods unless the Pods are configured to watch for changes or are restarted. You may need to manually trigger a restart of the Pods, such as by deleting them or using rolling updates.

Limitations

Not Suitable for Sensitive Data: ConfigMaps are not meant for storing sensitive information like passwords or API keys. Use Secrets for sensitive data, as they provide additional security features such as encryption at rest.
Size Limit: Kubernetes imposes size limits on ConfigMaps (typically 1MB). If you need to store larger configurations, you might need to split the data or use other solutions (e.g., a distributed configuration store).
Manual Pod Restarts for Updates: When a ConfigMap is updated, the Pods that use it may need to be manually restarted to pick up the changes, especially if they are consuming it as an environment variable or volume.

Best Practices

Use Separate ConfigMaps for Different Environments: To avoid conflicts between different environments (e.g., development, staging, production), create separate ConfigMaps for each environment with specific configurations.
Versioning: Although Kubernetes does not natively support versioning of ConfigMaps, you can implement versioning by appending version numbers to the keys (e.g., database_url_v1, database_url_v2) or creating separate ConfigMaps for each version.
Keep ConfigMaps Small: Keep the size of ConfigMaps reasonable to avoid issues with large configurations. If a ConfigMap becomes too large, consider splitting it into multiple smaller ones.
Secure Sensitive Information: For sensitive information like passwords, use Kubernetes Secrets instead of ConfigMaps, as they provide better security features.

Example Use Case

For a microservices application, you might have a ConfigMap that stores the database URL, API keys, and feature flags, which can be shared across multiple Pods. Each service can reference this ConfigMap in its Pods to ensure consistency in configuration, and updates to the database URL can be handled dynamically without needing to rebuild the container images.