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!