Kubernetes ConfigMap Variable Substitution
Table of Contents
- Core Concepts
- ConfigMaps
- Variable Substitution
- Typical Usage Example
- Creating a ConfigMap
- Using ConfigMap in a Pod
- Variable Substitution in a Container
- Common Practices
- Mounting ConfigMaps as Volumes
- Setting Environment Variables from ConfigMaps
- Best Practices
- Keeping Configurations Separate
- Using Multiple ConfigMaps
- Versioning ConfigMaps
- Conclusion
- 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_CONNECTIONandLOG_LEVELenvironment 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
- Kubernetes Documentation: https://kubernetes.io/docs/concepts/configuration/configmap/
- Kubernetes Best Practices: https://www.cncf.io/blog/2020/08/18/kubernetes-best-practices-configuring-application-configurations/