-
Notifications
You must be signed in to change notification settings - Fork 40k
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
add support to create webhook configuration when webhooks is enabled #120905
base: master
Are you sure you want to change the base?
Conversation
Hi @kmala. 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. |
/sig cloud-provider |
/triage accepted |
CABundle: []byte(webhooksConfig.CaBundle), | ||
} | ||
} | ||
kubeClient := clientBuilder.ClientOrDie("ccm") |
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.
Is ccm
the right client name? I think that name shows up in the audit logs, so I'm wondering if we want a suffix to make it clear what aspect of the ccm is making these calls.
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.
ccm-webhook
?
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.
+1
} | ||
} | ||
} | ||
if webhookConfigs.Len() != 0 { |
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 the behavior here is that we need a 1:1 mapping of enabled webhooks to webhook configs, right? I think that makes sense. The only case I'm thinking of is where a user wants to disable the webhook and reenable it later, but I think its better to force them to remove the config because that way its explicit what webhooks exist based on the configuration and the webhook names.
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.
yes, that correct. Since both are configs provided by the user i felt its better to force to update both places.
// CaBundle is the ca certs to be used by apiserver for validating the webhook server certs. | ||
CaBundle string | ||
// ValidationWebhookConfiguration is the config used for creating validation webhook config object. | ||
ValidationWebhookConfiguration *admissionregistrationv1.ValidatingWebhookConfiguration |
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.
Do we want to allow the user to choose between validating and mutating webhooks on a per-webhook basis?
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.
yeah i think its possible to do it by taking another input here https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/cloud-provider/app/webhooks.go#L56-L59
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.
Per @cheftako we may want to allow providers to choose, but they may not want their customers to choose.
/assign @cheftako |
discussed today at sig cloud provider meetings, needs a few more reviews here. @cheftako has offered to take point on the review requests |
@cheftako can you please review when you get chance |
/ok-to-test |
/retest |
54442a5
to
612c052
Compare
/retest |
737a281
to
9164613
Compare
4a86b5a
to
57f032d
Compare
/test pull-kubernetes-dependencies |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kmala The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest-required |
@kmala: 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. |
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.
this is generally making sense to me, and i don't see anything in the code that is concerning. i would like to play with the unit tests and run this locally to get a feel for how it works.
but i think on balance this is looking good to me
// CaBundle is the ca certs to be used by apiserver for validating the webhook server certs. | ||
CaBundle string | ||
// ValidatingWebhookConfiguration is the config used for creating validation webhook config object. | ||
ValidatingWebhookConfiguration *admissionregistrationv1.ValidatingWebhookConfiguration |
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'm very confused about what is going on here... why are we expecting to apply defaulting from REST APIs to fields of this config file?
@@ -162,6 +168,97 @@ the cloud specific control loops shipped with Kubernetes.`, | |||
return cmd | |||
} | |||
|
|||
func createOrUpdateWebhookConfiguration(ctx context.Context, webhooks map[string]WebhookHandler, webhooksConfig cloudproviderconfig.WebhookConfiguration, clientBuilder clientbuilder.SimpleControllerClientBuilder) error { |
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.
This self-registration of webhooks is really tricky to get right... I had no idea this was being contemplated to be added into cloud-controller-manager
some quick observations:
- it's not clear why having CCM create this programatically is better than applying a manifest
- does having CCM do this mean that multiple CCM controllers duel when the configuration changes?
- is the WebhookAddress expected to point to the CCM instance? how does routing work when there are multiple CCM instances?
- how do multiple CCM controllers handle rollout of a new webhook / configuration? all instances have to understand the new endpoints or fail open when requests to unknown endpoints arrive
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.
great questions @liggitt , i was not aware of the complexity around the self-registration but it makes perfect sense once you've laid it out. i think this might cause us to reconsider the methodology here, it seems like using a manifest would make a better experience for users and help with some of the ordering/dueling issues.
thanks for the review!
currentConfiguration, err := kubeClient.AdmissionregistrationV1().ValidatingWebhookConfigurations().Get(ctx, webhooksConfig.ValidatingWebhookConfiguration.Name, metav1.GetOptions{}) | ||
if err != nil { | ||
klog.ErrorS(err, "Unable to create validating webhook configuration with API server, error getting existing webhook configuration", "webhookconfiguration", webhooksConfig.ValidatingWebhookConfiguration.Name) | ||
return fmt.Errorf("unable to get validating webhook configuration from API server %w", err) | ||
} | ||
currentConfiguration.Webhooks = webhooksConfig.ValidatingWebhookConfiguration.Webhooks | ||
|
||
_, err = kubeClient.AdmissionregistrationV1().ValidatingWebhookConfigurations().Update(ctx, currentConfiguration, metav1.UpdateOptions{}) |
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.
how does this avoid dueling registration from other CCM instances?
// SetDefaults_ValidatingWebhook sets defaults for webhook validating. This function | ||
// is duplicated from "k8s.io/kubernetes/pkg/apis/admissionregistration/v1/defaults.go" | ||
// in order for in-tree cloud providers to not depend on internal packages. | ||
func SetDefaults_ValidatingWebhook(obj *admissionregistrationv1.ValidatingWebhook) { |
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 don't think any defaulting is required here... the defaulting gets applied when creating against the server
PR needs rebase. 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-sigs/prow repository. |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
i think this is still an important feature to work on, but i'm not sure we have the time/resources to push it further currently. /remove-lifecycle stale |
What type of PR is this?
/kind feature
What this PR does / why we need it:
The changes would create/update the validation webhook configuration if webhooks are enabled as part of the cloud controller and is an extension of #108838.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: