Native histograms are now a default behavior in v1.37 — and that single change will force platform teams to rethink how they ingest, store, and query Kubernetes metrics. For years most Kubernetes metric consumers relied on client-side bucketization (or series-per-bucket) patterns exported from components; with a KEP graduating to Beta and enabled by default, components and the control plane can expose histogram metrics natively. That both simplifies accurate percentile math and shifts cardinality and storage costs into your collection tier.
Why native histograms matter
Native histograms change the economics of observability. If your Prometheus stack, remote-write pipeline, or long-term store expects the historic "one-series-per-bucket" model, you'll see a different shape of data: fewer high-cardinality per-bucket series but more native histogram series that ingestion and query systems need to interpret correctly (and some systems still struggle with histogram semantics). This is the right call from the Kubernetes side — metric correctness should be a primitive — but it's going to bite teams who haven't modernized their ingest path. Expect to upgrade exporters, validate remote-write adapters, and confirm your alerting and dashboards interpret histogram metrics for percentiles instead of using approximation hacks.
If you want a quick refresher on how the community is talking about this change, see our earlier coverage: Kubernetes: Native Histograms Beta Enabled by Default.
PVC last-used becomes an actionable signal
v1.37 also promotes a PVC "last used" timestamp to Beta and enables it by default. This is underrated operationally. Having a reliable, API-level timestamp for when a PVC was last used turns brittle cleanup heuristics into a defensible policy signal. Garbage-collection controllers, reclaim workflows, and chargeback automation can now make TTL decisions based on an authoritative field instead of approximate pod annotations or volume-provisioner logs.
In practice, platform teams should start wiring this timestamp into lifecycle jobs and reclaim controllers. For clusters with heavy ephemeral-workload churn (CI runners, data-processing jobs), using the PVC unused timestamp reduces storage waste and the accidental deletion of still-in-use volumes caused by racey heuristics. We ran the numbers internally: even conservative TTLs paired with PVC last-used reduced lingering volumes by a measurable margin.
Pod-Level Resource Managers: beta but opt-in — and why that matters
Pod-Level Resource Managers graduate to Beta in v1.37 but remain disabled by default. This feature gives kubelet richer primitives to manage resources at pod granularity (think: coherent pod QoS and cross-container resource orchestration). Leaving it off by default is reasonable — the surface area interacts with cgroup v2 behavior, node-level schedulers, and eviction policies — but I think the project is being too timid. We need more teams experimenting with pod-level management in staging clusters now; the sooner real-world feedback lands, the sooner node scheduling and QoS semantics stabilize.
Operational checklist (short)
- Audit your metric ingestion: verify histogram-compatible remote-write and SLI/alerting code paths.
- Update exporters and dashboards to consume native histogram series for percentiles.
- Integrate the PVC last-used timestamp into reclaim or cleanup controllers; treat it as authoritative.
- Pilot Pod-Level Resource Managers in non-production to exercise eviction and QoS semantics before enabling in prod.
This week's practical action items live squarely in cluster ops and observability teams: change your metrics pipeline and add PVC-last-used to your cleanup playbooks.
Final thought: enabling native histograms and PVC last-used by default signals that Kubernetes is moving problems upstream — giving primitives, not policies. Platform teams who treat these as mere checkbox upgrades will get surprised. Teams that treat them as new telemetry and lifecycle primitives will get cleaner observability and vastly less storage debt. Which side are you on?