Use hashing to compare deployment specs for equality

[SaschaSchwarze0]

Fixes #13204

Proposed Changes

We are running Knative at scale with thousands of services. We observed that there are frequent updates of the Kubernetes Deployment related to a Knative Revision. Most of these update operations are no-ops caused by an incorrect assumption that a locally built Deployment spec can be compared with the latest spec from the server object. This does not work because the server object has defaulting applied.

The proposed change

• Introduces an annotation serving.knative.dev/deployment-spec-hash on the Deployment where the hash of the client-side created Deployment spec is stored.
• In case of updates, this hash is used to compare against the newest version.
• In case they are the same, the update call is omitted.

This saves us around 150k Update operations per day in our largest cluster.

Release Note

The revision reconciler now omits updates to the Deployment object when there are no changes to be made

[knative-prow]

Welcome @SaschaSchwarze0! It looks like this is your first PR to knative/serving 🎉

[knative-prow]

Hi @SaschaSchwarze0. Thanks for your PR.

I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

[psschwei]

/ok-to-test

[codecov]

Codecov Report

Patch coverage: 75.67% and project coverage change: -0.06 ⚠️

Comparison is base (6bc4bb2) 86.16% compared to head (aae2e70) 86.11%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #13552      +/-   ##
==========================================
- Coverage   86.16%   86.11%   -0.06%     
==========================================
  Files         197      197              
  Lines       14790    14822      +32     
==========================================
+ Hits        12744    12764      +20     
- Misses       1743     1750       +7     
- Partials      303      308       +5     

Impacted Files	Coverage Δ
pkg/reconciler/revision/resources/deploy.go	87.84% <70.00%> (-2.47%)	⬇️
pkg/reconciler/revision/cruds.go	64.70% <100.00%> (+2.20%)	⬆️

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[evankanderson]

/assign @psschwei @dprotaso

Not sure if we want to be doing this, server-side-apply, checking managedFields, or something else...

[psschwei]

I'd need to think a bit to see if I have any strong opinions on what the best way to do this is... going to add this as an agenda item for the next working group call in case that's easier than discussing here

[dprotaso]

/hold

From: #13204 (comment)

I started to look at server side apply and I believe it could solve the excess upgrades described in this issue as well as allowing two controllers to coordinate reconciling a single resource (tracked here: knative/pkg#2128).

1.9 release is next week but I think this is worth digging into for Knative 1.10 (something that I can do)

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: SaschaSchwarze0
Once this PR has been reviewed and has the lgtm label, please ask for approval from dprotaso. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[knative-prow-robot]

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/test-infra repository.

[github-actions]

This Pull Request is stale because it has been open for 90 days with
no activity. It will automatically close after 30 more days of
inactivity. Reopen with /reopen. Mark as fresh by adding the
comment /remove-lifecycle stale.

[dprotaso]

Going to close this out - I'm actually going to focus on server side apply now which should address this