Kubernetes Namespaces — multi-tenancy in practice

One Kubernetes cluster, five teams, three clients. How to ensure isolation, fair resource sharing and prevent one team from consuming all resources from others? Namespaces with Resource Quotas.

Namespace per tenant¶

Each team/client gets their own namespace: team-alpha, client-bank, client-insurance. Combined with RBAC, this is the basic building block of multi-tenancy.

Resource Quotas¶

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "50"
    services: "20"

Team Alpha has guaranteed 8 CPU and 16 GB RAM. They can burst up to 16 CPU and 32 GB, but no more. Maximum 50 pods.

LimitRange — defaults for pods¶

LimitRange sets default requests and limits for pods that don’t specify them. Protection against “pod without limits that consumes the entire node.”

Network Policies per namespace¶

Default deny in each namespace + explicit allow. Namespace team-alpha cannot communicate with client-bank. Network-level isolation.

Access limitations¶

• RBAC: admin in namespace, read-only in cluster
• Resource Quotas: fair sharing of compute resources
• Network Policies: network isolation
• Pod Security Policies: security restrictions

Soft multi-tenancy is achievable¶

Namespaces with RBAC, quotas and network policies provide sufficient isolation for teams within one organization. For hard multi-tenancy (untrusted tenants) consider separate clusters.