How to Clean Up Orphaned ConfigMaps in Kubernetes

If you don’t take steps to maintain your Kubernetes cluster, you could end up wasting money and storage on orphaned resources. Orphaned (or unused) resources, like ConfigMaps, Secrets, and Services, should be regularly located and removed to clear up storage space and prevent performance issues. 

In this post, we’ll be focusing on how to find and remove orphaned ConfigMaps.

ConfigMaps are API objects created to hold small amounts of visible configuration data. These objects support unbinding of configuration data from container images and application code for optimum portability of applications, but they cannot hold secret/encrypted data.

ConfigMaps may get orphaned if they are left isolated from the deployment they were created to support, or if their owners have been purged. Once orphaned, these ConfigMaps waste temporary storage and increase the risk of cluster instability.

Blink Automation: Find and Delete Orphaned ConfigMaps with Slack Approval

Kubernetes + Slack

Try This Automation

Finding and Deleting Orphaned ConfigMaps

Here are some steps you can take to find and remove orphaned ConfigMaps:

Step 1: Find all ConfigMaps 

First off, you can generate a list of all ConfigMaps using this command:

kubectl get configmaps –all-namespaces -o json

This command will return the list of ConfigMaps across all namespaces, but as you’ll see, the ConfigMap object does not reference its owner. You’ll need to run another command to identify which of the ConfigMaps have owners and are in use.

Step 2: Compare with a List of Used ConfigMaps

To find any orphaned ConfigMaps, you have to get the list of Pods across your cluster and list all ConfigMaps in use. Alternatively you can use the following to diff the list of ConfigMaps and used ConfigMaps, and get unused ConfigMaps:

volumesCM=$( kubectl get pods -o
jsonpath='{.items[*].spec.volumes[*].configMap.name}' | xargs -n1)
volumesProjectedCM=$( kubectl get pods -o
jsonpath='{.items[*].spec.volumes[*].projected.sources[*].configMap.name}' | xargs -n1)
envCM=$( kubectl get pods -o
jsonpath='{.items[*].spec.containers[*].env[*].ValueFrom.configMapKeyRef.name}' | xargs -n1)
envFromCM=$( kubectl get pods -o
jsonpath='{.items[*].spec.containers[*].envFrom[*].configMapKeyRef.name}' | xargs -n1)

diff \
<(echo "$volumesCM\n$volumesProjectedCM\n$envCM\n$envFromCM" | sort | uniq) \
<(kubectl get configmaps -o jsonpath='{.items[*].metadata.name}' | xargs -n1 | sort | uniq)

Finally, you can compare the two lists and delete ConfigMaps from the first list that are not in use by any Pod.

Step 3: Delete Orphaned ConfigMaps

Now that you have a list of orphaned ConfigMaps, you can run this command to delete them and free up memory in your cluster:

kubectl delete configmap/samplemap

Example output:

configmap "samplemap" deleted

Once you’ve deleted all the orphaned ConfigMaps you found, you’ll have removed unneeded, unused resources from your cluster and freed up memory and storage space. If you remove orphaned resources regularly, you’ll ensure that your team is maintaining optimal Kubernetes resource management.

Simplify Locating Orphaned ConfigMaps with Blink

Finding and removing orphaned ConfigMaps takes a few steps and you might not remember to make it a part of your routine.

With a free Blink account, you can schedule automated checks like this one so you can maintain your Kubernetes clusters in just a couple clicks:

This automation is available in the Blink library. When it runs, it does the following steps:

1. Finds unused Secrets on the cluster.
2. Finds unused ConfigMaps on the cluster.
3. Finds unused Services on the cluster.
4. Sends a report to a Slack channel.

This simple automation is easy to customize. Run it on a schedule, add approval steps to remove resources, or send the report via email or Teams instead.

There are over 5K automations in the Blink library to choose from, or you can build your own to match your unique needs.

Get started with Blink today and see how easy automation can be.