Helm Release Time-To-Live(TTL) for Temporary Environments

When working with Kubernetes, its often the case that youll need to create temporary environments/namespaces. You might need this as a way to limit the resources use, handle dev/staging environments, or just as a way to contain your tests while working on them. If you have used Helm before, you know that installing applications via Helm charts is simple by using the helm install command. The problem is that after installing a package, you or the user still needs to manually delete the package. With this in mind, we are going to explore how we set Time-To-Live Expiration for helm releases via the plugin, and create temporary Environments with to make our lives easier with Helm.

You can find the helm-release plug on :

To install the helm release plugin run command:

helm plugin install https://github.com/JovianX/helm-release-plugin

What are Helm Temporary Releases?

Helm temporary releases are one of the most useful features in the plugin. A temporary release allows you to run an application, while you test a new feature or validate a fix, and then it gets deleted and purged after a certain period of time. Temporary releases can be deployed in a new Kubernetes namespace or in an existing one.
The temporary application is effectively isolated from the rest of the Kubernetes cluster. It only has access to the resources that are allotted to it, and it iss are not affected by other pods, or the rest of the cluster. When you use a temporary environment to run the application, it is not impacting other apps running in the cluster. This means that they: Have their own set of persistent volumes, have their own set of APIs (endpoints, certificates, and so on). Youll find that temporary environments are very useful for testing, staging, and debugging, since you can use them to run test pods without disturbing the rest of the Kubernetes cluster, and not worry about forgotten releases that keep consuming cloud resources, and keep spending your cloud budget.

Why would you need a Helm Temporary Environment?

As I mentioned above, temporary environments are very useful when testing and debugging your code. Unfortunately, a common pattern is to create a new environment, install the dependencies in that environment, and then forget to remove the temporary environment after youve finished with it. This means that unneeded applications are consuming pricy cloud resources, and the next time you go to test your code, youll have leftovers from your previous testing run. This is commonly referred to as pollution, and if not cleaned up, can create confusion and make it harder for you to debug. Helm is an incredibly powerful tool for installing and managing dependencies on Kubernetes. Unfortunately, when using it for testing, you have to create a new environment for each test and then manually delete the environment once youre done with it. This is fine if youre only doing testing with a few things, but if youre testing a lot of things, youll end up with a lot of environments that you need to keep track of.

How does Helm release TTL Temporary Environments work?

Helm release TTL expiration is a new feature that was added in the v0.4 release of the plugin. This feature automatically creates a temporary environment that lasts the amount of time that you specify. Once that time has elapsed, the temporary environment will be automatically destroyed. This means that you can use it to test your code, and once youve finished, the environment will be destroyed. This also means that if you test with the same code again, youll have a clean environment without having to manually delete the environment.

Creating a Temporary Environment

To create a temporary environment with a TTL you first need to deploy the Helm release:

helm repo add bitnami https://charts.bitnami.com/bitnamihelm install my-release bitnami/apache...

Once youve created the release you can use the new helm release ttl command to set the environment TTL.

helm release ttl my-release --set='5 minutes'

The helm release ttl command takes the following options: - <RELEASE_NAME> - the name of the release, and --set to set the amount of time that the environment will last before expiring, the time format following the date Linux command time formatting.

Managing Expiration for a Temporary Environment

If youve created a temporary environment and you want to manage the expiration of that environment, you can use the helm release ttl <RELEASE_NAME> command to see the release expiration time.

helm release ttl redisScheduled release removal date: Tue Aug 30 20:12:00 EEST 2022

To Remove the expiration date use the --unset flag.

helm release ttl <RELEASE NAME> --unset

Conclusion

Temporary environments are very useful to make sure unnecessary resources are not eating up your cloud budget, and when testing code. Unfortunately, when manually creating environments, they can be easy to forget about and let linger until they become pollution. expiration solves this problem by creating a temporary environment that will automatically expire after the amount of time that you specify. With this in mind, you can use it to easily test your code, and once youve finished, the environment will be destroyed.