Preface
Kubernetes is one of the most popular container orchestration systems at present, and it provides rich features to support the management and deployment of containerized applications.
ConfigMap is an important resource object in Kubernetes that stores and injects insensitive configuration information into a pod. This article will introduce how to create and use ConfigMap and discuss its precautions.
ConfigMap Background
The operation of an application may rely on some configurations, and these configurations may change with the requirements. If our application architecture is not separated from the application and configuration, then there will be a dilemma in which we need to rebuild the mirror file when we need to modify the properties of certain configuration items.
Now, the ConfigMap component can help us achieve application and configuration separation well, avoiding rebuilding images by modifying configuration items. ConfigMap is a key-value pair used to save configuration data. It can be used to save individual properties or configuration files. ConfigMap is similar to Secret, but it can more easily handle strings that do not contain sensitive information.
How to create ConfigMap
ConfigMap can be created in a variety of ways, including:
- Command line tool kubectl
The kubectl create configmap command can be used to create a ConfigMap from a file or text.
For example, the following command creates a ConfigMap named my-config from a file:
kubectl create configmap my-config --from-file=
- Declarative YAML file
The ConfigMap object can be defined using a declarative YAML file.
For example, the following YAML defines a ConfigMap named my-config:
apiVersion: v1 kind: ConfigMap metadata: name: my-config data: DB_USERNAME: admin DB_PASSWORD: password123
- Configure automatic loading
In Kubernetes, you can use a specific mount point to automatically load ConfigMap as an environment variable or volume.
This can be achieved through Volume and environment variables in the Pod. For example:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
volumeMounts:
- name: config-volume
mountPath: /etc/config
env:
- name: DB_USERNAME
valueFrom:
configMapKeyRef:
name: my-config
key: DB_USERNAME
volumes:
- name: config-volume
configMap:
name: my-config
Use of ConfigMap
In Kubernetes, there are three main ways to inject ConfigMap into a Pod.
- Define as environment variables
In a Pod, ConfigMap data can be injected into the container's environment variables. Suppose a ConfigMap named my-config has been created, containing the following data:
DB_USERNAME=admin DB_PASSWORD=password123
This data can be injected into the container by defining the key that the environment variable refers to ConfigMap. For example:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
env:
- name: DB_USERNAME
valueFrom:
configMapKeyRef:
name: my-config
key: DB_USERNAME
- name: DB_PASSWORD
valueFrom:
configMapKeyRef:
name: my-config
key: DB_PASSWORD
- Use volume
Another common method is to mount ConfigMap data into a container as a file or directory. Suppose a ConfigMap named my-config has been created, containing the following data:
: =8080 =jdbc:mysql://localhost/mydb
You can use the following YAML to define a Pod and mount ConfigMap into the container as a Volume:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: my-config
Within the container, you can use the same path as the volume to access the data in the ConfigMap.
- Custom global parameters
ConfigMap data can also be passed to Kubernetes objects such as Deployment as custom global parameters.
For example, the following YAML defines a Deployment where the parameters can be set via ConfigMap:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-image
command: ["/bin/myapp"]
args: ["--config=/etc/myapp/"]
env:
- name: MY_APP_ENV
value: "production"
volumeMounts:
- name: config-volume
mountPath: /etc/myapp/
volumes:
- name: config-volume
configMap:
name: my-config
In this example, we pass the configuration file of myapp to the container via ConfigMap and set the environment to production.
Notes on using ConfigMap
ConfigMap is a very useful feature in Kubernetes, but the following points need to be paid attention to to use it correctly:
- Avoid including sensitive information
Since ConfigMap is stored in plain text, it should not contain sensitive information such as passwords or keys. This information should be stored and managed in other secure ways, such as the Secret object of Kubernetes.
- Note the synchronization between ConfigMap and container
If the data is changed in ConfigMap, containers in the Pod may not get the changed information in time. This can be solved by setting the Pod to restart or reloading the ConfigMap at runtime.
- Specify the key that must exist
If the key that does not exist in the container reference ConfigMap, the container will not start. Therefore, it is recommended to specify the key that must exist when defining ConfigMap in the YAML file.
- Storage ConfigMap may cause problems under default namespace
If ConfigMap is stored in the default namespace, problems may occur when using ConfigMap in another namespace. Therefore, it is recommended to store ConfigMap in its own namespace.
Summarize
ConfigMap is an important resource object in Kubernetes that can store insensitive configuration information and inject it into a pod.
This article introduces how to create and use ConfigMap, and discusses its precautions. Correct use of ConfigMap can greatly simplify application management and deployment, improve reliability and security. For more information about the separation of K8S ConfigMap application configuration, please follow my other related articles!