- Applications require a way for us to pass data to them
that can be changed at deploy time.
Examples of this might be log levels
or URLs of external systems
that the application might need at start-up time.
Instead of hard-coding these values,
we use configmaps in Kubernetes
to pass these values
as environment variables to the container.
For example, in this scenario, I have a deployment
where I have a container called karthequian reader
and, as an environment variable,
I want to pass log level of error.
So if I run this,
kubectl create -f reader deployment.yaml
I will see the deployment's been created.
Get pods, I see that the pod
is in a container-creating status,
and we see that the pod is running.
Let's take a look at the logs.
Get the pod name first.
We'll notice that this says
that the log level passed via environment variable
was error as per the application.
What we'd like to do is
we'd like to change this at deployment time.
For this, we can use something called configmaps.
In order to create a configmap,
we can use the kubectl command,
kubectl, create configmap.
We're going to call the configmap logger
and we're going to take this from literal
and we're going to call the actual value log_level=debug.
This means that
we are going to pass something called log_level=debug
to the actual container as an environment variable.
We get configmap created
and let's take a lot at the yaml for the deployment
and how that's going to change when we use configmap.
We will use VI for this,
VI, this is VI reader-configmap deployment.yaml.
Open this up and this is similar to the last example
that we opened up, except you'll notice
that we have an environment variable named log level,
but the values are values from configmapRef,
and the name of the configmap,
and the key for this is the log_level.
So this structure basically takes configmap,
which is called logger,
and reads the key, called log level,
out of the configmap.
So let's go ahead and run this example.
While this deployment is being created,
let's take a look at the actual configmaps
that we have created.
We can do this by doing a kubectl get configmaps.
As we notice, we have the logger
that we've created from before
and we can actually introspect into this guy
by doing a kubectl, get configmap/logger -o yaml,
similar to the way we look at deployments.
And this returns the entire configmap to us.
And you'll notice that in the data section,
as a log_level=debug,
which is what we had initially set it to.
By now, our deployment should be up and running.
Let's verify this by doing kubectl get deployments,
and let's take a quick look at the log for this guy.
Kubectl logs, except I cannot do a logs on deployment.
I'd have to do this on the pod.
Get pods.
I want the dynamic one.
And there we see it.
The log level passed via environment variables
was debugged.
And that's how you use configmaps
to send dynamic values into your deployment.