Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need to support maintaining default ConfigMap params #7

Closed
MrHohn opened this issue Oct 24, 2016 · 0 comments
Closed

Need to support maintaining default ConfigMap params #7

MrHohn opened this issue Oct 24, 2016 · 0 comments

Comments

@MrHohn
Copy link
Member

MrHohn commented Oct 24, 2016

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.

@bowei @thockin @bprashanth

@bowei bowei closed this as completed in #8 Nov 7, 2016
sftim pushed a commit to sftim/cluster-proportional-autoscaler that referenced this issue Feb 27, 2023
Extract ready/livenessProbe settings to values
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant