Skip to main content

Announcing GoKubeDownscaler 1.4.0

· 5 min read
GoKubeDownscaler Maintainers
GoKubeDownscaler Maintainers
Development Team of the GoKubeDownscaler

We are pleased to announce the release of version 1.4.0 of GoKubeDownscaler. This release focuses on introducing brand-new features, improving the scaling process, adding new resources and CRDs that can be managed within the Kubernetes cluster, improving the logging system, and fixing unexpected bugs and behaviors.

If you like the project, giving us a star would mean a lot to us! Reaching 300 stars would bring us one step closer to our goal and enable us to apply for inclusion in the CNCF Landscape.

New Features​

Over the past few months, we have been working hard to add several features we are thrilled to announce today.

  • LoadBalancer Scaling: Kubernetes Services of type LoadBalancer, as well as Ingresses and Gateway API resources can now be scaled down along with all other resources! This new feature takes the cost optimization of the cluster to the next level. LoadBalancers from cloud providers are among the most expensive resources in a Kubernetes cluster, and they are often left idle during off-hours. An average LoadBalancer from a cloud provider costs around $20 per month. Considering a 40-hour work week, users can now save up to 70% of the cost of a single LoadBalancer by scaling it down during off-hours. We recommend combining GoKubeDownscaler with ExternalDNS to enable seamless scale-down automation while automatically handling DNS changes, so users don’t have to worry about restoring DNS records when LoadBalancers are scaled back up. You can find more information about the feature in the DNS Aware Load Balancing Scaling guide.
  • Directional Timespan: this new timespan allows users to specify a target point in time relative to a specific timestamp, either before or after it. A common example would be downscaler/downtime: from 2026-09-01T08:30:00Z or downscaler/exclude: until 2026-09-01T08:30:00Z
  • Improved Logging: the logging system has been improved to provide more detailed information about the scaling process. This includes information about the resources being scaled, the reason for scaling or exclusion, initial and final state of the resources, the scope that decided the scaling, and any errors that may occur during the process. Log levels have been restructured and rebalanced to provide more relevant information at each level. More information about the logging system can be found on the logging documentation page.
  • New Resources: New resources have been added to the list of scalable resources, including Strimzi Kafka CRDs (KafkaBridges, KafkaConnects, KafkaMirrorMakers), PostgreSQLs from Zalando, and Kruise CRDs (AdvancedCronJobs, AdvancedStatefulSets, AdvancedDaemonSets, CloneSets, BroadcastJobs, ImagePullJobs). As mentioned in the first bullet point also Services, Ingresses, and Gateway API resources can now be scaled down.
  • New Argument: added the possibility to specify a custom --timeout value for API calls made by GoKubeDownscaler. A default timeout of 30 seconds is used and applied to every API Call if no value is specified. To disable the timeout, users can set the value to 0

Along with these features, we have also introduced several bug fixes and improvements to key behaviors:

  • Fixed the GetChildrenWorkloads behavior to correctly handle and identify child workloads.
  • Fixed the DEFAULT_TIMEZONE configuration so the configured timezone is correctly applied.
  • Fixed scanner mode to avoid scaling KEDA ScaledObject targets when the workload's TypeMeta is missing.
  • Fixed the algorithm to continue processing when a broken annotation is encountered instead of stopping.
  • Updated owner-reference handling to consider owner references only for scalable resources.
  • Updated the behavior of downscaler/exclude-until annotations. Past dates are no longer considered valid and will not be taken into account when populating scopes.
  • Fixed a bug that prevented --json-logs from displaying debug level logs when --debug was specified.

Conclusion & Future Developments​

The development team sincerely thanks everyone who took part in the development of this release, volunteering their time, offering ideas, suggestions, and pull requests. We would like to extend our gratitude to all the users who waited patiently for this release which, unfortunately, took longer than expected. In the coming months we expect to add mainly features to support GitOps workflows on Argo and Flux, while we continue to improve the stability and performance of the GoKubeDownscaler.

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.

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. Alternately, you can also open a PR on Github to add your logo to the adopters page.