Downscaling of multiple deployments
floretan opened this issue · 2 comments
There are cases where it would be nice to turn off multiple deployments/statefulsets based on traffic coming to a single service. For example, when we have a web application with a database behind it.
It would be possible to use the annotation on all services, but then each deployment would be upscaled sequentially, most likely resulting in a timeout.
A similar pattern is apparently used in OpenShift (https://github.com/openshift/service-idler).
What would you like to be added?
Update the service annotation so it can take references to multiple deployments.
Why is this needed?
Make it possible to scale to 0 more complex applications.
I can see the usefulness behind that, although I don't have the bandwidth to implement such a feature at the moment.
I'll leave some thoughts here in case anyone else wants to take it up:
We'd have to permit multiple values for the osiris.deislabs.io/deployment
on service resources. Activations would have to involve waiting for all of the indicated deployments to scale up and reach a ready state before forwarding traffic. We'd need to be able to very clearly differentiate between the deployment that should have traffic directly forwarded by the activator upon activation and those deployments that are farther downstream and simply need to be ready in order for that request-forwarding to proceed. It's possible that we should maybe leave the osiris.deislabs.io/deployment
annotation as is and use a new annotation for keeping track of these "downstream deployments."
My workaround for this challenge is:
- Add simple http server pod to the other deployments/statefulsets and create service (A) for them
- I'v used nginx docker image without changing config
- Add another nginx reverse proxy container in front of main pod then mirror traffic to (A).
- So, your sub deployments/statefulsets can scale to zero and up again with the main deployment.
I know it is rather hackish solution, but it works so far. I use it for development environments of PR branches. So I don't care much about....