# Kubelet Gets a New /flagz Endpoint
> Discover how Kubernetes v1.33 introduces a new /flagz endpoint in Kubelet for runtime introspection of component flags, debug like never before.

Canonical: https://blog.abhimanyu-saharan.com/posts/kubelet-gets-a-new-flagz-endpoint
Published: 2025-05-17
Last updated: 2025-05-24
Authors: Abhimanyu Saharan
Categories: Kubernetes v1.33, Kubernetes

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](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/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:

```sh
kubectl get --raw "/api/v1/nodes/<node-name>/proxy/flagz"
```

The response is plain text:

```
title: Kubernetes Flagz
description: Command line flags that Kubernetes component was started with.

address=0.0.0.0
anonymous-auth=true
container-runtime-endpoint=unix:///var/run/containerd/containerd.sock
cpu-cfs-quota=true
enable-server=true
...

```

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: 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**:

```yaml
--feature-gates=ComponentFlagz=true
```

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.

## FAQ

### What is the /flagz endpoint introduced in Kubernetes v1.33?

`/flagz` is a new HTTP(S) endpoint exposed by the Kubelet that displays its active command-line flags at runtime. It allows operators to introspect live configuration without accessing logs or manifests, improving transparency and debugging.

### How do I enable the /flagz endpoint in Kubelet?

You must enable the `ComponentFlagz` feature gate on the Kubelet. Once enabled, the Kubelet will expose the `/flagz` endpoint alongside standard health endpoints like `/livez` and `/readyz`.

### Who can access the /flagz endpoint and is it secure?

Access is restricted to users in the `system:monitoring` group. The endpoint follows the same RBAC model as other introspection endpoints, ensuring controlled, read-only access to configuration details.

### What are the current limitations of /flagz?

- It is not enabled by default
- The output is unstructured plain text, not intended for automation
- It should be used for one-off inspection, not continuous monitoring

### What is the broader goal behind introducing /flagz?

The `/flagz` endpoint is part of a larger observability effort (like `/livez`, `/readyz`, and `/configz`) to make Kubernetes components self-report their runtime state. It supports easier debugging, auditability, and eventual integration with diagnostics tools.