Skip to content

kube-proxy: list available endpoints in /statusz #133190

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

aman4433
Copy link
Contributor

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

This PR adds a list of available HTTP endpoints for the kube-proxy component under the /statusz page. It enhances the visibility of active health/metrics/debug endpoints for instrumentation and operational introspection.
It follows the pattern introduced for other control plane components like kube-apiserver, kube-scheduler, and kube-controller-manager.

Which issue(s) this PR is related to:

Fixes: #133185
Part of umbrella issue: #132474

Special notes for your reviewer:

Tested locally with a custom build of kube-proxy confirming that /statusz correctly shows the listed endpoints.

kube-proxy statusz
Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only.

Started: Thu Jan  1 05:30:00 IST 1970
Up: 487052 hr 18 min 53 sec
Go version: go1.24.0
Binary version: 1.30.0
Emulation version: 1.30
Paths:  /healthz /livez /metrics /proxyMode /readyz

Does this PR introduce a user-facing change?

The `/statusz` page for `kube-proxy` now includes a list of exposed endpoints, making it easier to debug and introspect.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jul 24, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-ci-robot k8s-ci-robot added needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jul 24, 2025
@k8s-ci-robot
Copy link
Contributor

Hi @aman4433. Thanks for your PR.

I'm waiting for a kubernetes 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-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added needs-priority Indicates a PR lacks a `priority/foo` label and requires one. area/kube-proxy sig/network Categorizes an issue or PR as relevant to SIG Network. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jul 24, 2025
@k8s-ci-robot k8s-ci-robot requested review from bowei and danwinship July 24, 2025 20:25
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: aman4433
Once this PR has been reviewed and has the lgtm label, please assign robscott for approval. For more information see the 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:

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

@aman4433
Copy link
Contributor Author

cc: @richabanker

@@ -486,7 +486,15 @@ func serveMetrics(ctx context.Context, bindAddress string, proxyMode kubeproxyco
}

if utilfeature.DefaultFeatureGate.Enabled(zpagesfeatures.ComponentStatusz) {
statusz.Install(proxyMux, kubeProxy, statusz.NewRegistry(compatibility.DefaultBuildEffectiveVersion()))
statusz.Install(proxyMux, kubeProxy, statusz.NewRegistry(compatibility.DefaultBuildEffectiveVersion(),
statusz.WithListedPaths([]string{

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paths are actually path strings from actual handlers, which could be changed separately and bring inconsistency. Wouldn't it be better to introduce constant variables with string or something like that, so that path strings are changed in single place?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the suggestion! Just to confirm — is it okay if I define constants for these paths locally in server.go (e.g., livezPath = "/livez") and reuse them in WithListedPaths()?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here is similar PR, it should help you in some way #133199

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for sharing the reference PR! I’ve updated the code to follow a similar pattern — hope this is what you were expecting. Let me know if anything else needs tweaking!

@ylink-lfs
Copy link
Contributor

Please note that you need to verify the existence of all listed HTTP routes by making localhost requests to each one.

@aman4433 aman4433 force-pushed the kube-proxy-statusz-endpoints branch from 1103f21 to 3d85034 Compare July 27, 2025 12:43
@aman4433
Copy link
Contributor Author

Please note that you need to verify the existence of all listed HTTP routes by making localhost requests to each one.

Thanks for the reminder! Verified each listed endpoint with localhost curl requests:

(base) amanshrivastava@Amans-MacBook-Pro kubernetes % curl localhost:8080/readyz
ok%                                                                                                                                                           
(base) amanshrivastava@Amans-MacBook-Pro kubernetes % curl localhost:8080/livez
ok%                                                                                                                                                           
(base) amanshrivastava@Amans-MacBook-Pro kubernetes % curl localhost:8080/metrics
metrics ok%                                                                                                                                                   
(base) amanshrivastava@Amans-MacBook-Pro kubernetes % curl localhost:8080/statusz

kube-proxy statusz
Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only.

Started: Thu Jan  1 05:30:00 IST 1970
Up: 487116 hr 33 min 25 sec
Go version: go1.24.0
Binary version: 1.30.0
Emulation version: 1.30
Paths:  /healthz /livez /metrics /proxyMode /readyz
(base) amanshrivastava@Amans-MacBook-Pro kubernetes % curl localhost:8080/proxyMode
iptables%                       

@richabanker
Copy link
Contributor

richabanker commented Aug 5, 2025

Ah, sorry for the duplicated effort here, seems like #133239 is already fixing the issue correctly by getting the list of paths from the mux rather than hard coding them.

Edit: Oh this one is for kube-proxy, my bad. Its not duplicated then. But can we make sure to obtain the list of paths from the handler rather than hard code them?

@aman4433
Copy link
Contributor Author

aman4433 commented Aug 7, 2025

Ah, sorry for the duplicated effort here, seems like #133239 is already fixing the issue correctly by getting the list of paths from the mux rather than hard coding them.

Edit: Oh this one is for kube-proxy, my bad. Its not duplicated then. But can we make sure to obtain the list of paths from the handler rather than hard code them?

Thanks for the feedback and for referencing PR #133239.

According to my investigation, the kubelet's approach is possible because its HTTP router (restful.Container) has a public method to get registered paths. From what I could find, kube-proxy's router (PathRecorderMux) doesn't seem to expose a similar method.

This was what prevented me from querying the handler dynamically. I'm very open to other ideas, though. Is there a better approach you're aware of that I might have missed?

@richabanker
Copy link
Contributor

Ah, sorry for the duplicated effort here, seems like #133239 is already fixing the issue correctly by getting the list of paths from the mux rather than hard coding them.
Edit: Oh this one is for kube-proxy, my bad. Its not duplicated then. But can we make sure to obtain the list of paths from the handler rather than hard code them?

Thanks for the feedback and for referencing PR #133239.

According to my investigation, the kubelet's approach is possible because its HTTP router (restful.Container) has a public method to get registered paths. From what I could find, kube-proxy's router (PathRecorderMux) doesn't seem to expose a similar method.

This was what prevented me from querying the handler dynamically. I'm very open to other ideas, though. Is there a better approach you're aware of that I might have missed?

There is a ListedPaths() method for the proxyMux here that you could use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kube-proxy cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/network Categorizes an issue or PR as relevant to SIG Network. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

List available endpoints for kube-proxy's /statusz
5 participants