Optimize retrieving remainingItemCount from etcd for APIServer List chunking calls for performance gain on etcd

[hakuna-matatah]

Enhancement Description

• One-line enhancement description (can be used as a release note): Optimize retrieving remainingItemCount from etcd for APIServer List chunking calls for performance gain on etcd.
• Kubernetes Enhancement Proposal: WIP
• Discussion Link: Discussed this SIG API Machinery meeting today April 3rd 2024 and got consensus on this from the call
• Primary contact (assignee): @hakuna-matatah
• Responsible SIGs: sig-apimachinery
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.31
  • Beta release target (x.y):
  • Stable release target (x.y):
• Alpha
  • KEP (k/enhancements) update PR(s):
  • Code (k/k) update PR(s):
  • Docs (k/website) update PR(s):

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[hakuna-matatah]

/sig api-machinery

[hakuna-matatah]

/cc @jpbetz

^^^ we discussed today in Sig API-Machinery meeting today

[hakuna-matatah]

/cc @dims

[hakuna-matatah]

/milestone v1.31

[k8s-ci-robot]

@hakuna-matatah: You must be a member of the kubernetes/milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility.

In response to this:

/milestone v1.31

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.

[jpbetz]

Avoiding the cost in etcd of computing count where we don't actually need it SGTM.

The case discussed in the SIG meeting was: When serving continuations of a paginated list, the first request would need to request a count from etcd, but then the subsequent "continue pagination" requests don't need to get the count from etcd again so long as those requests can reuse the count from the first request. Since the continue token is opaque, including the count in the continue token seems like a plausible way to propagate it between requests.

[hakuna-matatah]

Avoiding the cost in etcd of computing count where we don't actually need it SGTM.

The case discussed in the SIG meeting was: When serving continuations of a paginated list, the first request would need to request a count from etcd, but then the subsequent "continue pagination" requests don't need to get the count from etcd again so long as those requests can reuse the count from the first request. Since the continue token is opaque, including the count in the continue token seems like a plausible way to propagate it between requests.

Appreciate for summarizing our conversation :)