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

Support additional kube-scheduler config parameters via config file #8407

Merged
merged 12 commits into from
Jan 27, 2020

Conversation

rralcala
Copy link
Contributor

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.

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.
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jan 24, 2020
@k8s-ci-robot
Copy link
Contributor

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

@k8s-ci-robot k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 24, 2020
pkg/configbuilder/buildconfigfile.go Outdated Show resolved Hide resolved
pkg/apis/kops/componentconfig.go Outdated Show resolved Hide resolved
pkg/configbuilder/buildconfigfile.go Outdated Show resolved Hide resolved
pkg/configbuilder/buildconfigfile.go Outdated Show resolved Hide resolved
@johngmyers
Copy link
Member

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jan 24, 2020
Copy link
Member

@johngmyers johngmyers left a 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.

pkg/apis/kops/componentconfig.go Outdated Show resolved Hide resolved
@@ -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
Copy link
Member

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()?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

Copy link
Contributor Author

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.

pkg/configbuilder/buildconfigfile.go Outdated Show resolved Hide resolved
pkg/configbuilder/buildconfigfile.go Outdated Show resolved Hide resolved
pkg/configbuilder/buildconfigfile.go Outdated Show resolved Hide resolved
// 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"`
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

pkg/apis/kops/componentconfig.go Outdated Show resolved Hide resolved
pkg/configbuilder/buildconfigfile.go Outdated Show resolved Hide resolved
pkg/configbuilder/buildconfigfile.go Outdated Show resolved Hide resolved
pkg/configbuilder/buildconfigfile.go Outdated Show resolved Hide resolved
rralcala and others added 3 commits January 25, 2020 10:07
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>
@johngmyers
Copy link
Member

/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"`
Copy link
Member

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.

@johngmyers
Copy link
Member

/retest

@rralcala
Copy link
Contributor Author

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!!

@johngmyers
Copy link
Member

/retest

@rralcala
Copy link
Contributor Author

/retest

1 similar comment
@johngmyers
Copy link
Member

/retest

@johngmyers
Copy link
Member

BuildConfigYaml seems a bit specific as it knows that a resource.Quantity gets converted into a float32.

@johngmyers
Copy link
Member

johngmyers commented Jan 25, 2020

I think the e2e test would be best as part of this PR if possible.

@rralcala
Copy link
Contributor Author

rralcala commented Jan 26, 2020

BuildConfigYaml seems a bit specific as it knows that a resource.Quantity gets converted into a float32.

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.

nodeup/pkg/model/kube_scheduler.go Outdated Show resolved Hide resolved
nodeup/pkg/model/kube_scheduler.go Outdated Show resolved Hide resolved
nodeup/pkg/model/kube_scheduler.go Outdated Show resolved Hide resolved
nodeup/pkg/model/kube_scheduler_test.go Outdated Show resolved Hide resolved
pkg/apis/kops/v1alpha2/componentconfig.go Outdated Show resolved Hide resolved
@rdrgmnzs
Copy link
Contributor

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.

@rdrgmnzs
Copy link
Contributor

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
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 27, 2020
@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 27, 2020
@k8s-ci-robot k8s-ci-robot merged commit ace4c60 into kubernetes:master Jan 27, 2020
@k8s-ci-robot k8s-ci-robot added this to the v1.18 milestone Jan 27, 2020
@rifelpet
Copy link
Member

@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:

no kind "KubeSchedulerConfiguration" is registered for version "kubescheduler.config.k8s.io/v1alpha1"

I see in the changelog that KubeSchedulerConfiguration used to be under componentconfig/v1alpha1 but was moved to kubescheduler.config.k8s.io/v1alpha1 in k8s 1.12. Rather than supporting both api groups how about we increase the version check to only use the config file in k8s 1.12?

// 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")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for a followup PR:

Suggested change
useConfigFile := b.IsKubernetesGTE("1.11")
useConfigFile := b.IsKubernetesGTE("1.12")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants