🐛 reconciler/apibinding: make group resources of APIBindings + CRD race-free

[sttts]

Summary

The conflict checker in the APIBinding reconciler computed a list of CRDs, both real and bound ones. It took the APIExport as reference instead of the bindings directly. This seems wrong. If a schema is removed from an export, or the whole export is deleted, the binding still exists, but it didn't contribute the conflict checker anymore.

This PR does the following:

1. make the conflict checker use the APIBinding.status.boundResources as reference.
2. store group resource bindings in an apis.kcp.io/resource-bindings annotation on the LogicalCluster. It records the APIBinding or whether it is a CRD. This annotation (a JSON map) is updated BEFORE (a) a CRD is created (admission) or (b) an APIBinding bind the group resource:

   internal.apis.kcp.io/resource-bindings: '{"partitions.topology.kcp.io":{"n":"topology.kcp.io"},"partitionsets.topology.kcp.io":{"n":"topology.kcp.io"},"shards.core.kcp.io":{"n":"shards.core.kcp.io"},"workspaces.tenancy.kcp.io":{"n":"tenancy.kcp.io"},"workspacetypes.tenancy.kcp.io":{"n":"tenancy.kcp.io"}}'

The tricky case is that we can only update the annotation during CRD creation via admission. And creation can fail. Then we have a dangling group resource reservation. This PR adds an expery timestamp to the group resource entries for CRD which matches the maximum request duration of 30s. For that time an APIBinding of the same group resource would fail (delayed). Don't know a better way to solve that.

Downside: CRD creation implies update of the LogicalCluster, with potential for conflicts. This might make CRD creation slower. So if you install 1000 CRDs, this PR will have an impact.

Related issue(s)

Fixes #3252

Release Notes

Fix critical race condition between APIBindings and CRDs potentially allowing the same resource to be bound by multiple bindings or CRDs, leading to data loss or inconsistent state.

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from sttts. 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
• pkg/admission/OWNERS
• sdk/apis/OWNERS

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

[embik]

/retest

[mjudeikis]

/build-image

[kcp-ci-bot]

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.

[yastij]

/cc