You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: keps/sig-instrumentation/4828-component-flagz/README.md
+8-4Lines changed: 8 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -272,7 +272,7 @@ This section must be completed when targeting beta to a release.
272
272
273
273
This feature should not cause rollout failures. If it does, we can disable the feature. In the worst
274
274
case, it is possible it could cause runtime failures, but it is highly unlikely we would not detect this
275
-
with existing tests.
275
+
with existing tests. The endpoint is isolated and does not affect core workloads.
276
276
277
277
###### What specific metrics should inform a rollback?
278
278
@@ -332,6 +332,7 @@ This is a debugging feature and not something that workloads depend on. Therefor
332
332
###### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
333
333
334
334
This enhancement proposes data that can be used to determine the health of the component.
335
+
(though this endpoint is not intended to be used for alerting.)
335
336
336
337
###### Are there any missing metrics that would be useful to have to improve observability of this feature?
337
338
@@ -347,11 +348,11 @@ No, each component's flagz is independent.
347
348
348
349
###### Will enabling / using this feature result in any new API calls?
349
350
350
-
No
351
+
Yes, enabling this feature will result in a new HTTP endpoint (/flagz) 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 flag information for debugging and observability. No new Kubernetes API objects or resource types are introduced.
351
352
352
353
###### Will enabling / using this feature result in introducing new API types?
353
354
354
-
No.
355
+
No, this feature does not introduce new Kubernetes API types or resources. While the flagz 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.
355
356
356
357
###### Will enabling / using this feature result in any new calls to the cloud provider?
357
358
@@ -381,14 +382,17 @@ flagz endpoint for apiserver will not be available if the API server itself is d
381
382
382
383
###### What are other known failure modes?
383
384
384
-
Overreliance on flagz for critical monitoring. We will clearly document the intended use cases and limitations of the flagz endpoint, emphasizing that it's primarily for informational and troubleshooting purposes, not real-time monitoring or alerting.
385
+
Overreliance on flagz for critical monitoring. We will clearly document the intended use cases and limitations of the flagz endpoint, emphasizing that it's primarily for informational and troubleshooting purposes.
385
386
386
387
###### What steps should be taken if SLOs are not being met to determine the problem?
387
388
388
389
The feature can be disabled by setting the feature-gate to false if the performance impact of it is not tolerable.
389
390
390
391
## Implementation History
391
392
393
+
- 1.32: New `flagz` endpoint introduced for [apiserver](https://github.com/kubernetes/kubernetes/pull/127581)
394
+
- 1.33: `/flagz` enablement extended to [kubelet](https://github.com/kubernetes/kubernetes/pull/128857), [scheduler](https://github.com/kubernetes/kubernetes/pull/128818), [controller-manager](https://github.com/kubernetes/kubernetes/pull/128824), and [kube-proxy](https://github.com/kubernetes/kubernetes/pull/128985)
0 commit comments