Kubelet Gets a New /flagz Endpoint

Modern Kubernetes environments are complex. Debugging a misconfigured component often requires searching logs, tracing deployments, or examining configuration files deployed weeks ago. What if you could just ask the component what it’s running with live?

With the Kubernetes v1.33 release, Kubelet now exposes a /flagz endpoint, providing real-time introspection into the exact command-line flags it's running with. This enhancement (as part of KEP-4828: Component Flagz) marks a step forward in observability and operational transparency.

Why /flagz?¶

The goal is simple but powerful: expose the runtime flags of core Kubernetes components, on demand.

This is especially useful for:

• Debugging: You suspect a feature isn’t enabled or configured correctly? Don’t grep logs, just curl /flagz.
• Auditing: After upgrading or restarting a component, verify the actual runtime state reflects your intent.
• Supportability: If you operate large-scale clusters, this offers a clear lens into how each node is configured, without SSHing or relying on historical manifests.

How It Works¶

Once the ComponentFlagz feature gate is enabled, Kubelet exposes a /flagz endpoint over HTTP(S). It’s accessible via:

The response is plain text:

You get the actual runtime values, not default assumptions or config guesses.

Security & Access Control¶

Access is restricted, only users in the system:monitoring group can hit this endpoint. It follows the same model as /livez, /readyz, and /healthz.

Note

No sensitive data is exposed.

Design Philosophy¶

The /flagz endpoint:

• Is built on the existing component-base zpages interface.
• Returns minimal, focused output, just flags and their values.
• Introduces negligible performance overhead since it surfaces static state.
• Can be toggled on/off using the ComponentFlagz feature gate.

Gotchas & Best Practices¶

• Not enabled by default: You must explicitly opt-in via the feature gate.
• Not structured: Do not automate against this endpoint yet. Structured versions may come later.
• Use for inspection, not monitoring: It complements observability, not replaces it.

Broader Context¶

The /flagz enhancement aligns with a broader push in Kubernetes to make core component internals more observable via standard endpoints (/livez, /readyz, /configz, and now /flagz). Future versions may expand this capability to other components such as kube-apiserver, kube-controller-manager, scheduler, and kube-proxy.

What’s Next?¶

As /flagz matures:

• Expect versioned schemas (e.g., /flagz?version=2) for programmatic compatibility.
• It may integrate with broader debugging tooling or diagnostics dashboards.
• Adoption across more components is likely.

Try it out in v1.33 with:

And see what your nodes are really running with, live, from the inside.

If you manage clusters, debug configuration drift, or support multi-tenant platforms, /flagz is a small addition that will likely save you hours.