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

When working with Kubernetes, it’s often the case that you’ll 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 Helm release plugin, and create temporary Environments with Time-To-Live to make our lives easier with Helm.

You can find the helm-release plug on GitHub:
https://github.com/JovianX/helm-release-plugin

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 Helm release 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). You’ll 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 you’ve finished with it. This means that unneeded applications are consuming pricy cloud resources, and the next time you go to test your code, you’ll 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 you’re done with it. This is fine if you’re only doing testing with a few things, but if you’re testing a lot of things, you’ll 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 Helm Release 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 you’ve finished, the environment will be destroyed. This also means that if you test with the same code again, you’ll 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/bitnami
helm install my-release bitnami/apache
...

Once you’ve 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 you’ve 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 redis
Scheduled 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”. Helm release temporary environments with TTL 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 you’ve finished, the environment will be destroyed.

Comments

[Ant(on) Weiss]

First - let me tell you it's a great little feature! Ephemeral helm releases are a definite need.
If they should be defined on helm plugin level is another consideration.
But right now something is broken.
On my M1 MacBook I'm getting:

helm release ttl my-release --set='2 minutes'
/Users/antweiss/Library/helm/plugins/helm-release-plugin/lib/main.sh: line 13: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
error: [ /Users/antweiss/Library/helm/plugins/helm-release-plugin/lib/main.sh at line 9 ]
date: illegal option -- -
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
date: illegal option -- -
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
date: illegal option -- -
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
The CronJob "my-release-ttl" is invalid: spec.schedule: Required value
error: [ /Users/antweiss/Library/helm/plugins/helm-release-plugin/release.sh at line 20 ]
Error: plugin "release" exited with error

[Arthur Berezin]

@antweiss Thanks, it's a know issue for MacBooks runnig older Bash 3.x. We are using declare -A which was introduced in bash 4.0. We are working on a fix. In the mean time you can upgrade to a newer 4.x or 5.x version of Bash to make it work.

You can find more details in the open issue github.com/JovianX/helm-release-pl...

[Ant(on) Weiss]

Makes sense!
Upgraded bash with brew install bash
Now I'm getting:

helm release ttl my-release --set='5 minutes'
bash version is 5.1.16(1)-release
date: illegal option -- -
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
date: illegal option -- -
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
date: illegal option -- -
usage: date [-jnRu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
The CronJob "my-release-ttl" is invalid: spec.schedule: Required value
error: [ /Users/antweiss/Library/helm/plugins/helm-release-plugin/release.sh at line 20 ]
Error: plugin "release" exited with error

[Ant(on) Weiss]

Basically date works differently on MacOS. So this is a new bug. :)