Kubernetes ConfigMap Variable Substitution

Kubernetes is a powerful container orchestration platform that simplifies the deployment, scaling, and management of containerized applications. One of the key challenges in managing applications on Kubernetes is handling configuration data. ConfigMaps in Kubernetes provide a way to decouple configuration artifacts from container images, making it easier to manage and update configurations. ConfigMap variable substitution is a technique that allows you to inject configuration data from ConfigMaps into your application pods. This enables your applications to be more flexible and portable, as they can consume different configurations based on the environment they are deployed in. In this blog post, we will explore the core concepts, typical usage examples, common practices, and best practices related to Kubernetes ConfigMap variable substitution.

Table of Contents

  1. Core Concepts
    • ConfigMaps
    • Variable Substitution
  2. Typical Usage Example
    • Creating a ConfigMap
    • Using ConfigMap in a Pod
    • Variable Substitution in a Container
  3. Common Practices
    • Mounting ConfigMaps as Volumes
    • Setting Environment Variables from ConfigMaps
  4. Best Practices
    • Keeping Configurations Separate
    • Using Multiple ConfigMaps
    • Versioning ConfigMaps
  5. Conclusion
  6. References

Core Concepts

ConfigMaps

A ConfigMap is an API object used to store non-confidential data in key - value pairs. ConfigMaps allow you to decouple environment - specific configuration from your container images, so that your applications are more portable. You can create ConfigMaps from literal values, files, or directories.

# Create a ConfigMap from literal values
kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2

Variable Substitution

Variable substitution is the process of replacing placeholders in your application’s configuration files or environment variables with the actual values stored in a ConfigMap. This can be done in various ways, such as mounting the ConfigMap as a volume or setting environment variables based on the ConfigMap data.

Typical Usage Example

Creating a ConfigMap

Let’s start by creating a ConfigMap that contains some configuration data. Suppose we have an application that needs a database connection string and a logging level.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  db_connection: "mysql://user:password@dbhost:3306/mydb"
  log_level: "debug"

Save the above YAML in a file named app-config.yaml and create the ConfigMap using the following command:

kubectl apply -f app-config.yaml

Using ConfigMap in a Pod

Now, let’s create a pod that uses the ConfigMap. We will mount the ConfigMap as a volume and set environment variables based on the ConfigMap data.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
    - name: my-app-container
      image: my-app-image
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      env:
        - name: DB_CONNECTION
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: db_connection
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: log_level
  volumes:
    - name: config-volume
      configMap:
        name: app-config

Save the above YAML in a file named my-app-pod.yaml and create the pod using the following command:

kubectl apply -f my-app-pod.yaml

Variable Substitution in a Container

Inside the container, the application can access the configuration data in two ways:

  • Environment Variables: The DB_CONNECTION and LOG_LEVEL environment variables are set based on the ConfigMap data. The application can read these environment variables to get the configuration values.
  • Mounted Volume: The ConfigMap data is mounted as a volume at /etc/config. The application can read the configuration files from this directory.

Common Practices

Mounting ConfigMaps as Volumes

Mounting ConfigMaps as volumes is a common way to provide configuration files to your containers. When you mount a ConfigMap as a volume, each key in the ConfigMap becomes a file in the mount path, and the value of the key becomes the content of the file.

spec:
  containers:
    - name: my-container
      image: my-image
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: my-config

Setting Environment Variables from ConfigMaps

Setting environment variables from ConfigMaps is another common practice. This allows your application to access the configuration data as environment variables, which is a common way for applications to consume configuration.

spec:
  containers:
    - name: my-container
      image: my-image
      env:
        - name: MY_CONFIG_KEY
          valueFrom:
            configMapKeyRef:
              name: my-config
              key: my-key

Best Practices

Keeping Configurations Separate

It is a good practice to keep different types of configurations in separate ConfigMaps. For example, you can have one ConfigMap for database configurations, another for logging configurations, and so on. This makes it easier to manage and update the configurations.

Using Multiple ConfigMaps

You can use multiple ConfigMaps in a single pod. This allows you to combine different sets of configuration data.

spec:
  containers:
    - name: my-container
      image: my-image
      volumeMounts:
        - name: db-config-volume
          mountPath: /etc/db-config
        - name: log-config-volume
          mountPath: /etc/log-config
      envFrom:
        - configMapRef:
            name: db-config
        - configMapRef:
            name: log-config
  volumes:
    - name: db-config-volume
      configMap:
        name: db-config
    - name: log-config-volume
      configMap:
        name: log-config

Versioning ConfigMaps

Just like code, ConfigMaps should be versioned. You can use a version control system like Git to manage your ConfigMap YAML files. This allows you to track changes, roll back to previous versions, and collaborate with other developers.

Conclusion

Kubernetes ConfigMap variable substitution is a powerful technique that allows you to manage and inject configuration data into your applications in a flexible and portable way. By understanding the core concepts, using typical usage examples, following common practices, and adopting best practices, you can effectively use ConfigMaps to manage the configuration of your Kubernetes applications. This not only simplifies the deployment process but also makes your applications more adaptable to different environments.

References