Running multiple teams or customers on a shared Kubernetes cluster is one of the hardest platform engineering problems. Get it wrong and you have noisy neighbours, blast radius nightmares, and compliance failures. Get it right and you have a self-service platform that makes your engineering teams dramatically more productive.
The Three Multi-Tenancy Models
Namespace-per-tenant is soft multi-tenancy where each tenant gets one or more namespaces, with network policies, RBAC, and resource quotas providing isolation on shared nodes. This is the most common model and works well for internal platform teams where tenants are trusted. Node-pool-per-tenant gives each tenant dedicated node pools via node selectors or taints and tolerations with no cross-tenant pod scheduling. This costs more but provides strong noisy-neighbour protection and is common in regulated industries. Cluster-per-tenant provides maximum isolation and is justified for large enterprise customers or strict compliance requirements such as PCI DSS scope separation.
Namespace Isolation: The Foundation
Whatever model you choose, namespace isolation is the foundation. ResourceQuotas cap CPU, memory, and object counts per namespace. LimitRanges set default and maximum resource requests and limits for pods. NetworkPolicies should deny all ingress and egress by default, then allowlist explicitly. RBAC should use namespace-scoped roles and never cluster-admin for tenant service accounts. PodSecurityAdmission should enforce restricted or baseline pod security standards.
The Noisy Neighbour Problem
Even with ResourceQuotas, a tenant running CPU-intensive batch jobs can steal I/O or network bandwidth from neighbours. Solutions include node taints and tolerations to schedule sensitive workloads on dedicated nodes, PriorityClasses to give critical workloads preemption priority, and Karpenter NodePools to provision tenant-specific node groups on demand.
GitOps for Multi-Tenancy
The cleanest multi-tenant GitOps pattern uses one Git repository per tenant, ArgoCD ApplicationSet templating across all tenants, and a platform team repository that owns cluster-wide policies. The platform repository contains NetworkPolicies, PodSecurityAdmission, and OPA Gatekeeper policies. Tenant repositories contain their own Helm charts, Kustomize overlays, and application manifests. ArgoCD AppProject per tenant limits which repositories and namespaces a tenant can deploy to.
Secret Isolation
Secrets are the most common multi-tenancy failure point. External Secrets Operator with per-tenant AWS Secrets Manager paths or Vault namespaces provides strong isolation. Sealed Secrets with namespace-scoped keys ensures a secret sealed for one namespace cannot be decrypted in another. Cluster-scoped secrets should never be used for tenant data.
Compliance and Audit
For PCI DSS and SOC 2, multi-tenancy requires demonstrating that cardholder data environments are isolated from non-CDE workloads. Network policy audits prove no cross-namespace traffic is possible for CDE namespaces. RBAC audits demonstrate minimum privilege for all tenant service accounts. OPA Gatekeeper or Kyverno enforce policies that prevent tenants escaping their namespace. Falco provides runtime security monitoring for suspicious cross-namespace behaviour.
Conclusion
Multi-tenant Kubernetes is not a single architecture — it is a spectrum of isolation tradeoffs. The teams that succeed build the isolation controls first, then build the self-service developer experience on top. The platform that makes tenants productive while keeping blast radius contained is the one engineers will actually use.