-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Support additional kube-scheduler config parameters via config file #8407
Conversation
Mentioned in kubernetes#6942 This change allows using the --config flag and a generated configfile to set options that were not previously supported and the use via flags is deprecated. (https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) I thought that it might be better to have them in a config file to ensure support in newer kubernetes versions. It also makes it easy to add more.
Hi @rralcala. Thanks for your PR. I'm waiting for a kubernetes 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/test-infra repository. |
/ok-to-test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems the code is still calling flagbuilder.BuildFlagsList()
to reflecting the KubeSchedulerConfig
for passing values as flags, as well as having configbuilder.BuildConfigYaml()
to reflect the same KubeSchedulerConfig
to pass the same values in a yaml config file. This is redundant and confusing, likely to lead to problems where a change affects one but not the other. Any given value should be passed as either a flag or in the yaml config file, not both.
I see, different struct tags.
nodeup/pkg/model/kube_scheduler.go
Outdated
@@ -79,6 +82,23 @@ func (b *KubeSchedulerBuilder) Build(c *fi.ModelBuilderContext) error { | |||
}) | |||
} | |||
|
|||
if b.Cluster.Spec.KubeScheduler.KubeConfig == nil { | |||
b.Cluster.Spec.KubeScheduler.KubeConfig = &defaultKubeConfig |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't filling in defaults happen in kops.FillDefaults()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I looked up for this can couldn't find the default, I guess that's why the default was living in this file before the change, so I just kept it.
// Burst sets the maximum qps to send to apiserver after the burst quota is exhausted | ||
Burst *int32 `json:"burst,omitempty" configfile:"ClientConnection.Burst"` | ||
// KubeConfig overrides the default kubeconfig path. | ||
KubeConfig *string `json:"kubeConfig,omitempty" configfile:"ClientConnection.Kubeconfig"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The configfile
tags here and in v1alpha2 seem unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
Co-Authored-By: John Gardiner Myers <jgmyers@proofpoint.com>
Co-Authored-By: John Gardiner Myers <jgmyers@proofpoint.com>
Co-Authored-By: John Gardiner Myers <jgmyers@proofpoint.com>
/retest |
// Qps sets the maximum qps to send to apiserver after the burst quota is exhausted | ||
Qps *resource.Quantity `json:"qps,omitempty" configfile:"ClientConnection.QPS"` | ||
// Burst sets the maximum qps to send to apiserver after the burst quota is exhausted | ||
Burst *int32 `json:"burst,omitempty" configfile:"ClientConnection.Burst"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to change one of the e2e tests to fill in these two values? That would make it more likely we'd detect k/k changing the name or type of these settings.
/retest |
Updated based on feedback, I'm ok with the e2e test, just let me know where it should be part of this PR or a separate one, the other things are addressed, about the generalization, we were facing qps problems with another daemon so I was planning to send that PR as a followup to this one to avoid changing to many things and also propose the overall idea first. Thanks for all the input so far!! |
/retest |
/retest |
1 similar comment
/retest |
|
I think the e2e test would be best as part of this PR if possible. |
flagbuilder.BuildFlagsList does the same and it's used in several places, and I couldn't use floatX in KubeSchedulerConfig so that's why I went with resource.Quantity since I found it being used in other Config structs. |
Hi @rralcala can you add Qps and Burst back to pkg/apis/kops/v1alpha1/componentconfig.go and pkg/apis/kops/v1alpha2/componentconfig.go, that way we can re-gen the api machinery correctly for those API versions. |
Thanks for all the work on the PR and addressing all the comments @rralcala ! We can split the e2e tests in a separate PR, will ping you on Slack directly to get that going. /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rdrgmnzs, rralcala The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@rralcala it looks like this may have caused a regression in our E2E suite when running k8s 1.11 clusters: https://testgrid.k8s.io/sig-cluster-lifecycle-kops#kops-aws-k8s-1.11 @hakman and I found that the error message in the kube-scheduler log is:
I see in the changelog that |
// Build is responsible for building the manifest for the kube-scheduler | ||
func (b *KubeSchedulerBuilder) Build(c *fi.ModelBuilderContext) error { | ||
if !b.IsMaster { | ||
return nil | ||
} | ||
|
||
useConfigFile := b.IsKubernetesGTE("1.11") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for a followup PR:
useConfigFile := b.IsKubernetesGTE("1.11") | |
useConfigFile := b.IsKubernetesGTE("1.12") |
Mentioned in #6942
This change allows using the --config flag and a generated configfile to set
options that were not previously supported and the use via flags is deprecated.
(https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
I thought that it might be better to have them in a config file to ensure
support in newer kubernetes versions.
It also makes it easy to add more.