You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current autoscaler only takes the responsibility to fetch ConfigMap from the apiserver. When there is no ConfigMap created or the previous ConfigMap on apiserver got accidentally deleted, autoscaler will fail. It would be good that this autoscaler also provides the ability to create a default ConfigMap when not present, and the default ConfigMap params could(or should) be provided by user.
Here is one specific use case of autoscaler with kube-dns addon of kubernetes:
The plan to use this autoscaler with kube-dns is to make it also an addon and put its manifest into the /addon folder. By doing so, the addon manager will manage its creation and update. A problem will happen to the ConfigMap if we also treat it as an addon resource. Addon manager assumes ownership over all supplied fields in the initial config, which means the user would not be able to modify the autoscale params(ConfigMap) if they don't have the permission to modify the manifests locate on the master node. Without the ability to configure the scaling params, this autoscaler is much less useful.
An obvious way to solve above problem is to only create the ConfigMap once on startup instead of handing over it to the addon manager. But that leads to another issue that what if the ConfigMap got accidentally deleted by user? The autoscaler will be functionless if no one re-create the ConfigMap params.
To make the autoscaling feature both flexible and robust, a quick proposal below:
Add one more flag (like --default-params) for user to provide the default params for scaling. The autoscaler will create/update the corresponding ConfigMap on startup if flag presents.
The working logic remains the same, user could still modify the ConfigMap params on the fly. But if fetching ConfigMap from apiserver fails, autoscaler should re-create the ConfigMap with the given default params.
If default params not provided, autoscaler acts as before and will not manage the ConfigMap.
Current autoscaler only takes the responsibility to fetch ConfigMap from the apiserver. When there is no ConfigMap created or the previous ConfigMap on apiserver got accidentally deleted, autoscaler will fail. It would be good that this autoscaler also provides the ability to create a default ConfigMap when not present, and the default ConfigMap params could(or should) be provided by user.
Here is one specific use case of autoscaler with kube-dns addon of kubernetes:
The plan to use this autoscaler with kube-dns is to make it also an addon and put its manifest into the /addon folder. By doing so, the addon manager will manage its creation and update. A problem will happen to the ConfigMap if we also treat it as an addon resource. Addon manager assumes ownership over all supplied fields in the initial config, which means the user would not be able to modify the autoscale params(ConfigMap) if they don't have the permission to modify the manifests locate on the master node. Without the ability to configure the scaling params, this autoscaler is much less useful.
An obvious way to solve above problem is to only create the ConfigMap once on startup instead of handing over it to the addon manager. But that leads to another issue that what if the ConfigMap got accidentally deleted by user? The autoscaler will be functionless if no one re-create the ConfigMap params.
To make the autoscaling feature both flexible and robust, a quick proposal below:
@bowei @thockin @bprashanth
The text was updated successfully, but these errors were encountered: