[WIP]: Add Kruize Autoscaler #1801
Conversation
Signed-off-by: Dinakar Guniguntala <dgunigun@redhat.com>
Signed-off-by: Dinakar Guniguntala <dgunigun@redhat.com>
Signed-off-by: Dinakar Guniguntala <dgunigun@redhat.com>
Signed-off-by: Dinakar Guniguntala <dgunigun@redhat.com>
Signed-off-by: Dinakar Guniguntala <dgunigun@redhat.com>
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
needs-ok-to-test
|
Hi @dinogun. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
There was a problem hiding this comment.
(nit) The app's metrics are pulled by Prometheus rather than pushed. Similarly I suppose that Kruize queries metrics from Prometheus.
|
|
||
| **Summary** | ||
|
|
||
| This enhancement proposes the integration of Kruize as a new Autoscaling and Recommendation Engine in OpenShift. Kruize will assist users not only with container right-sizing and autoscaling, but also with namespace quota recommendations and GPU right-sizing and autoscaling through integration with the Instaslice project. Additionally, it will offer a Bulk API for managing multiple workloads simultaneously, box plots for improved visualization of recommendations, and notifications for various resource usage events. |
There was a problem hiding this comment.
This enhancement proposes the integration of Kruize as a new Autoscaling and Recommendation Engine in OpenShift.
Integrated...how? (At least, conceptually?) 😄
-
Since this is an OpenShift enhancement, I assume there is some "OpenShift specific stuff" that you want to happen? Like, OpenShift is expected to change in some way as a result of this proposal?
-
What's in here so far just seems to be "yes, we've connected Kruize to the VPA" -- what's being described here so far could be done right now presumably in any Kubernetes cluster, it's not clear what OpenShift needs to do differently.
-
The VPA operator currently ships as an OLM operator installable from the marketplace/OperatorHub. Is the intent something like:
- install the VPA from the marketplace
- install Kruize (from the marketplace??)
- configure some stuff to make them work together?
Or are you proposing some sort of OpenShift platform component that stitches together Kruize + VPA + the configuration into some kind of cohesive thing?
There was a problem hiding this comment.
@jkyros Thanks for the review. I agree the request is looking deeper into the Kruize VPA integration whereas maybe it needs to first address the OpenShift aspect.
We dont yet have Kruize as a OLM operator, it is in the works. However the goal is for Kruize to be made available as a OLM operator and for it to be installed from there. Do you think that this is a pre-req for this enhancement request or is it ok for us to have the installation done through scripts until that happens.
Also do you think the Kruize VPA integration aspect is needed to be explained here or is that not relevant?
There was a problem hiding this comment.
However the goal is for Kruize to be made available as a OLM operator and for it to be installed from there. Do you think that this is a pre-req for this enhancement request or is it ok for us to have the installation done through scripts until that happens.
@dinogun No, not a prereq by any means for this request. I actually think it would great if we captured the intended progression of this here in the enahcement. Something like:
- Phase 1: Dev/Tech preview, install with scripts from
<blessed location> - Phase 2: Pack Kruize as an OLM operator, document OpenShift configuration instructions in OpenShift doc
- Phase 3: ???
And maybe Phase 3 is someday something that "makes configuring it way more pleasant" like:
- Some logic in Kruize + OpenShift VPA operator so they can find each other and genrate some boilerplate objects if they do?
- Or maybe some "It just works" checkbox somewhere in ACM or some other add-on?
- Or some other central thing that handles the configuration automatically for the user?
I don't know. I just think capturing how we expect it to evolve would be great and make it clear where you want/expect this to go?
Also do you think the Kruize VPA integration aspect is needed to be explained here or is that not relevant?
I think if we want/expect to to build something into OpenShift to deal with VPA integration or document it somewhere as part of this process it's relevant.
-
Like maybe at least state what the installation scripts are intended to do for configuration between the VPA and Kruize? Like do your Kruize install scripts currently install the VPA OLM operator automatically as a dependency or is that something the user is expected to do?
-
Or if "how users will configure it" is "read the OpenShift Kruize doc / OpenShift VPA doc which will be produced as part of this enahcement work and see the section on VPA integration" we could at least state that in the enhancement?
There was a problem hiding this comment.
Thanks for all the clarifications, it really helps!!
- Phase 1: Dev/Tech preview, install with scripts from
<blessed location>- Phase 2: Pack Kruize as an OLM operator, document OpenShift configuration instructions in OpenShift doc
- Phase 3: ???
I think we are fairly close to Phase 2, so maybe we can start from there.
Also do you think the Kruize VPA integration aspect is needed to be explained here or is that not relevant?
I think if we want/expect to to build something into OpenShift to deal with VPA integration or document it somewhere as part of this process it's relevant.
Kruize has a dependency on VPA for compute resources, it has a dependency on Instaslice for GPU resources. Given this, it would be nice to have Kruize install (through Operator) ideally take care of both of these under the covers if they are not already present.
As an aside, does Instaslice installation take care of Nvidia GPU operator as well?
- Like maybe at least state what the installation scripts are intended to do for configuration between the VPA and Kruize? Like do your Kruize install scripts currently install the VPA OLM operator automatically as a dependency or is that something the user is expected to do?
At the moment, VPA is expected to be present, we don't take care of that
- Or if "how users will configure it" is "read the OpenShift Kruize doc / OpenShift VPA doc which will be produced as part of this enahcement work and see the section on VPA integration" we could at least state that in the enhancement?
Listing all of the dependencies in the doc definitely makes sense, especially as it would mean setting aside resources for each of these entities
No description provided.