Move away from custom autoscaler fork for MCM Provider to gRPC pluggable provider #783
Labels
area/dev-productivity
Developer productivity related (how to improve development)
kind/enhancement
Enhancement, improvement, extension
kind/technical-debt
Something that is only solved on the surface, but requires more (re)work to be done properly
lifecycle/rotten
Nobody worked on this for 12 months (final aging stage)
needs/planning
Needs (more) planning with other MCM maintainers
priority/4
Priority (lower number equals higher priority)
How to categorize this issue?
/area control-plane
/area auto-scaling
/kind enhancement
/priority 3
What would you like to be added:
Today the gardener MCM team manages a custom fork of k8s cluster autoscaler that includes code which implements the cloudprovider.CloudProvider interface. This involves regular maintenance, resolving merge conflicts, associated testing, management of custom images etc.
However, the autoscaler has in the last year provided a mechanism to inject custom providers via gRPC obviating the need for separate fork maintenance. This is described here: Pluggable gRPC provider mechanism and the calling gRPC client is present here: External gRPC Client
The enhancement request is to implement our MCM controller as an external gRPC cloud provider, remove our custom autoscaler image and leverage the standard autoscaler image with all associated and necessary changes in testing/deployment/rollout.
Why is this needed:
This has also been mentioned as an issue in our autoscaler fork: gardener/autoscaler#172
The text was updated successfully, but these errors were encountered: