DevOps & Kubernetes (50 Qs)•Part 3: Production K8s Scaling, Reliability & SRE (26 - 35)
Multi-Tenant Cluster Isolation: ResourceQuotas, LimitRanges, NetworkPolicies, and Virtual Clusters (vcluster).
Hard vs. Soft Multi-Tenancy
When multiple teams share a single physical Kubernetes cluster, the platform team must implement boundaries to prevent noisy neighbors and security breaches.
yaml
+-------------------------------------------------------------------------------+
| Shared Physical EKS / GKE Cluster |
| |
| +-------------------------------+ +-------------------------------+ |
| | Namespace: team-alpha | | Namespace: team-beta | |
| | - ResourceQuota: max 16 Cores | | - ResourceQuota: max 32 Cores | |
| | - LimitRange: default 500m | | - LimitRange: default 1 Core | |
| | - NetworkPolicy: Deny Ingress | <---X | - NetworkPolicy: Deny Ingress | |
| +-------------------------------+ +-------------------------------+ |
| |
| [ Advanced Isolation: vcluster (Virtual API Server & etcd inside a Pod) ] |
+-------------------------------------------------------------------------------+
Multi-Tenancy Guardrail Stack
- ResourceQuota: Limits the aggregate compute consumption of a namespace (e.g. max 32 cores, 64Gi RAM, max 20 LoadBalancer services).
- LimitRange: Sets default and minimum/maximum resource constraints on individual containers in a namespace if developers omit them.
- NetworkPolicy: Isolates inter-namespace communication (blocks Team Beta from accessing Team Alpha’s Redis instance).
- Virtual Clusters (vcluster): Runs a lightweight virtual control plane (API Server and SQLite/etcd) inside a single namespace on the host cluster. Tenants get full
cluster-adminrights to create CRDs and namespaces without risk of compromising the underlying physical cluster.