kubernetes-sigs / kubernetes-sigs/controller-runtime

Optimize patches returned by Defaulter

Open
#2,800 5 comments 6 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

lifecycle/frozen
Dominant language
Go
Stars
3k
Forks
1.3k
Avg merge
2d 5h
Merged PRs (30d)
14

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing Defaulter and CustomDefaulter patch generation from WithDefaulter, then inspect handling of req.SubResource and req.Object.Raw. Verify the three listed cases, including empty status, and consider how the WithDefaulter option would distinguish status-subresource behavior; done means patches contain only the relevant object sections.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, backend
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.