Seeing your allocation

Before you start

• You have a working kubelogin session — see Install kubelogin if you have not set up OIDC login yet.
• You understand the shared pool model — all namespaces in your tenant pull from the same ResourcePool.

Checking your ResourcePool

Two kubectl commands answer the “how much have I used” question:

List your ResourcePool

kubectl get resourcepool

This returns the ResourcePool backing your tenant. The ResourcePool is cluster-scoped — there is one pool per tenant, shared across every namespace the tenant owns. Because it is cluster-scoped, the command takes no namespace; passing -n is ignored.

Describe the pool

kubectl describe resourcepool <pool-name>

The output shows your quota and current usage broken out by resource type (trimmed to the relevant fields):

Spec:
  Quota:
    Hard:
      limits.cpu:        8
      limits.memory:     16Gi
      requests.cpu:      8
      requests.memory:   16Gi
      requests.storage:  50Gi
  Selectors:
    Match Labels:
      capsule.clastix.io/tenant:  def-profname
Status:
  Allocation:
    Available:
      limits.cpu:        5
      limits.memory:     10Gi
      requests.cpu:      6
      requests.memory:   12Gi
      requests.storage:  30Gi
    Hard:
      limits.cpu:        8
      limits.memory:     16Gi
      requests.cpu:      8
      requests.memory:   16Gi
      requests.storage:  50Gi
    Used:
      limits.cpu:        3
      limits.memory:     6Gi
      requests.cpu:      2
      requests.memory:   4Gi
      requests.storage:  20Gi
  Namespace Count:  2
  Namespaces:
    def-profname-experiments
    def-profname-prod

• Hard (under Spec → Quota) is the ceiling — the maximum your tenant’s workloads can claim across all namespaces.
• Status → Allocation is the live view: Hard repeats the ceiling, Used is what your workloads currently claim (the requests and limits of every non-terminal Pod, plus all PVC sizes) across the whole tenant, and Available is Hard minus Used.
• Namespaces lists every namespace currently drawing from the pool.

To see usage scoped to a single namespace rather than the whole tenant, describe the ResourceQuota in that namespace:

kubectl describe resourcequota -n <your-tenant>-<a-namespace>

The ResourcePool resource is Capsule-managed: you can read it but you cannot edit it. Quota changes go through an RCS ticket — see Requesting quota changes.

Grafana tenant dashboard

A Grafana view of the same numbers, with trend lines per namespace, is available through the cluster monitoring stack. See Monitoring for how to access the Grafana dashboards and which panels map to tenant quota.

No dashboards when you log in?

Every authenticated user receives at least the Grafana Viewer role. If you log in and see no dashboards or datasources, use the kubectl commands above to check your allocation, and open an RCS support ticket.

Common “why is my quota used up” scenarios

Completed Jobs (not a quota consumer)

Kubernetes Jobs that have finished (Completed status) keep their Pods around until the Job’s ttlSecondsAfterFinished expires or you delete them manually. Those leftover Pods are in a terminal phase (Succeeded or Failed), and terminal-phase Pods do not count against CPU and memory quota — deleting finished Jobs will not free up compute quota.

Cleaning them up is still good hygiene: stale Pods clutter kubectl get pods output, and deleting a Job also deletes its Pods’ logs, so grab anything you need first. Set ttlSecondsAfterFinished in the Job spec to have Kubernetes remove finished Jobs automatically:

spec:
  ttlSecondsAfterFinished: 86400  # remove the Job and its Pods a day after completion

If a Job created PVCs, those are a different story: PVCs are not removed with the Job and keep counting against requests.storage — see PVCs consuming storage quota.

Pods stuck in Pending

A Pod in Pending state has its requests reserved by the scheduler but is not actually running. If you have Pods stuck pending due to a scheduling constraint (node affinity, resource shortage, etc.), they are consuming quota without doing work.

kubectl get pods -n <your-tenant>-<any-namespace> --field-selector=status.phase=Pending

Check why the Pod is pending:

kubectl describe pod <pod-name> -n <your-tenant>-<any-namespace>

The Events section tells you what the scheduler is waiting for.

PVCs consuming storage quota

PersistentVolumeClaims count against requests.storage even if the volume is not mounted by any Pod. Orphaned PVCs from deleted Deployments or Jobs can silently eat your storage budget.

kubectl get pvc -n <your-tenant>-<any-namespace>

Delete PVCs you no longer need — but check the reclaim policy first. The default storage class (csi-cinder-sc-delete) uses Delete reclaim, so deleting the PVC destroys the backing volume. Use csi-cinder-sc-retain if you need the backing volume to survive PVC deletion.

Overprovisioned requests and limits

If your Pods set requests and limits much higher than what they actually use, you are reserving quota you do not need. Review your workloads’ actual resource consumption (via kubectl top pod or Grafana) and right-size the requests and limits in your manifests.

Who to ask when the numbers look wrong

If kubectl describe resourcepool shows numbers that do not add up — for example, Used exceeds the sum of your visible Pods’ requests — the most common cause is a namespace you have forgotten about (remember, all namespaces under your tenant prefix share the pool):

kubectl get ns | grep <your-tenant>

This lists every namespace in your tenant. Check each one for running workloads and leftover PVCs. If the numbers still do not add up after reviewing every namespace, open a ticket with RCS.