Ensure old revision stays Unreachable after Knative Service update

[SaschaSchwarze0]

Fixes #14115 by changing how the Knative PodAutoscaler detects whether a ServerlessService is ready.

Before my change, it called the IsReady function of the ServerlessService which is returning false if the generation is different in metadata and status.

Due to it temporarily not being ready, the PodAutoscaler is set to SKSReady=Unknown here.

The PodAutoscaler then goes Ready=False because SKSReady is part of Ready here.

The revision inherits the PodAutoscaler status and sets Active=Unknown here.

This causes the PodAutoscaler's Reachability to be set to Unknown here.

Once the PodAutoscaler is not anymore marked as unreachable, the scaling boundary will be set to the min value from the annotation again here. This will cause a revision that is being not needed anymore to scale up again for a short moment which causes additional pods.

I am changing the logic in the KPA reconciler to directly look at the Ready condition of the ServerlessService instead of calling its IsReady function.

I need somebody with experience in this area to carefully assess if there are side-effects.

/kind bug

Release Note

An Unreachable revision is now not anymore causing additional pods to get created while it is scaled down to 0.

[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 assign creydr for approval. For more information see the Kubernetes Code Review Process.

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

Details

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]

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.

Details

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: 100.00% and project coverage change: -0.04% ⚠️

Comparison is base (e9425f8) 86.26% compared to head (1a13f7b) 86.23%.
Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #14287      +/-   ##
==========================================
- Coverage   86.26%   86.23%   -0.04%     
==========================================
  Files         195      195              
  Lines       14702    14703       +1     
==========================================
- Hits        12683    12679       -4     
- Misses       1719     1723       +4     
- Partials      300      301       +1     

Files Changed	Coverage Δ
pkg/reconciler/autoscaling/kpa/kpa.go	95.28% <100.00%> (+0.02%)	⬆️

... and 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[psschwei]

/cc @dprotaso

[dprotaso]

So I was thinking about simplifying the circular logic in the revision reconciler using an approach where reachability only flows downward and isn't influenced by the child resources.

I have a WIP here - https://github.com/knative/serving/pull/14309/files#diff-7ad1d76110f486046dc682be17600b22d4958b12160852c9f4040ce32f5d8dfc

Surprising all the e2e tests pass without any changes. I think this is because after reachability to the spec we simplified things years later by adding a ScaleTargetInitialized condition.

I'm going to test your specific scenario with those changes.

[dprotaso]

I tested your scenario mentioned here: #14115 and the changes in #14309 did fix it.

[dprotaso]

Closing in favour of #14309