-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
⚠️ Use and provide a single dynamic rest mapper #2296
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri 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 |
Didn't see the test failure before but looks unrelated /test pull-controller-runtime-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.
one nit, up to you
/retest |
6ac8b0c
to
98137e8
Compare
/retest |
651fe09
to
98d420f
Compare
Signed-off-by: Vince Prignano <vincepri@redhat.com>
@vincepri: The following test 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. |
/lgtm |
provider-kubernetes initialized a new kubernetes client for each reconcile. The REST mapper in controller-runtime used to fetch information about every CRD in the cluster. controller-runtime introduced a lazy restmapper which means we don't have to introduce any complex caching to get a significant performance boost in provider-kubernetes: kubernetes-sigs/controller-runtime#2116 This seems to become the default in the next release: kubernetes-sigs/controller-runtime#2296 But this is so significant that we want to update now: * CPU reduced from constant throttling at 0.4 cores to 0.04 cores * CloudWatch / EKS audit log costs reduced significantly (55% for our cluster, with a lot of provider-kubernetes resources) Signed-off-by: Carl Henrik Lunde <chlunde@ifi.uio.no>
provider-kubernetes initialized a new kubernetes client for each reconcile. The REST mapper in controller-runtime used to fetch information about every CRD in the cluster. controller-runtime introduced a lazy restmapper which means we don't have to introduce any complex caching to get a significant performance boost in provider-kubernetes: kubernetes-sigs/controller-runtime#2116 This seems to become the default in the next release: kubernetes-sigs/controller-runtime#2296 But this is so significant that we want to update now: * CPU reduced from constant throttling at 0.4 cores to 0.04 cores * CloudWatch / EKS audit log costs reduced significantly (55% for our cluster, with a lot of provider-kubernetes resources) Signed-off-by: Carl Henrik Lunde <chlunde@ifi.uio.no>
New changes done to the controller-runtime to make the rest mapper truly lazy in nature now means that the connection is never really validated until the first connection is made. So the current test is basically of no use anymore. Cleaning them up. xref: kubernetes-sigs/controller-runtime#2296
provider-kubernetes initialized a new kubernetes client for each reconcile. The REST mapper in controller-runtime used to fetch information about every CRD in the cluster. controller-runtime introduced a lazy restmapper which means we don't have to introduce any complex caching to get a significant performance boost in provider-kubernetes: kubernetes-sigs/controller-runtime#2116 This seems to become the default in the next release: kubernetes-sigs/controller-runtime#2296 But this is so significant that we want to update now: * CPU reduced from constant throttling at 0.4 cores to 0.04 cores * CloudWatch / EKS audit log costs reduced significantly (55% for our cluster, with a lot of provider-kubernetes resources) Signed-off-by: Carl Henrik Lunde <chlunde@ifi.uio.no>
@vincepri May I ask the background of this PR? Why removed the following options: WithCustomMapper, WithExperimentalLazyMapper, WithLazyDiscovery, and WithLimiter? |
@RainbowMango The options were either outdated, or provided no meaningful additions. Folks can always use their own RESTMapper implementation if they need. For the majority of controller-runtime users, having a single implementation is less error prone. |
New changes done to the controller-runtime to make the rest mapper truly lazy in nature now means that the connection is never really validated until the first connection is made. So the current test is basically of no use anymore. Cleaning them up. xref: kubernetes-sigs/controller-runtime#2296
Hi @vincepri, Do you have any suggestions about how we can adopt the breaking change? PS:
The performance of |
@RainbowMango Overriding the RESTMapper implementation in the manager is still possible with controller-runtime/pkg/manager/manager.go Lines 108 to 112 in 56a973c
|
No description provided.