ITSH Documentation

English

Deutsch

English

Deutsch

Appearance

Billing and quotas ​

CPU and memory are billed on requests, not on usage

You are billed for what your pods declare under resources.requests, not for what they actually consume. A pod requesting 1 vCPU and using 5 % of it still costs a full vCPU.

Why it works that way ​

A request is a reservation. The scheduler places your pod on a node and keeps exactly that capacity free there, whether you use it or not. No other tenant can have it. Reserved capacity is occupied capacity, which is why the request is the number billing is based on.

What counts is the request of a pod that is actually Running, measured over time rather than sampled. A pod bills from the moment it is Running until it stops, at one-minute resolution. So a Job that runs for five minutes is billed five minutes of its requests, not an hour, and a completed pod whose object is still around (retained CronJob history, for instance) is not billed at all.

In practice: over-generous requests are the most expensive mistake you can make in a manifest. It goes unnoticed because nothing breaks. The application runs, utilisation looks relaxed, and only the invoice fails to match the amount of work being done.

The same number drives your quota: a Pending pod almost always means the sum of requests in the namespace is exhausted, not that the applications are consuming too much.

Storage ​

Storage is billed on provisioned PVC capacity, not on bytes written. An empty 100 GiB volume costs the same as a full one.

On block storage (hcloud-volumes) there is also a minimum of 10 GiB per volume: a smaller PVC provisions normally but is billed at 10 GiB. Shared storage (nfs-rwx) has no such floor and is billed at the requested size. The details and the storage classes are under Storage.

Egress ​

Egress is billed on traffic actually transferred, so this is the one place where you really only pay for what flows.

Setting requests properly ​

Omitting requests does not make a pod free

A container that declares no requests is not rejected. Your namespace fills in a default instead, currently 50m CPU and 64Mi of memory, with limits of 200m and 256Mi. You are billed for that default like any other request, and the limits apply whether or not they suit your application. "No requests" therefore means "someone else chose your requests", not "no charge".

  • Set the request to what the application needs in normal operation. Not to the worst-case peak it could theoretically reach.
  • Set the limit above it. The gap between request and limit is your headroom for spikes, and you do not pay for it continuously, because billing follows what is reserved.
  • Do not guess, measure. The portal already did the measuring: the Workloads view compares each workload's request against its actual use over the last seven days and suggests a request that fits, with the saving next to it. See What the portal shows you. If you would rather have it in-cluster, the VPA in recommendation mode (updateMode: "Off", see Autoscaling) collects the same kind of suggestion without changing anything.

Too small is not free either: a CPU request below what the workload needs means less CPU time under contention, because CPU is shared between pods in proportion to their requests. A memory request that is too low makes your pod the first candidate when a node has to reclaim memory. The goal is not the smallest number, it is the honest one.

Paying nothing while nothing runs ​

Because billing follows the requests of running pods, a workload with no pods running costs nothing in CPU and memory. An HTTP service can be set up to drop to zero replicas when nothing calls it and wake on the next request, which is worth doing for anything that is idle most of the day. See Scale-to-Zero.

It lowers the compute part of your bill, not the whole bill. Volumes stay allocated while the pods sleep, so storage and the base fee continue as normal.

What the portal shows you ​

The portal shows what is running and what it costs, without kubectl: quota against your limits, per-workload cost, month-to-date and projected spend, and the floor figure showing what the namespace costs if everything sleeps.

Two things there are worth setting up before you need them: the right-sizing suggestions, which are the fastest way to find an over-provisioned workload, and a spending cap on the namespace. See What the portal shows you.

Quotas and prices ​

The quotas of the free namespace are listed under Free tier.

For the paid tiers, the prices and quotas that apply are the ones on the Kubernetes product page and in the pricing calculator. Your actual usage is in the portal under Kubernetes.

What's next ​