-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
Separate loop and plugin control #52371
Conversation
/assign @wlan0 |
/assign @thockin |
@@ -131,6 +131,7 @@ func (s *CMServer) AddFlags(fs *pflag.FlagSet, allControllers []string, disabled | |||
fs.BoolVar(&s.UseServiceAccountCredentials, "use-service-account-credentials", s.UseServiceAccountCredentials, "If true, use individual service account credentials for each controller.") | |||
fs.StringVar(&s.CloudProvider, "cloud-provider", s.CloudProvider, "The provider for cloud services. Empty string for no provider.") | |||
fs.StringVar(&s.CloudConfigFile, "cloud-config", s.CloudConfigFile, "The path to the cloud provider configuration file. Empty string for no configuration file.") | |||
fs.StringVar(&s.ExternalPlugin, "external-plugin", s.ExternalPlugin, "The plugin to use when cloud provider external. Can be empty, should only be set when cloud-provider is external.") |
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.
Volume plugin to use when Cloud provider is external. Eg.
--external-plugin=aws
(for ebs )
--external-plugin=gce
(for pd) etc.
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 the name say "volume" if it is about volumes? But it's not a volume plugin, it's a cloud plugin. Can we just make this extra extra clear?
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.
I was very confused as well. What @thockin said.
@cheftako Thanks for the PR. Initializing external plugin using the cloud initializer will start the cloud dependent controllers. If the cloudprovider is not null, then the controllers will start. For eg. The service controller uses the With the current PR, I believe the feature we want is for the volume controller only to be started with that cloudprovider if |
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.
What is actually different when you specify --external-plugin
? To me it seems like the behavior of the kcm would be the same...
Can you please explain further why this is needed?
Hi @luxas as @wlan0 mentioned there is a problem in this fix which I am working on fixing but may be making it tougher to understand the point of the fix. As the cloud provider initiative (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cloud-provider-refactoring.md) proceeds kcm should not be running the following controller loops, node, route, service (and volume). We have broken out the first 3 loops from the kcm to the ccm based on the --cloud-provider flag being set to external. Volume is in parentheses because we are still a ways from being ready to break that out. However the cloud provider flag also controls initializing the cloud plugin. Without a working cloud plugin the volume controller loop breaks for volumes of type aws_ebs, gce_pd etc. So the idea is to separate control of which loops are being run from which plugin is being loaded. As @wlan0 points out I missed that we used the existence of the plugin to control the execution of the loops rather than controlling it directly off of the flag itself. |
cc @shashidharatd This will make us able to use the ccm for federation and kube-anywhere :) |
Assign back to me once it is LGTM'ed and ready for approval. |
/test pull-kubernetes-unit |
Seperate loop and plugin control in the kube-controller-manager. Adding an "--external-plugin" flag to specify a plugin to load when cloud-provider is set to "external". Flag has no effect currently when the cloud-provider is not set to external. The expectation is that the cloud provider and external plugin flags would go away once all cloud providers are on stage 2 cloud-controller-manager solutions. Managing the control loops more directly based on start up flags. Addressing issue brought up by @wlan0 Switched to using the main node controller in CCM. Changes to enable full NodeController to start in CCM. Fix related tests. Unifying some common code between KCM and CCM. Fix related tests and comments. Folded in feedback from @jhorwit2 and @wlan0
@cheftako: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
/retest |
/approve no-issue |
/assign @thockin Ready for your review |
/assign @mikedanese /approve |
/approve |
Let's ship it! before we have to rebase :) /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cheftako, dims, mikedanese, wlan0 Associated issue: #52369 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
Automatic merge from submit-queue (batch tested with PRs 56716, 52371). If you want to cherry-pick this change to another branch, please follow the instructions here. |
@cheftako @lavalamp @sttts I think the intent of this pull is create a generic set of controller library code (https://github.com/kubernetes/kubernetes/blob/master/cmd/controller-manager/app/options/utils.go#L30), but a lot of controller specific code has leaked into it (https://github.com/kubernetes/kubernetes/blob/master/cmd/controller-manager/app/options/utils.go#L71-L74 as a for instance). I think we should follow a pattern like we did for the genericapiserver of requiring only generic things be move into common code. Sometimes that forces other refactors to happen first, but it keeps the generic library purer and generally exposes more problems. A few concrete items here need followups:
|
What this PR does / why we need it: Separate loop and plugin control in the kube-controller-manager.
Adding an "--external-plugin" flag to specify a plugin to load when
cloud-provider is set to "external". Flag has no effect currently
when the cloud-provider is not set to external. The expectation is
that the cloud provider and external plugin flags would go away once
all cloud providers are on stage 2 cloud-controller-manager solutions.
Which issue this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close that issue when PR gets merged): fixes #52369Special notes for your reviewer:
Release note: