Instrument flagz and statusz endpoints with apiserver request metrics#137021
Instrument flagz and statusz endpoints with apiserver request metrics#137021k8s-ci-robot merged 2 commits intokubernetes:masterfrom
Conversation
|
I think we should add a changelog entry. |
5e72a6c to
767f8cd
Compare
Updated. |
|
/assign @richabanker |
…rics Use MonitorRequest instead of InstrumentHandlerFunc so that group, version, and deprecated status are derived from content negotiation on each request. For text/plain requests, group and version are empty. For structured responses (JSON/YAML/CBOR), they reflect the negotiated API version (e.g., config.k8s.io/v1alpha1). This ensures accurate metric labels even when clients request deprecated API versions. Add TestMetrics for both endpoints, verifying that requests are recorded in apiserver_request_total with correct label values.
767f8cd to
e728229
Compare
|
/triage accepted |
| "", // resource | ||
| DefaultFlagzPath, // subresource | ||
| "", // scope | ||
| "", // component |
There was a problem hiding this comment.
can we put "apiserver" here? Is that what component is supposed to mean?
There was a problem hiding this comment.
hmmm, the healthz doesn't pass "component" field. But I think we should pass "apiserver" here?
There was a problem hiding this comment.
componentName thats passed to handleFlagz()?
| "", // resource | ||
| DefaultStatuszPath, // subresource | ||
| "", // scope | ||
| "", // component |
There was a problem hiding this comment.
same comment about component
| # HELP apiserver_request_total [STABLE] Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, and HTTP response code. | ||
| # TYPE apiserver_request_total counter | ||
| apiserver_request_total{code="200",component="",dry_run="",group="",resource="",scope="",subresource="/flagz",verb="GET",version=""} 1 | ||
| apiserver_request_total{code="200",component="",dry_run="",group="config.k8s.io",resource="",scope="",subresource="/flagz",verb="GET",version="v1alpha1"} 1 |
There was a problem hiding this comment.
Nit: Its including the "/" that too in subresource.. should that be in resource and without the "/" ?
There was a problem hiding this comment.
I see. Unlike healthz/livez/readyz, flagz and statusz are defined API resources with their own GVK (config.k8s.io/v1alpha1/Flagz and config.k8s.io/v1alpha1/Statusz), so it makes more sense to use resource="flagz" with an empty subresource rather than putting the path in subresource. Updated
|
Few nits about lgtm otherwise. Thanks for the help on adding metrics coverage for these endpoints! |
435226c to
83959a9
Compare
…tusz metrics
Set component label to componentName (e.g., "kube-proxy", "kubelet")
instead of empty string. Move endpoint identifier from subresource to
resource ("flagz"/"statusz") since these are defined API resources with
their own GVK (config.k8s.io/v1alpha1).
83959a9 to
c246753
Compare
|
/retest |
|
/lgtm |
|
LGTM label has been added. DetailsGit tree hash: bdf3f8ff3832572cf54b8dd3d981bebf940c4fca |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: richabanker, yongruilin The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Instruments the /flagz and /statusz endpoints with metrics.InstrumentHandlerFunc so that requests are recorded in apiserver_request_total and apiserver_request_duration_seconds, matching the existing pattern used by /healthz, /livez, and /readyz. This enables operators to detect potential abuse or DDOS of these zpages endpoints via the standard apiserver HTTP metrics.
Which issue(s) this PR is related to:
KEP: kubernetes/enhancements#4828
kubernetes/enhancements#5806 (comment)
Special notes for your reviewer:
The instrumentation follows the exact same pattern as the health endpoints in staging/src/k8s.io/apiserver/pkg/server/healthz/healthz.go. Tests also follow the existing TestMetrics pattern in healthz_test.go.
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: