Quota And Limits

Every tenant namespace has two things allocated at setup, visible as CRDs:

• CloudekaResourceQuota (rquota) — how much of each product you're allowed to use.

• CloudekaPrice (price) — what each product costs per hour (and per month, where applicable).

Both are set up for you when your namespace is created and are view-only — if you need a limit raised or a price changed, contact the platform team; don't hand-edit these CRs.

What's limited

Product	Quota field	Unit
CPU	cpu	cores (e.g. "4")
RAM	ram	bytes (e.g. "16Gi")
Storage	storage.<class>	per storage class, bytes (e.g. storage-nvme-c1: "100Gi")
GPU	gpu.<model>	per GPU model, count (e.g. NVIDIA-H100-80GB-HBM3: 1)
Floating IP	floatingIP	count
NVAIE (NVIDIA AI Enterprise)	nvaie	count
Other	others.<key>	count
Prepaid balance	quotaBalance	currency units

Check your allocation and live consumption side by side:

kubectl get rquota -n <your-namespace> -o yaml

• spec.* — what you're allocated.

• status.usages.* — what you're currently consuming, recomputed from your running workloads. This updates whenever a Pod, PVC, or Floating IP is created, changes state, or is deleted.

Billing type × charge type

Your CloudekaTenant object (tenant) carries two settings that change how limits are enforced:

billingType	chargeType	Meaning
prepaid	hourly	You have a balance; usage draws it down hour by hour. Can go into further use only while balance allows.
prepaid	hourly_quota_fixed	Both your quota and balance are checked.
prepaid	fixed	Only quota is checked (no balance draw-down).
postpaid	hourly	Usage accrues as debt against your balance (billed after the fact).
postpaid	fixed	Only quota is checked.

kubectl get tenant -n <your-namespace>
# shows: Project, Organization, Billing, Charging, Balance, Updated At

If you're not sure which combination applies to you, kubectl get tenant shows it directly under the Billing/Charging columns.

The 48-hour rule

Before admitting any Pod, PVC, or LoadBalancer Service, the platform doesn't just check "can you afford this resource right now" — it checks whether your balance can cover this resource plus everything else you're already running, for the next 48 hours:

(cost of everything you're running, per hour) × 48  ≤  your balance

This means:

• You can be rejected even if the new resource alone looks affordable, if your existing workloads plus the new one would exhaust your balance within 48 hours.

• Topping up your balance (see Billing & Balance) or reducing running workloads both restore headroom.

• This is a look-ahead check, not the actual charge — the real charge for each hour is computed separately when that hour ends (see billing doc). A rejection here means "you don't have enough runway," not "you were overcharged."

What happens when a limit is hit

The webhook that intercepts your kubectl apply/create rejects the request outright — the object is never created. You'll see the rejection message directly in your terminal or CI output.

Common causes:

• Requesting more CPU/RAM/storage/GPU than your remaining quota.

• Insufficient balance for the 48-hour look-ahead.

• Requesting a storage class or GPU model you have no quota entry for.

See Workload Rules for the exact checks per resource type, and Troubleshooting for the full error-message reference.

Requesting a quota or price change

Quota and price are seeded once at namespace creation and only change when the platform team updates them on your behalf. They push the change to your CloudekaResourceQuota/CloudekaPrice objects, which then syncs back into billing.

Reach out to your platform contact with the new limits you need; don't kubectl edit these objects yourself — an edit that isn't also applied on the platform side will not take effect and may be reverted.