Skip to main content
11.08.2026

Kubernetes v1.37 Storage Health Checks

head-image

The Kubernetes v1.37 sneak peek is useful reading for teams planning the next upgrade window. Some items are deprecations, such as kube-proxy IPVS mode warnings and the long cgroup v1 exit path. The most interesting reliability feature is Volume Health Monitor, because storage failures are still too often diagnosed through symptoms instead of clear Kubernetes status.

What Is Volume Health Monitor?

Volume Health Monitor lets CSI drivers report health back into Kubernetes objects. Instead of forcing operators to compare pods, PVCs, kubelet logs, CSI logs, and vendor dashboards by hand, the cluster can expose volume health in standard status fields.

The v1.37 plan resets the feature to alpha and introduces CSI calls for controller-side and node-side health. Controller plugins can list unhealthy volumes or check a specific volume. Node plugins can report mounted volume health and storage driver health on a node.

Why SRE Teams Should Care

Storage incidents are noisy. A pod may sit in ContainerCreating, an application may report I/O timeouts, or a rollout may stall because a volume attach path is degraded. Without a standard health signal, responders burn time finding the layer that actually failed.

Kubernetes v1.37 points toward clearer signals:

  • PersistentVolumeClaim.status.healthStatus for controller-side volume health
  • Pod.status.volumeHealth for volume health observed by kubelet
  • CSINode.status.storageHealth for storage driver health on each node
  • simple states such as Inaccessible and Degraded
  • optional reason and message fields for driver-specific detail

That gives alerting and remediation controllers something better than log scraping.

Upgrade Notes

Start by inventorying CSI drivers. Volume health only helps when the driver implements the new RPCs, so managed storage, self-managed CSI deployments, and cloud-provider add-ons may move at different speeds. Add checks for PVC health, pod volume health, and CSINode storage health beside the existing pod event and CSI controller log steps.

Finally, watch the neighboring v1.37 changes. If nodes still rely on cgroup v1, plan that migration before it becomes urgent. If kube-proxy runs in IPVS mode, start testing nftables or iptables mode now.

Operational Tips

Treat storage health as an input, not an automatic fix. A Degraded volume should page differently from a failed attach, and remediation should respect workload state, backup freshness, and application restart tolerance.

Add health fields to incident snapshots. When an on-call opens a case, capture pod status, PVC status, CSINode status, storage class, driver version, and recent node events together. That makes storage failures easier to compare across incidents.

Conclusion

Kubernetes v1.37 is a good release to review storage observability, node readiness, and old networking assumptions. Volume Health Monitor is still alpha, but it points in the right direction: clearer storage failure signals that SRE teams can alert on, reason about, and eventually automate.

If your team wants AI-assisted incident workflows built on reliable Kubernetes context, Akmatori helps SRE teams investigate alerts, coordinate response, and automate safe infrastructure actions. Powered by Gcore for global infrastructure reliability.

Automate incident response and prevent on-call burnout with AI-driven agents!