Limits & rules

Your resource budget

Each tenant namespace has a quota. These are the per-namespace caps:

Resource	Limit
CPU (requests)	2 cores
CPU (limits)	4 cores
Memory (requests)	4 Gi
Memory (limits)	8 Gi
Pods	10
PersistentVolumeClaims	4
Storage (total)	20 Gi
GPU	0 (ask the admin)

If a deploy is rejected with an exceeded quota error, you’ve hit one of these. Either scale down or ask for more.

Always set resource requests

Because a quota is in effect, every container must declare CPU and memory requests/limits, or the pod will be rejected. A LimitRange applies sane defaults if you forget, but it’s best to set them explicitly (see the example in Deploy an app).

Isolation

Your pods run inside lightweight VMs (Kata Containers), not plain containers. You won’t notice any difference day-to-day, but it means even a full container breakout can’t reach the host kernel or another tenant. Combined with per-namespace network policies, your workloads are sealed off from everyone else’s.

What you can do

Inside your own namespace you have edit rights — create, update, and delete: Deployments, Pods, Services, Ingresses, ConfigMaps, Secrets, PersistentVolumeClaims, Jobs, CronJobs.

What you can’t do

• See or touch other namespaces — your view is scoped to tenant-<you>.
• List nodes or cluster-wide resources — kubectl get nodes will be Forbidden. That’s expected.
• Change your own quota or RBAC — those are admin-only.
• Run privileged / host-mounted pods — blocked by Pod Security. Keep workloads unprivileged.
• Use the GPU — it’s a single shared card; GPU quota is 0 by default. Ask if you need it.

Storage notes

Storage is node-local (local-path). Two consequences:

• A PersistentVolumeClaim pins its pod to the node where the volume was created.
• There’s no shared (RWX) storage — two pods can’t mount the same volume across nodes.

Fine for most stateful apps (a database, a cache). If you need shared storage, talk to the admin.