{{announcement.body}}
{{announcement.title}}

Manage Configurable Data In Kubernetes

DZone 's Guide to

Manage Configurable Data In Kubernetes

This article, throught the use of actual code snippets, demonstrates some of the uses of configMap in Kubernetes Pods dynamically to decouple them.

· Cloud Zone ·
Free Resource

When doing containerization, often there is a need to have some configurations manageable from outside the container. After a container has booted with certain pre-configured data, it is necessary to have a way by which this data can be modified at runtime, if needed. For instance, we may have different configurations for different deployment environments and we may want to use the correct set of configurations for a target environment without re-creating the container.

Kubernetes provides ConfigMap to help configure data externally. This follows the design paradigm - "separation of config from code." The ConfigMap API makes the application portable. The configuration can be changed without redeploying the application.

ConfigMap

Kubernetes' ConfigMap resource holds data as a key-value pair. It allows us to specify configuration data outside of the container. This decouples the image and its configuration. Any changes to a configMap at runtime also reflects within the running container. Hence, configMap is a very useful tool in several use cases, such as:

  • Setting environment variables
  • Setting command-line arguments in a pod
  • Reading config files from a Volume

Each of these use cases is explained further in this post. 

First, let's take a look at a sample ConfigMap.

YAML
 




x
14


1
kind: ConfigMap
2
apiVersion: v1
3
metadata:
4
  creationTimestamp: 2020-03-12T20:10:5Z
5
  name: my-configmap
6
  namespace: default
7
data:
8
  environment.variable.1: value1
9
  environment.variable1.2: value2
10
  external.property.file: |-
11
    prop.1=value1
12
    prop.2=value2
13
    prop.3=value3
14
 
          


In the above example, the field data holds the configuration data. As we can see, it can hold individual properties as well as content from an external file.

Create a ConfigMap

Let us now start by creating a configMap. This can be done by using the command below: 

Shell
 




xxxxxxxxxx
1


1
$ kubectl create configmap <name> <source>


where the name is the name of configMap and the source is a literal value or a file containing the data.

To populate the configMap from literal values, see the command: 

Shell
 

If we have a directory containing multiple files then use the following command: 

Shell
 

To see details of an already created configMap, use the following command:

Shell

Using ConfigMap in a Pod

There are several use cases where a configMap is used inside a Pod specification.

For Environment Variables

If we need to set the value of an environment variable declared in a Pod specification using configMap then we can follow below steps.

First, create a configMap:

Shell
 




xxxxxxxxxx
1


1
$ kubectl create configmap my-configmap --from-literal=property.1=value


Now create a pod specification (mypod.yaml):

YAML

Now create the pod from the above specification.

Shell

Now to verify if the environment variables have been created.

Shell
 




xxxxxxxxxx
1


 
1
$ kubectl exec my-pod -it -- env | grep ENV_VARIABLE
2
 
          
3
ENV_VARIABLE =value


It is not necessary to set the config data from one configMap only. We can specify multiple configMaps and use them to set different environment variables.

Let’s say we have two configMaps, my-configmap1 and my-configmap2.

We can then use them as follows in a pod:

YAML
 




xxxxxxxxxx
1
20


 
1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: my-pod
5
spec:
6
  containers:
7
    - name: my-container
8
      image: hello-world
9
      env:
10
        - name: ENV_VARIABLE_1
11
          valueFrom:
12
            configMapKeyRef:
13
              name: my-configmap1
14
              key: property.1
15
        - name: ENV_VARIABLE_1
16
          valueFrom:
17
            configMapKeyRef:
18
              name: my-configmap2
19
              key: property.1


For Command-Line Arguments to A Pod

Pod specification has a section of command. We can set this command from a configMap thus making the command dynamic. See the below pod specification:

YAML

Here, KEY holds the value of property.1 defined in a configMap my-configMap.

If we are using a Kubernetes volume for the pod and then we can populate it using files declared in a configMap. See the pod specification below:

YAML
 




xxxxxxxxxx
1
17


 
1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: my-pod
5
spec:
6
  containers:
7
    - name: my-container
8
      image: hello-world
9
      volumeMounts:
10
      - name: test-volume
11
        mountPath: /etc/myvolume
12
  volumes:
13
    - name: test-volume
14
      configMap:
15
        # Name ConfigMap which contains list of files which will be populated in the voume
16
        name: my-configmap


In the above example, my-configmap data will be added to the volume mentioned in volumeMounts.mountPath.

Conclusion

We discussed in this post how we can use Kubernetes resource configMap to set the configuration data of the pods dynamically thus decoupling config from code.

We explained how to use configMap through actual code snippets which can be used readily in your project.

Topics:
docker ,kubernetes ,container configuration ,container challenges ,cloud ,configmap ,kubernetes pods ,decoupling

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}