What is ConfigMap in Kubernetes?

A ConfigMap is a Kubernetes API object used to store non-confidential data in key-value pairs. It allows you to decouple configuration artifacts from image content to keep containerized applications portable.

What is a Kubernetes ConfigMap?

In Kubernetes, a ConfigMap provides a mechanism to inject configuration data into pods. It's designed to hold configuration data separately from the application code, making it easier to manage and update configurations without rebuilding Docker images or redeploying the application.

This separation enhances the portability and reusability of container images, as the same image can be used in different environments (development, staging, production) simply by providing different ConfigMaps.

How ConfigMaps Work

A ConfigMap stores configuration data as key-value pairs. These key-value pairs can then be consumed by pods in several ways:

• As environment variables inside a container.
• As command-line arguments to the entrypoint of a container.
• As files in a volume mounted inside a container.

ConfigMaps are namespace-scoped resources, meaning they exist within a specific Kubernetes namespace and can only be accessed by pods in that same namespace.

Creating a ConfigMap

ConfigMaps can be created using kubectl from literal values, files, or directories, or by defining them directly in a YAML manifest.

From literal values

kubectl create configmap my-app-config --from-literal=config.name=MyApp --from-literal=config.version=1.0

From files

Assuming you have a file named app-settings.properties:

api.url=http://api.example.com
database.host=db.example.com
logging.level=INFO

kubectl create configmap my-app-config --from-file=app-settings.properties

Using a YAML manifest

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-config-yaml
data:
  api.url: "http://api.example.com"
  database.host: "db.example.com"
  logging.level: "INFO"
  custom.message: "Hello from ConfigMap!"

Consuming a ConfigMap

As Environment Variables

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:latest
        env:
        - name: API_URL
          valueFrom:
            configMapKeyRef:
              name: my-app-config
              key: api.url
        envFrom:
        - configMapRef:
            name: my-app-config-yaml # Exposes all keys as environment variables

As Mounted Volumes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:latest
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
      - name: config-volume
        configMap:
          name: my-app-config-yaml
          # You can also specify specific keys to project as files:
          # items:
          # - key: api.url
          #   path: application.properties
          # - key: custom.message
          #   path: welcome.txt

When mounted as a volume, each key in the ConfigMap becomes a file in the specified mount path, with the file name being the key and its content being the value.

Key Use Cases

• Environment-Specific Configuration: Storing different configurations for development, staging, and production environments (e.g., database connection strings, external service URLs).
• Application Settings: Providing application-wide settings such as logging levels, feature flags, or API keys (though sensitive data should use Secrets).
• Custom Configuration Files: Injecting full configuration files (e.g., Nginx configuration, Java properties files, shell scripts) into a container's filesystem.

Security Considerations

It's crucial to remember that ConfigMaps are *not* designed for sensitive data. Their content is stored unencrypted in the etcd data store and can be easily viewed by anyone with API access. For sensitive information like passwords, API tokens, or private keys, Kubernetes Secrets should be used instead.