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:

Spec:
  Hard:
    limits.cpu:             8
    limits.memory:          16Gi
    requests.cpu:           8
    requests.memory:        16Gi
    requests.storage:       50Gi
Status:
  Used:
    limits.cpu:             3
    limits.memory:          6Gi
    requests.cpu:           2
    requests.memory:        4Gi
    requests.storage:       20Gi

• Hard is the ceiling — the maximum your tenant’s workloads can claim across all namespaces.
• Used is the sum of what your running workloads currently claim (the sum of all Pod requests and limits plus all PVC sizes) across the whole tenant.

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.

Grafana access requires UVic Staff role

Tenant owners who are not in the UVic Staff group are assigned the Grafana role None and will not see any dashboards. If you log into Grafana and have no dashboards, use the kubectl commands above to check your allocation, and contact RCS if you need dashboard access.

Common “why is my quota used up” scenarios

Completed Jobs still consuming quota

Kubernetes Jobs that have finished (Completed status) still have their Pods present until the Job’s ttlSecondsAfterFinished expires or you delete them manually. Those Pods’ requests and limits count against your ResourcePool even though they are not running.

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

Delete completed Job Pods to reclaim quota:

kubectl delete job <job-name> -n <your-tenant>-<any-namespace>

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 — open a ticket with RCS. 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.