Repository navigation
Optimize patches returned by Defaulter #2800
Description
Today our Defaulter and CustomDefaulter implementations always compare the entire req.Object.Raw with the object mutated by the Default func.
The result is that we always return patches for metadata, spec and status if there are differences including cases where e.g. the status marhals to an empty object. For example in the latter case the webhook returns a patch to add an empty status object.
We have the following cases where the Defaulter webhook is called:
- CRs without status subresource
- for the entire object => we actually have to return patches for the entire object (correct as of today)
- CRDs with status subresource
- for spec & metadata => we should only return patches for spec & metadata (today we also return patches for status)
- I'm not aware of any way to detect this at runtime, we could maybe introduce an option on the
WithDefaulterfunc.
- I'm not aware of any way to detect this at runtime, we could maybe introduce an option on the
- for status => we should only return patches for status (today we also return patches for spec & metadata)
- We should be able to optimize this by dropping all non-status patches if
req.SubResource == "status"
- We should be able to optimize this by dropping all non-status patches if
- for spec & metadata => we should only return patches for spec & metadata (today we also return patches for status)
The reason why I'm bringing this up is because I've noticed that in a lot of cases our Cluster API webhooks are returning patches for status fields that are never used (and eventually discarded by the apiserver). Would be better if we don't return those patches in the first place. If we only compare the relevant parts of the object we should be also able to slightly improve the performance of the webhooks.
Activity
k8s-triage-robot commentedon Jul 28, 2024
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/remove-lifecycle stale/closePlease send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
sbueringer commentedon Jul 29, 2024
/lifecycle frozen
alvaroaleman commentedon Sep 29, 2024
Would't it be possible to solve this by constructing the Patch not with
req.Obj.Rawas base but with the result ofh.decoder.Decode(req, obj)before mutating it?That would accurately capture the differences that the validator actually made, rather than potentially also including a bunch of unrelated stuff due to go type not perfectly matching with the configured CRD.
sbueringer commentedon Sep 30, 2024
I think this will lead to other problems. See the first two comments in this thread: #2931 (comment)
Basically the patches then won't be generated based on the actual JSON anymore, so then there are cases where the apiserver won't be able to apply the JSON patches.
trasc commentedon Oct 14, 2024
@sbueringer @alvaroaleman I've opened #2982 , in it, the approach is similar to the one in #2931, but we only make sure that the removals that are generated by the object decoding are not part of the final patch.
Additionally, we can make this behavior optional and maybe add some warnings in result indicating which fields wold have bean removed by the decoding itself.