Storage and cost surprises

A PVC stays Pending

kubectl get pvc
kubectl describe pvc <name>

The storage class name is wrong. The read-write-many class is nfs-rwx, not nfs. A PVC naming a class that does not exist waits forever without an error, because Kubernetes assumes the class might appear later. You cannot list the classes to check, so the two names are on Storage.

You are on the free tier and asked for block storage. That one is refused at apply time rather than left pending, see The API said no.

Nothing is mounting it yet. The default class binds on first use, so a PVC with no pod attached stays Pending and that is correct. It binds when a pod mounts it.

The quota is full. Storage counts against your namespace quota like everything else.

A volume keeps growing

Autoresize is doing exactly what you configured, and the configuration usually means the opposite of what was intended.

resize.topolvm.io/threshold is free space, not used space.

• "20%" means: grow when less than 20% is free, that is at 80% full. This is what you want.
• "80%" means: grow when less than 80% is free, that is at 20% full. The volume expands almost immediately, then keeps expanding step by step up to storage_limit, and you pay for all of it while it was never close to full.

Check what yours says:

kubectl get pvc <name> -o jsonpath='{.metadata.annotations}'

A volume can never shrink. Not by autoresize, not by lowering resources.requests.storage by hand. To get smaller, create a new PVC, copy the data across, and delete the old one.

Autoresize also does nothing on nfs-rwx. If you set the annotations there and nothing happens, that is why.

The invoice is higher than expected

Start from the portal, which shows per-workload cost and a projection for the month. Then check these, in the order they usually turn out to be the cause.

You are billed on requests, not usage. A pod requesting 1 vCPU and using 5% of it costs a full vCPU. Over-generous requests are the most expensive thing you can put in a manifest, and nothing breaks to tell you: the application runs fine, utilisation looks relaxed, and only the invoice is wrong.

The portal computes a suggested request per workload from actual usage over seven days. That is the fastest way to find the gap.

A container with no requests is not free. It gets a namespace default and is billed for it.

kubectl top pods

Compare that against what your manifests ask for.

Storage is billed on provisioned capacity, not bytes written. An empty 100 GiB volume costs the same as a full one. On hcloud-volumes there is also a 10 GiB minimum per volume, so five 2 GiB block volumes cost the same as five 10 GiB ones. nfs-rwx has no minimum.

A sleeping workload still has volumes. Scale-to-zero removes the CPU and memory charge, not the storage or the base fee. A namespace with a 20 GiB volume that sleeps all month still pays for that volume.

Something is holding a workload awake. See Scaling does not do what you expect.

What's next

• Billing and quotas for how the meter works
• Storage for classes and autoresize