Replica counts changing based on time of day

[pcfens]

We have some workloads that we'd like to scale up and down based on time of day (e.g. anticipated loads, scaling non-production instances to 0 to save money after hours, etc). I don't think the fix outlined in #1686 will work because either spec.replicas (in a deployment) or spec.minReplicas/spec.maxReplicas (in an HPA) needs to change.

As I understand it, a user can adjust the number of replicas by editing a deployment directly or by adjusting the limits in an associated HPA. The mechanism might be manual (captured in git), a CronJob, or some schedule controller. I'm concerned that the automated options would be undone by the flux agent. An HPA native approach never got a lot of traction (kubernetes/kubernetes#49931)

The only fixes I can think of that keep git as a source of truth involve syncing some data back to the repository. Is there a better option?

[2opremio]

I don't think the fix outlined in #1686 will work because either spec.replicas (in a deployment) or spec.minReplicas/spec.maxReplicas (in an HPA) needs to change.

Why not? As long as you keep the HPA in git and edit the values there, it should work.

[pcfens]

Editing in git works well when it's a manual change but not for automatic changes like scaling a test environment to 0 overnight and on weekends.

[pcfens]

There are a number of options out there that will modify HPA objects or the replica count in a Deployment or StatefulSet based on the time of day.

As long as flux automation isn't turned on something like kubernetes-cronhpa-controller should work if we leave replicas blank in the deployment specification. The one downside is that we'll only be running 1 replica between the initial deployment (or manual upgrade) until the first scaling event.

Without the ability to sync something back to the git repository I'm still not sure how we can make kubernetes auto-scale workloads based on time of day, default to more than one replica, and work with a gitops workflow.

[graywolf-at-work]

Without the ability to sync something back to the git repository

Is that a problem? Why cannot the cron commit the result?

[pcfens]

cron could commit a change, but then it would require the job be the only thing that dynamically modifies the objects and for the user to handle yaml parsing and SSH keys. The right fix for this might be the ability to selectively sync resources/fields from Kubernetes back to git (object annotations?).

[kingdonb]

As Flux contrib efforts have been focused on Flux v2, we have developed a support policy page with references to how community works in our new architecture for Flux v2, with more different ways to meet and engage with us for help. If you've been following our development efforts then of course we hope you are able to upgrade, here's more info on how to find support with that: https://fluxcd.io/support/ - tl;dr: the Flux project has moved to a new repo, fluxcd/flux2

If this is still affecting you, I will be happy to reopen and/or troubleshoot with you here, or in the #flux slack channel on CNCF, but in the interest of reducing the number of open issues not directly related to supporting Flux v1 in maintenance mode, and respecting you may have moved on already, I will go ahead and close out this issue for now.

[pcfens]

Hi @kingdonb- I think this is still open, but it's likely moved from a question to a feature request. I'll re-create the request with a better description in the new repo. Thanks!