From now on, all development and new features will focus primarily on this project, with the goal of making it available within the CNCF landscape.

New Features​

Over the past few months, in addition to adapting PyKubeDownscaler features within this new project, we have been working hard to release as many new features and improvements as possible to make Kubernetes downscaling and cost optimization workflows as effective as possible. Among the new features are:

• Introduction of Metrics: Starting today, GoKubeDownscaler exposes a series of metrics that can be used for production alerts, general statistics, and tracking of CPU and memory savings. Metrics can be exposed using the --metrics argument.
• Performance Optimizations: GoKubeDownscaler introduces new quality-of-life performance improvements. API calls have been optimized and reduced, multithreaded execution has been introduced, leveraging Go's native parallelism. Resource usage has been minimized, especially during idle situations.
• Webhook Introduction: An optional webhook has been introduced that can perform scaling during resource admission phases. This is very useful for ensuring cluster compliance and avoiding unnecessary scale-ups that could occur if a resource is deployed between two KubeDownscaler cycles. The webhook can be installed via Helm Chart.
• Regulated API Server Access: GoKubeDownscaler now natively supports and customizes QPS and Burst values to avoid saturating the API Server during downscaling peaks. The user can adjust these values using the --qps and --burst arguments.
• Introducing JSON Logs: GoKubeDownscaler can now print logs in JSON format using the --json-logs argument.

How To Migrate From PyKubeDownscaler​

To migrate from PyKubeDownscaler, you can follow the dedicated guide in our documentation at this link. We expect the migration to be quick and with only a few changes required. We recommend reading the guide carefully to avoid missing any details. The development team is available to answer any questions or address any issues within the "Issues" or "Discussions" sections of the GitHub repository.

PyKubeDownscaler Set In Maintenance Mode​

For anyone wondering what will happen from now on to the PyKubeDownscaler project, our fork of the original KubeDownscaler that we have maintained, evolved, and refined over the past two years, we assure you that we will continue to support the tool with bug fixes, security patches, helm chart changes, and the introduction of any mandatory features.

Adopters​

If your company actively uses the GoKubeDownscaler, you can contact us through our slack channel to add your logo to our showcase carousel in the homepage of our website.

Conclusions​

The development team sincerely thanks everyone who, over the past year and a half, supported the development of this new tool by volunteering their time, offering ideas, suggestions, and pull requests. In the coming months we expect to add as many features as possible to make this project more and more attractive, stay tuned!

Why Not Use the Py-Kube-Downscaler​

The Py-Kube-Downscaler (or just known as the kube-downscaler at the time) was a popular tool for downscaling kubernetes workloads. It had loads of configuration options and a big userbase.

Even with its many users and contributors the project and its dependencies (like pykube) were over time all becoming unmaintained. Additionally its codebase became cluttered over the years of being developed which made adding new features, maintaining the repo and adding new resources hard to do and prone to introduce unwanted bugs.

With the py-kube-downscaler becoming unmaintained more and more bugs were slowly coming to the light of day. At our company we also ran into some bugs which we tried to fix via a pr to the project. However, since the project was no longer maintained our pr did not get merged. After a few weeks we decided that we should maintain a fork of the project ourselves. This also meant maintaining the pykube (also known as pykube-ng and now new-pykube) dependency.

After we cleaned up the repo and fixed the bugs our prs were aiming to fix we continued to maintain the project along with Samuel. As more work was done on the project the above points about it being hard to maintain became clear. This led us to decide that it was necessary to rewrite the project since doing a big refactoring would basically involve the same.

The Reason for Choosing Golang​

It soon became clear that rewriting the project in python would not be the best option, as all native kubernetes libraries including ones for CRDs are either only available to golang or native to it.

Golang also has many other advantages compared to python like being statically typed making collaboration easier, having faster execution times thanks to compilation as well as generally being more efficient with memory management and other resources.

Go's concurrency model is also one of the easiest to work with. This allowed us to build the downscaler to use concurrent operations wherever possible making scans complete much faster.

In our team we were also already basically exclusively using golang for our other projects which made it clear to us that using golang was the way to go.

General Design Considerations​

As said above the design of the Downscaler is made to be based on go's great concurrency. This also makes conflicts from workloads being modified while they are being scanned less likely.

One of our main focuses is making this repo as easy to maintain and keep clean as possible. To achieve this we are making use of many strict linters and other tools like dependabot.

We also want to make sure that adding new resources is as easy as possible, which is why we are planning on making all resources data driven allowing anyone to add custom resources or modify existing ones without touching or having any knowledge of the code.

It was also important to us that you can run the downscaler locally which greatly simplifies testing new features while developing. This is done by if applicable having a runtime configuration to substitute these in-cluster sources of data (e.g. -k for setting the kubeconfig manually).

Outlook​

We plan to continue maintaining, improving and adding new features to the project. With the GoKubeDownscaler soon being stable and feature complete we are planning on concentrating on further development of the project while we step back from developing new features for the py-kube-downscaler.

What this means is that in the future the py-kube-downscaler project will only be maintained by dependency updates, security fixes and bug fixes. The GoKubeDownscaler project will be the official successor to the old kube-downscaler and will likely be the only downscaler that gets new features and improvements.

Any changes to the repo will continue to be strictly reviewed and tested by us maintainers and code quality/security tools. We will be adding more linters and general tools to make sure the project's code stays clean and its dependencies up-to-date

Conclusion​

In summary, the lack of good first party apis for python, go's efficiency and the state of the py-kube-downscaler repo all led to rewriting the project in golang. The kube-downscaler's rewrite is more efficient and can handle larger clusters thanks to go and we will continue to make sure that the GoKubeDownscaler's repo stays clean and easily maintainable.