Skip to main content

ConfigMaps

Optional ConfigMaps in Kubernetes

There are scenarios where you might want to make certain configurations optional.

This is where the concept of Optional ConfigMaps comes into play.

Let's look at this feature and its practical applications.

What are Optional ConfigMaps?

Optional ConfigMaps in Kubernetes allow you to specify that a particular ConfigMap is not required for your application to run.

If the ConfigMap doesn't exist, Kubernetes will still start your pod without it, instead of failing the pod creation.

To make a ConfigMap optional, you can use the optional: true field in your pod specification under configMapRef

Here is an example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: webserver
    image: nginx
    envFrom:
    - configMapRef:
        name: my-optional-config
        optional: true

In this example, if the ConfigMap my-optional-config doesn't exist, the pod will still start normally.

Real World Use Case

Optional ConfigMaps can be used for handling environment-specific settings.

This approach allows you to maintain a base configuration that's common across all environments, while providing the flexibility to override or add settings for specific environments.

For example:

envFrom:
- configMapRef:
    name: common-config
- configMapRef:
    name: prod-specific-config
    optional: true
- configMapRef:
    name: dev-specific-config
    optional: true

This setup allows you to have a common configuration and optional environment-specific overrides.

prod-specific-config and dev-specific-config: These ConfigMaps are marked as optional and contain environment-specific overrides or additional settings.

Here is an example prod-specific-config and dev-specific-config configmaps.

apiVersion: v1
kind: ConfigMap
metadata:
  name: prod-specific-config
data:
  LOG_LEVEL: "warn"
  ENABLE_CACHING: "true"
  CDN_URL: "https://cdn.production.com"

----
apiVersion: v1
kind: ConfigMap
metadata:
  name: dev-specific-config
data:
  LOG_LEVEL: "debug"
  ENABLE_MOCKING: "true"
  API_KEY: "dev-test-key"

In this setup:

  • The common-config ConfigMap will always be applied and must exist in the cluster.
  • If the Pod is deployed in a production environment, the prod-specific-config ConfigMap will be created and applied, overriding the LOG_LEVEL from "info" to "warn" and adding additional production-specific settings.
  • If the Pod is deployed in a development environment, the dev-specific-config ConfigMap will be created and applied instead, changing the LOG_LEVEL to "debug" and adding development-specific settings.
  • If neither the prod-specific-config nor dev-specific-config exists, the Pod will still start using just the common configuration.

This approach allows you to:

  • Maintain a single deployment configuration that works across environments.
  • Easily add or modify environment-specific settings without changing the main application code or deployment specs.
  • Gracefully handle cases where environment-specific configs might not be present (e.g., in a new or temporary environment).