Optimize patches returned by Defaulter

[sbueringer]

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 WithDefaulter func.
  • 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"

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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[sbueringer]

/lifecycle frozen

[alvaroaleman]

Would't it be possible to solve this by constructing the Patch not with req.Obj.Raw as base but with the result of h.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]

Would't it be possible to solve this by constructing the Patch not with req.Obj.Raw as base but with the result of h.decoder.Decode(req, obj) before mutating it?

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]

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