Jump right into Kubernetes development with career-focused lessons and hands-on practice.

DevOps for Developers

Kubernetes is a powerful container management tool that's taking the world by storm. This detailed course will help you master it.

In this course, you'll start with the fundamentals of Kubernetes and what the main components of a cluster look like. You'll then learn how to use those components to build, test, deploy, and upgrade applications, as well as how to achieve state persistence once your application is deployed. You'll also learn how to secure your deployments and manage resources, which are crucial DevOps skills.

By the time you're done, you'll have a firm grasp on what Kubernetes is, as well as the skills to deploy your own clusters and applications with confidence.

A Practical Guide to Kubernetes

# Why should we not use ConfigMaps?

In our experience, ConfigMaps are overused.

If we have a configuration that is the same across multiple clusters, or if we have only one cluster, all we need to do is include it in our Dockerfile and forget it ever existed. When there are no variations of a configuration, there’s no need to have a configuration file, at least not outside an immutable image.

Unfortunately, that is not always the case. To be more precise, it’s almost never the case. We tend to make things more complicated than they should be. This, among other things, often means an endless list of configuration options hardly anyone ever uses. Still, some things usually do change from one cluster to another, and we might need to look into alternatives to configurations baked into images.

# Finding out the best way
The best way to design new applications is to use a combination of configuration files and environment variables. Make sure that the default values in a configuration file are sensible and applicable in most use-cases. Bake it into the image. When running a container, declare only the environment variables that represent the differences of a specific cluster. This way, our configuration will be portable and simple at the same time.

What if our application is not new and does not support configuration through environment variables? We should refactor it so that it does. It shouldn’t be hard to add the ability to read a few environment variables. Keep in mind that we don’t need all the settings, but only those that differ from one cluster to another. It would be hard to imagine that such a trivial request would be complex or time-consuming. If it is, we might have more significant issues to fix before even thinking about putting our application into a container.

# When to use ConfigMaps
Still, configuration files will not disappear. No matter which strategy we choose, each image should have a copy of them with sensible default values. Maybe we can put in extra effort and change the application so that configuration entries are loaded from two locations. This way, we can load the default values from one file and the differences from the other file. That would, at least, reduce the need to have to specify more than the minimum required for each cluster. In such a case, ConfigMap’s `--from-literal` and -`-from-env-file` sources are an excellent choice.

When everything else fails, the `--from-file` source can be useful. Just make sure that ConfigMap is not defined in the same file as the objects that mount it. If it is, it would mean that they could be used only inside one cluster. Otherwise, we’d be deploying the same configuration, and we should go back to the initial idea of having it baked into the image together with the application.

Do not let this pessimism discourage you from using ConfigMaps. They are very useful, and you should adopt them. Our intention was to make you think of alternatives, not to tell you never to use ConfigMaps.




In our experience, ConfigMaps are overused.

A Plea NOT to Use ConfigMaps!

Why should we not use