The Storage page
A top-level Storage page lists every PVC with:- Live usage from kubelet volume stats, as a bar.
- Days-to-full projection — a trend fit over recent usage (suppressed when a volume isn’t meaningfully filling or is more than ~90 days out).
- The mounting workload, the StorageClass and whether it’s expandable, any active exception, and per-PVC override chips.
- A row-expand usage history chart (used vs capacity over time).
Direct expand
You don’t have to wait for a volume to cross a threshold.POST /api/v1/pvcs/{ns}/{name}/expand
(or the dashboard button) expands any healthy PVC directly. It runs the same safety chain as the
exception-driven expand — a confirm gate, a live re-check that the StorageClass allows expansion,
the target must exceed the current size and stay within any ceiling — plus a 2× growth cap as
a fat-finger guard on an irreversible operation (bypassed only when a per-PVC ceiling explicitly
covers the target).
Every direct expand is audited three ways: a ManualExpand StorageException record (so it’s
visible in the exception history), an operator note, and a Kubernetes Event on the PVC.
Per-PVC overrides
Set annotations on the PVC to tune its behavior without touching the global policy:
Set them from the dashboard (
PATCH /api/v1/pvcs/{ns}/{name}/override) or directly. Removing an
override reverts the PVC to the global policy.
The expand action is deliberately not modeled as an override — an irreversible mutation isn’t
a declarative constraint. Overrides shape future behavior (ceilings, thresholds, auto-expand);
the expand button does the one-time growth.
Shrink protection
A separate mutating webhook (pvcWebhook.enabled) prevents a Helm redeploy from shrinking a PVC
below its current size after Autopilot (or you) expanded it — a common cause of failed
redeploys. It clamps the requested size upward on PVC update.