How to Configuring Redis Using a ConfigMap

By | September 29, 2022
Configuring Redis Using a ConfigMap

If you wish to configure Redis using a ConfigMap, then you have landed at the right place.

This article helps to understand this concept in detail.

As a first step, you must have a Kubernetes cluster along with a configured kubectl command-line tool to establish a nexus with the cluster. If you currently do not have a cluster, you have the option to create one with the help of minikube.

Or on the other hand, you also have the option to use one of the Kubernetes playgrounds. For instance, Katacoda or Kubernetes.

Moving on, to know about the version, simply type Kubectl version.

Let us now understand the steps to configure a Redis cache using the data of ConfigMap.

The first step is to create a config map as shown below:

cat <<EOF >./example-redis-config.yaml

apiVersion: v1

kind: ConfigMap

metadata:

name: example-redis-config

data:

redis-config: “”

EOF

The next step is to apply this config map with the Redis pod as explained below:

kubectl apply -f example-redis-config.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml

Moving on, here is a list to analyse the contents of the Redis pod and understand the following points:

  • spec.volumes[1] creates a volume named config
  • Under the section, spec.volumes[1].items[0], the key and path shows the redis-config key from the example-Redis-config ConfigMap
  • By spec.containers[0].volumeMounts[1] the config volume mounts at /redis-master

Now, from example-raids-config ConfigMap, the data is exposed in data.redis-config as /redis-master/redis.conf in the pod.

Take a look at this piece of code:

apiVersion: v1
kind: Pod
metadata:
 name: redis
spec:
 containers:
 - name: redis
 image: redis:5.0.4
 command:
 - redis-server
 - "/redis-master/redis.conf"
 env:
 - name: MASTER
 value: "true"
 ports:
 - containerPort: 6379
 resources:
 limits:
 cpu: "0.1"
 volumeMounts:
 - mountPath: /redis-master-data
 name: data
 - mountPath: /redis-master
 name: config
 volumes:
 - name: data
 emptyDir: {}
 - name: config
 configMap:
 name: example-redis-config
 items:
 - key: redis-config
 path: redis.conf

kubectl get pod/redis configmap/example-redis-configNow is the time to bring the objects that you created under examination. Use this command as given below:

The output looks like this:

NAME READY STATUS RESTARTS AGE
pod/redis 1/1 Running 0 8s
NAME DATA AGE
configmap/example-redis-config 1 14s

Moving on, notice that you had left the redis-config key, in example-redis-config ConfigMap:

kubectl describe configmap/example-redis-config

This is what an empty redis-config key:

Name: example-redis-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
redis-config:

Moving on, you need to use kubectl exec so that you can enter the pod. Next, to check the configuration, you have to run the redis-cli tool as given below:

kubectl exec -it redis -- redis-cli

To check maxmemory, type in the following command:

127.0.0.1:6379> CONFIG GET maxmemory

The default value should be 0. Take a look:

1) “maxmemory”

2) “0”

You can check maxmemory-policy by using the given command:

127.0.0.1:6379> CONFIG GET maxmemory-policy

It yields to a default value of noeviction:

1) “maxmemory-policy”

2) “noeviction”

To make you more clear about the topic, here is an example of the example-redis-config ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
 name: example-redis-config
data:
 redis-config: |
 maxmemory 2mb
 maxmemory-policy allkeys-lru 

You have to apply the ConfigMap now:

kubectl apply -f example-redis-config.yaml

The next step is configuration of values:

Name: example-redis-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
redis-config:
----
maxmemory 2mb
maxmemory-policy allkeys-lru

The Redis pod can be accessed using redis-cli to check if your configured parameters have been applied or not:

kubectl exec -it redis — redis-cli

Again, to check maxmemory, type in the following:

127.0.0.1:6379> CONFIG GET maxmemory

The default value stays at 0:

1) “maxmemory”

2) “0”

Also, the maxmemory-policy stays at noeviction default setting, as shown in the below-stated command:

127.0.0.1:6379> CONFIG GET maxmemory-policy

The output shows like this:

1) “maxmemory-policy”

2) “noeviction”

If you notice here, the configuration values are the same. The reason is that the pod needs a restart so that it can update the values of the ConfigMaps.

Here, we are going to delete the pod and recreate a new one. Take a look at the procedure:

kubectl delete pod redis
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml

It’s time to recheck the values for the last time. Use the below given command:

kubectl exec -it redis -- redis-cli

To check the maxmemory, type:

127.0.0.1:6379> CONFIG GET maxmemory

The value in the output looks like this:

1) “maxmemory”

2) “2097152”

Now, you can notice that the maxmemory-policy is updated:

127.0.0.1:6379> CONFIG GET maxmemory-policy

At this point, you will see the desired value regarding allkeys-lru:

1) “maxmemory-policy”

2) “allkeys-lru”

You can now clear up the resources that you created using the below-given command:

kubectl delete pod/redis configmap/example-redis-config

Additionally, there are certain restrictions associated with the same. Take a look:

In order to define environment variables, if you use envFrom, it skips the invalid keys. The pod starts but it records the invalid names in the event log. Moreover, the log message displays the list of skipped keys. For instance:

kubectl get events

Here is the output:

LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE

0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.

You must create a config map before you can refer it to a pod. Furthermore, if the reference does not exist, your pod will not initiate. Similar to the ConfigMap, if you give references to non-existent keys, the pod will not start.

Conclusion

As you can understand, ConfigMaps helps to decouple the configuration artifacts for containerized applications to be portable from the image content.

You learned how to create ConfigMaps and how to configure pods based on the data in them in this article.

It is our hope that the information provided will help you understand the concept better!

Keep learning, keep exploring!

Leave a Reply

Your email address will not be published.