Kubernetes Introduces /statusz for Debugging Components
When you're deep in troubleshooting a production issue, the last thing you want to do is sift through logs, decode binary versions, or chase down build metadata. Kubernetes is addressing that pain point with a new feature proposed in KEP-4827: the /statusz endpoint. Inspired by Google’s internal z-pages, this endpoint aims to expose real-time, low-overhead component diagnostics across Kubernetes control plane components.
What is /statusz?¶
/statusz is a lightweight, authenticated HTTP endpoint that returns plain-text diagnostic data about a Kubernetes component, version info, uptime, build metadata, and links to health endpoints, all in one place. It’s a status snapshot for the component itself, not the cluster, and it’s strictly read-only.
Example response:
Started: Fri Sep 6 06:19:51 UTC 2024
Up: 0 hr 00 min 30 sec
Go version: go1.23.0
Binary version: 1.31.0-beta.0.981+c6be932655a03b-dirty
Emulation version: 1.31.0-beta.0.981
Minimum Compatibility version: 1.30.0
List of useful endpoints
--------------
configz:/configz
healthz:/healthz
livez:/livez
metrics:/metrics
readyz:/readyz
sli metrics:/metrics/slisWhy It Matters¶
Whether you're a developer, SRE, or support engineer, /statusz can help answer questions like:
- What Go version is this binary running with?
- Has someone deployed a dev build by mistake?
- Is this version compatible with the rest of the control plane?
Before this, answering those questions often meant shell access, log diving, or custom debug tooling. With /statusz, it’s a single curl away.
Who Can Access It?¶
Access is secured via Kubernetes RBAC, specifically the system:monitoring group, just like existing endpoints such as /healthz or /metrics. That means only authorized tools and personnel can see it, avoiding any unintentional exposure.
For example, to allow access to kubelet’s /statusz:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: system:monitoring
rules:
- apiGroups: [""]
resources: ["nodes/statusz"]
verbs: ["get"] Feature Lifecycle¶
- Alpha: Feature gated via
ComponentStatusz; opt-in required. - Beta: Expanded to more components beyond
apiserver. - GA: Hardened with SLO guarantees, testing coverage, and real-world feedback.
Importantly, this feature doesn’t replace metrics or tracing. It complements them by exposing debug-relevant details from within the component, without needing external monitoring or service dependencies.
Safe by Design¶
- No sensitive data is exposed.
- Auth enforced by default.
- Format is plain-text only for now, explicitly non-machine-parseable to discourage misuse.
- Future schema versions will be opt-in via
/statusz?version=2.
Summary¶
If you’ve ever asked “What version of kubelet is actually running on that node?” and didn’t have an easy answer, this feature is for you. /statusz offers a simple yet powerful window into component internals, built natively into Kubernetes.
With performance safeguards, strict access controls, and low operational overhead, it's another step toward making Kubernetes more transparent and operable, especially when it matters most.
FAQs
What is the /statusz endpoint introduced in Kubernetes?
/statusz is a new authenticated, read-only HTTP endpoint that exposes runtime diagnostic information about a Kubernetes component. It includes build metadata, Go version, uptime, and links to related endpoints, helping operators quickly inspect the component's internal status.
Why is /statusz useful for debugging and operations?
It answers key questions, like which binary version is running, how long the component has been up, and whether a dev build was deployed, without needing shell access or log inspection. This simplifies root cause analysis and accelerates production troubleshooting.
Who can access /statusz, and is it secure?
Access is restricted via Kubernetes RBAC. Only users or services in the system:monitoring group (or with explicitly granted roles) can access it, similar to /healthz and /metrics. No sensitive data is exposed.
What is the current state of the /statusz feature and how is it enabled?
As of its introduction, /statusz is an alpha feature gated by ComponentStatusz. It must be explicitly enabled on the target component (e.g., kubelet, kube-apiserver) via the appropriate feature gate.
Does /statusz replace existing observability tools like metrics or tracing?
No. /statusz complements, but does not replace, metrics or tracing. It focuses on real-time introspection of the component's own runtime metadata—not on cluster state, performance trends, or distributed tracing data.
