KEP: New kubelet gRPC API with endpoint returning local pods information

[kl52752]

Enhancement Description

• One-line enhancement description (can be used as a release note): New kubelet gRPC API with endpoint returning local pods information
• Kubernetes Enhancement Proposal: KEP-4188: New kubelet gRPC API with endpoint returning local pods information #4184
• Discussion Link: KEP was discussed at SIG-Arch meeting on 24th August, 2023 and SIG-Node meeting on 29th August link.
• Primary contact (assignee): kl52752
• Responsible SIGs: sig-node, sig-architecture
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.29
  • Beta release target (x.y): 1.30
  • Stable release target (x.y): 1.31
• Alpha
  • KEP (k/enhancements) update PR(s): KEP-4188: New kubelet gRPC API with endpoint returning local pods information #4184
  • Code (k/k) update PR(s):
    • Move grpc rate limiter from podresource folder kubernetes#121019
    • Add proto file for gRPC pod-status service kubernetes#121026
  • 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.

[kl52752]

/sig node

[k8s-ci-robot]

@kl52752: The label(s) sig/arch cannot be applied, because the repository doesn't have them.

In response to this:

/sig arch

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.

[kl52752]

/sig architecture

[SergeyKanzhelev]

/stage alpha
/milestone v1.29
/label lead-opted-in

[SergeyKanzhelev]

/milestone v1.29

[AnaMMedina21]

Hola @kl52752👋, v1.29 Enhancements team here.

I am just checking in as we approach enhancements freeze on 18:00 PDT on Thursday 6th October 2023..

This enhancement is targeting for stage alpha for v1.29 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP readme using the latest template has been merged into the k/enhancements repo. [waiting on KEP-4188: New kubelet gRPC API with endpoint returning local pods information #4184]
• KEP status is marked as implementable for latest-milestone: { v1.29}. KEPs targeting stable will need to be marked as implemented after code PRs are merged and the feature gates are removed.
• KEP readme has up-to-date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements. (For more information on the PRR process, check here). [waiting on KEP-4188: New kubelet gRPC API with endpoint returning local pods information #4184]

The status of this enhancement is marked as Tracked for Enhancements Freeze. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

[AnaMMedina21]

Hey @kl52752 👋, v1.29 Enhancements team here, checking in once more as we approach the v1.29 enhancement freeze deadline on 01:00 UTC, Friday, 6th October 2023. The status of this enhancement is marked as Tracked for Enhancements Freeze. It looks like #4184 is still open but it seems to be small edits to close it out. Let me know if I missed anything. Thank you!

[kl52752]

hi @AnaMMedina21 The PR for KEP was merged, yesterday

[taniaduggal]

Hey there @kl52752 ! 👋, v1.29 Docs team shadow here.
Does this enhancement work planned for v1.29 require any new docs or modifications to existing docs?
If so, please follow the steps here to open a PR against dev-1.29 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before Thursday, 19 October 2023.
Also, take a look at Documenting for a release to get yourself familiarized with the docs requirement for the release.
Thank you!

[taniaduggal]

Hey there @kl52752 !, The deadline to open a placeholder PR against k/website for required documentation is Thursday, 19 October. Could you please update me on the status of docs for this enhancement? Thank you!

[taniaduggal]

Hey @kl52752 , Could you please update me on the status of docs for this enhancement? Thank you!

[kl52752]

hi @taniaduggal I don't think I will finish the feature work for 1.29 so I will not add this to the documentation.

[npolshakova]

Hi @kl52752, 1.29 Enhancements team here- thanks for letting us know, I'll remove this KEP from the tracking board.
/milestone clear

[salehsedghpour]

/remove-label lead-opted-in

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[aojea]

@kl52752 @wojtek-t if in addition to the conditions we expose the status.PodIPs we solve one scalability problem with networking component that need to watch for this information, can we add them in addition to the conditions?

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[SergeyKanzhelev]

/remove-lifecycle rotten

As far as I know, activity on this one is on pause now. But it is still a desireable feature to have

[SergeyKanzhelev]

Before re-starting this KEP, we need to reevaluate more feedback. Specifically this from @deads2k

#4184 (comment)

I re-found this while having a look at https://github.com/kubernetes/enhancements/pull/4615/files and noticing that it was also dealing with the power and limitations of the existing grpc kubelet endpoint. In particular, I noticed that

1. there is more than one resource needed for read powers from the kubelet
2. even with a single resource, partitioning between the clients is desired (authentication)
3. the clients using the existing grpc extension are trying tunnel http over the grpc to be able to re-use the existing client and controller libraries. Even the APIs don't match exactly, the dynamic client and controller libraries still operate extremely well.
4. versioning of APIs is important for adoption and to allow old and new extensions to coexist

As I recall, versioning was well handled by this design, but the trajectory of resource grpc endpoint could inform future kubelet serving extensions.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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-sigs/prow repository.

[SergeyKanzhelev]

/reopen
/remove-lifecycle rotten

I believe this is still desirable feature

[k8s-ci-robot]

@SergeyKanzhelev: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle rotten

I believe this is still desirable feature

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-sigs/prow repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[SergeyKanzhelev]

/remove-lifecycle stale

this is still a desirable API