Skip to content

Update ComponentStatusz milestones and PRR #5611

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Oct 16, 2025
+14 −9
Merged

Update ComponentStatusz milestones and PRR #5611

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 11 additions & 6 deletions keps/sig-instrumentation/4827-component-statusz/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -303,7 +303,7 @@ It will expose the statusz endpoint again

###### Are there any tests for feature enablement/disablement?

Unit test will be introduced in alpha implementation.
Unit and integration tests will be introduced in alpha implementation.

### Rollout, Upgrade and Rollback Planning

Expand All @@ -315,7 +315,7 @@ This section must be completed when targeting beta to a release.

This feature should not cause rollout failures. If it does, we can disable the feature. In the worst
case, it is possible it could cause runtime failures, but it is highly unlikely we would not detect this
with existing tests.
with existing tests. The endpoint is isolated and does not affect core workloads.

###### What specific metrics should inform a rollback?

Expand Down Expand Up @@ -374,7 +374,7 @@ This is a debugging feature and not something that workloads depend on. Therefor

###### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?

This enhancement proposes data that can be used to determine the health of the component.
This enhancement proposes data that can be used to determine the health of the component (though this endpoint is not intended to be used for alerting.)

###### Are there any missing metrics that would be useful to have to improve observability of this feature?

Expand All @@ -390,11 +390,11 @@ No, each component's statusz is independent.

###### Will enabling / using this feature result in any new API calls?

No
Yes, enabling this feature will result in a new HTTP endpoint (/statusz) being served by each component (including apiserver). However, this is not a Kubernetes API type or resource; it is a non-resource endpoint that provides component status information for debugging and observability. No new Kubernetes API objects or resource types are introduced.
Copy link
Member

Choose a reason for hiding this comment

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

IIUC there won't be any new API calls unless a human pings this path (under standardized conditions, these paths shouldn't be machine-consumed, so there won't be any workloads querying this)?

Copy link
Contributor Author

@richabanker richabanker Oct 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Because we are introducing a structured api for this endpoint in 1.35, we are essentially allowing for programatic access via those. So we will have both text/plain format (for human access) and json format (for machine access)

Copy link
Member

Choose a reason for hiding this comment

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

I see, just saw the structured JSON PR and came back here to amend my comment. SGTM.


###### Will enabling / using this feature result in introducing new API types?

No.
No, this feature does not introduce new Kubernetes API types or resources. While the statusz endpoint uses a structured JSON response with Group/Version/Kind for content negotiation and consistency, it is not a Kubernetes API object and is not managed or persisted by the API server. The GVK is used solely to provide a predictable format for clients querying the endpoint.

###### Will enabling / using this feature result in any new calls to the cloud provider?

Expand Down Expand Up @@ -424,13 +424,18 @@ statusz endpoint for apiserver will not be available if the API server itself is

###### What are other known failure modes?

Overreliance on statusz for critical monitoring. We will clearly document the intended use cases and limitations of the statusz endpoint, emphasizing that it's primarily for informational and troubleshooting purposes, not real-time monitoring or alerting.
Overreliance on statusz for critical monitoring. We will clearly document the intended use cases and limitations of the statusz endpoint, emphasizing that it's primarily for informational and troubleshooting purposes.

###### What steps should be taken if SLOs are not being met to determine the problem?

The feature can be disabled by setting the feature-gate to false if the performance impact of it is not tolerable.

## Implementation History
- v1.32: New `/statusz` endpoint introduced for [apiserver](https://github.com/kubernetes/kubernetes/pull/125577),
- v1.33: `/statusz` enablement extended to [kubelet](https://github.com/kubernetes/kubernetes/pull/128811), [scheduler](https://github.com/kubernetes/kubernetes/pull/128987), [controller-manager](https://github.com/kubernetes/kubernetes/pull/128991), and [kube-proxy](https://github.com/kubernetes/kubernetes/pull/128989)
- v1.34: `/statusz` response enhanced to add a `Paths` field listing down all debug endpoints available for [apiserver](https://github.com/kubernetes/kubernetes/pull/132581)
- v1.35: `Paths` field added for [kubelet](https://github.com/kubernetes/kubernetes/pull/133239), [scheduler](https://github.com/kubernetes/kubernetes/pull/132606), [controller-manager](https://github.com/kubernetes/kubernetes/pull/133218), and [kube-proxy](https://github.com/kubernetes/kubernetes/pull/133190)
Copy link
Member

Choose a reason for hiding this comment

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

🎉



## Drawbacks

Expand Down
6 changes: 3 additions & 3 deletions keps/sig-instrumentation/4827-component-statusz/kep.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,13 +19,13 @@ stage: alpha
# The most recent milestone for which work toward delivery of this KEP has been
# done. This can be the current (upcoming) milestone, if it is being actively
# worked on.
latest-milestone: "v1.32"
latest-milestone: "v1.35"

# The milestone at which this feature was, or is targeted to be, at each stage.
milestone:
alpha: "v1.32"
beta: "v1.33"
stable: "v1.34"
beta: "v1.36"
stable: "v1.37"

feature-gates:
- name: ComponentStatusz
Expand Down