Storage

Storage

How full your PersistentVolumeClaims are, a warning before a disk fills up, and VolumeSnapshots and Velero backups in plain words — with actions that create a snapshot, restore one to a new claim, back up a namespace or restore a backup. Every action creates one new object after you have seen it; nothing existing is ever changed.

Contents: Volume usage · Where the numbers come from · Disk almost full · Volume snapshots · Velero · How the actions create objects · Permissions

Volume usage

• Persistent Volume Claims table: a Usage column with the percent used, coloured when it is almost full (from 85 %) or critically full (from 95 %).
• A claim's details: a Usage section with space (used of capacity, available) and inodes.
• A pod's details: a Volume usage section with each claim it mounts.

Used is capacity − available, so blocks the file system reserves count as used — the same number Prometheus' KubePersistentVolumeFillingUp alert uses, and the one that matters when writes start to fail. Inodes count the same way (total − free); a volume full of small files can run out of inodes before space. Usage is refreshed every minute while a view that shows it is open.

Not measured means no running pod mounts the claim: only the kubelet of a node where it is mounted measures it.

Where the numbers come from

Source	When
The kubelets (their stats summary, read through the API server)	When you may read nodes/proxy. Sextant asks at most 8 nodes at a time; a node that does not answer is named, and the claims mounted there are missing.
Prometheus (kubelet_volume_stats_*)	When nodes/proxy is not allowed or no node answers, and the cluster has a Prometheus (see the cluster's Metrics settings in Settings). The view says it uses Prometheus and why.
Neither	The view says why usage cannot be read. Snapshots and Velero still work.

Disk almost full

Disk almost full is a kind of problem that is off until you turn it on in Settings → General → Notifications (Notify about). When on, a claim at or over the warning or critical level, of space or of inodes, is a problem of that claim on the Problems page, and a desktop notification is sent when it first crosses a level. The levels are set in the same section under Volume usage:

Setting	Default
Almost full from this percent used	85
Critically full from this percent used	95

See Problems and notifications.

Volume snapshots

When the cluster has the snapshot CRDs, the sidebar shows Volume Snapshots with Volume Snapshots, Volume Snapshot Classes and Volume Snapshot Contents: state (ready, pending, failed), source claim, class, restore size, driver, deletion policy, and in plain words why a snapshot is not ready ("No VolumeSnapshotContent is bound yet: check that the snapshot controller runs and that the class exists").

• Create snapshot… on a bound claim: a name and a VolumeSnapshotClass (by default the class of the claim's CSI driver, or the driver's default class).
• Restore to a new PVC… on a ready snapshot: a new claim in the snapshot's namespace (a snapshot can be restored only there), with a size of at least the snapshot's restore size, a StorageClass and an access mode. The original claim is never touched.

Velero

When Velero is installed, the sidebar shows Velero with Backups, Schedules, Restores, Backup Storage Locations and Volume Snapshot Locations: phase, error and warning counts, what failed and where to look (velero backup logs <name>), schedules and their last backup, locations and when they were last validated.

• Back up namespace… on a namespace: a Velero Backup of that namespace in Velero's namespace (found by its Backup Storage Locations), with a time to keep it (TTL, Velero's default 720h0m0s = 30 days) and a storage location. The backup runs in Velero, not in Sextant.
• Restore from this backup… on a backup: a Velero Restore, optionally into other namespaces (leave a field empty to keep the name). Velero skips most objects that already exist and counts them as warnings; some kinds, such as ServiceAccounts, are merged. If the backup is not Completed, the dialog warns that the restore may be partial.

Sextant never runs the velero program.

How the actions create objects

1. You fill in the form.
2. Review shows the one object that will be created, with its YAML.
3. Create sends it once, as a create — not an apply. If an object of that name already exists (also one created a moment ago by someone else), the cluster refuses and Sextant says … already exists: nothing was changed. Choose another name.

A failed or timed-out create is never repeated by Sextant.

Permissions

You need get on nodes/proxy for kubelet usage (or a Prometheus), list on the claims and snapshots, and create on the object an action makes. AI agents (MCP) and extensions get none of these actions or the usage readings.