Multi-tenancy and isolation
Soft vs hard multi-tenancy — namespaces, quotas, network and security boundaries between teams.
Most clusters are shared. Multi-tenancy is how you keep one team from taking another down — or reading their Secrets.
Soft multi-tenancy (common)
Shared control plane and nodes; isolation via namespaces, RBAC, NetworkPolicies, quotas, and Pod Security. Good enough for many internal platforms when teams are trusted and policies are enforced.
Harder isolation
Separate node pools (taints), separate clusters per env/team, or sandbox runtimes. Regulated workloads and untrusted compute push you here. Cost and ops complexity rise with isolation strength.
What namespaces do not give you
They do not encrypt memory between Pods on a node or stop every kernel exploit. Treat node compromise as cross-tenant risk unless you isolate nodes/clusters.
Fairness
ResourceQuotas + LimitRanges + priority classes prevent noisy neighbors from scheduling the cluster into failure. Without quotas, soft tenancy is a gentleman’s agreement.
API and add-on blast radius
Cluster-scoped CRDs and cluster-admin bindings pierce tenant illusions. Minimize cluster-wide privileges; review every ClusterRoleBinding.
Choose deliberately
Document the tenancy model for your platform. Product teams should know whether they share nodes, what policies apply, and how to request exceptions — not discover isolation during an incident.