[{"data":1,"prerenderedAt":353},["ShallowReactive",2],{"blog-en-kubernetes-multi-tenancy-capsule-namespace-isolation":3,"blog-related-en-kubernetes-multi-tenancy-capsule-namespace-isolation":303,"blog-en-kubernetes-multi-tenancy-capsule-namespace-isolation-alt":291},{"id":4,"title":5,"author":6,"body":7,"date":285,"description":286,"extension":287,"image":288,"locale":289,"meta":290,"navigation":291,"path":292,"seo":293,"stem":294,"tags":295,"__hash__":302},"blog\u002Fblog\u002Fen\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation.md","Splitting by Namespace Isn't Isolation. How Capsule Solves Kubernetes Multi-Tenancy","Kubo Team",{"type":8,"value":9,"toc":269},"minimark",[10,15,19,26,37,46,51,59,68,72,86,92,108,125,129,132,138,142,151,155,168,172,181,185,188,194,214,222,241,245,248,251],[11,12,14],"h2",{"id":13},"_1-a-namespace-is-a-shelf-not-a-boundary","1. A Namespace Is a Shelf, Not a Boundary",[16,17,18],"p",{},"When designing multi-tenancy in Kubernetes, the first idea that comes to mind is usually \"just split each tenant into its own namespace.\" In practice, many teams run multiple business units or client workloads on a single cluster this way.",[16,20,21],{},[22,23],"img",{"alt":24,"src":25},"Comparison of namespace boundaries","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Fsection01.webp",[16,27,28,29,36],{},"But the ",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Fmulti-tenancy\u002F",[34],"nofollow","Kubernetes official documentation"," is explicit about the limits here: the namespace-based isolation model \"requires strict adherence to several other Kubernetes resources, network plugins, and security best practices.\" In other words, a namespace only provides a \"scope\" for separating resource names and applying RBAC or NetworkPolicy — actually keeping those policies correctly configured for every tenant remains a manual, ongoing operational task.",[16,38,39,40,45],{},"As the number of tenants grows to 5, 10, or more, this manual consistency starts to break down. A NetworkPolicy gets forgotten in one namespace; a ResourceQuota is left with an outdated limit in another — this kind of policy drift is a common failure mode. ",[30,41,44],{"href":42,"rel":43},"https:\u002F\u002Fwww.sysdig.com\u002Fjp\u002Fblog\u002Fmulti-tenant-isolation-boundaries-kubernetes",[34],"Sysdig's blog"," also points out that each of the three isolation boundaries — control plane\u002FAPI, host, and network — requires its own explicit RBAC least-privilege design and NetworkPolicy enforcement.",[47,48,50],"h3",{"id":49},"kubernetes-multi-tenancy-is-a-spectrum","Kubernetes Multi-Tenancy Is a Spectrum",[16,52,53,54,58],{},"The Kubernetes documentation explains that multi-tenancy shouldn't be framed as a binary choice between \"soft\" and \"hard\" isolation, but as a ",[55,56,57],"strong",{},"spectrum"," of isolation techniques to choose from based on requirements. Soft isolation is sufficient for internal teams that already trust each other, while SaaS-style use cases hosting untrusted external customers need stronger (hard) multi-tenancy. Failing to understand this premise — and assuming \"splitting namespaces\" alone is enough — is exactly what sets the stage for incidents.",[16,60,61,62,67],{},"This policy management overhead is also something worth reconsidering at the point of choosing a managed Kubernetes platform. With a platform like ",[30,63,66],{"href":64,"rel":65},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo",", which is built with tenant management as an operational default, you don't need to rebuild this kind of mechanism from scratch.",[11,69,71],{"id":70},"_2-capsules-answer-declaring-a-group-of-namespaces-via-the-tenant-crd","2. Capsule's Answer — Declaring a \"Group of Namespaces\" via the Tenant CRD",[16,73,74,79,80,85],{},[30,75,78],{"href":76,"rel":77},"https:\u002F\u002Fgithub.com\u002Fprojectcapsule\u002Fcapsule",[34],"Capsule",", accepted as a CNCF Sandbox project, offers a clear solution to this problem. Capsule was accepted at the CNCF Sandbox level on December 13, 2022 (",[30,81,84],{"href":82,"rel":83},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fcapsule\u002F",[34],"CNCF Capsule project page","), and is an OSS project that implements a \"multi-tenant, policy-based environment\" on a Kubernetes cluster.",[16,87,88],{},[22,89],{"alt":90,"src":91},"Architecture diagram of the Capsule Tenant CRD","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Fsection02.webp",[16,93,94,95,98,99,103,104,107],{},"At the core of Capsule is a custom resource (CRD) called ",[55,96,97],{},"Tenant",". According to the ",[30,100,102],{"href":76,"rel":101},[34],"official GitHub repository",", the Tenant CRD groups multiple namespaces into a \"lightweight abstraction.\" Administrators only need to define NetworkPolicy, Security Policy, ResourceQuota, LimitRange, and RBAC settings at the tenant level, and these are ",[55,105,106],{},"automatically inherited by every namespace belonging to that tenant",". There's no need to reconfigure policies every time a new namespace is added.",[16,109,110,111,114,115,118,119,124],{},"Equally important is the idea of \"self-service delegation.\" Within the boundaries assigned to a tenant, development teams can autonomously create namespaces and deploy applications ",[55,112,113],{},"without cluster administrator intervention",". Capsule is designed as \"a minimalist, microservice-based ecosystem that leverages only upstream Kubernetes\" (",[30,116,84],{"href":82,"rel":117},[34],"), achieving this purely through admission webhooks and CRDs. Cluster administrators only need to design the tenant framework, while day-to-day namespace management is delegated to each team — making it possible to balance operational load with governance. The ",[30,120,123],{"href":121,"rel":122},"https:\u002F\u002Fzesty.co\u002Ffinops-glossary\u002Fcapsule-kubernetes\u002F",[34],"FinOps media outlet Zesty"," also describes Capsule as \"an operator that groups multiple namespaces into lightweight virtual clusters called tenants, enabling efficient and secure workload isolation,\" highlighting its ability to enforce tenant-level policy without handing out cluster administrator privileges.",[11,126,128],{"id":127},"_3-soft-vs-hard-isolation-how-vcluster-and-hnc-differ","3. \"Soft\" vs \"Hard\" Isolation — How vCluster and HNC Differ",[16,130,131],{},"Beyond Capsule, several other OSS projects tackle the Kubernetes multi-tenancy problem, each with a different tradeoff between isolation strength and operational cost, worth laying out clearly.",[16,133,134],{},[22,135],{"alt":136,"src":137},"Comparison of Capsule, vCluster, and HNC","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Fsection03.webp",[47,139,141],{"id":140},"capsule-soft-multi-tenancy","Capsule — Soft Multi-Tenancy",[16,143,144,145,150],{},"Capsule takes a \"soft\" isolation approach centered on namespaces and admission webhooks. ",[30,146,149],{"href":147,"rel":148},"https:\u002F\u002Fwww.vcluster.com\u002Fblog\u002Fcomparing-multi-tenancy-options-in-kubernetes",[34],"vCluster's official blog comparison"," points out that namespace-based multi-tenancy \"lacks true tenant isolation, leaving globally shared resources like ClusterRole and PersistentVolume in place,\" while positioning Capsule as mitigating this weakness through automatic policy inheritance. Because it shares the same API server and control plane across multiple tenants, its resource overhead stays low.",[47,152,154],{"id":153},"vcluster-hard-isolation-via-a-virtual-control-plane","vCluster — Hard Isolation via a Virtual Control Plane",[16,156,157,161,162,167],{},[30,158,160],{"href":147,"rel":159},[34],"vCluster",", on the other hand, takes the approach of running a dedicated virtual control plane (its own API server, controller-manager, and scheduler) for each tenant inside the host cluster. Workloads themselves are synced back to the host cluster, but each tenant gets its own Kubernetes API, allowing different CRDs or API versions per tenant. The tradeoff is that running multiple control planes increases both resource consumption and operational complexity. For cases like financial institutions or healthcare providers that require per-tenant data sovereignty or fully air-gapped operation, pairing this approach with a platform built for air-gapped environments, such as ",[30,163,166],{"href":164,"rel":165},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[34],"Kubo On-Premise",", becomes a viable option.",[47,169,171],{"id":170},"hnc-hierarchical-namespace-inheritance","HNC — Hierarchical Namespace Inheritance",[16,173,174,175,180],{},"The ",[30,176,179],{"href":177,"rel":178},"https:\u002F\u002Fgithub.com\u002Fkubernetes-sigs\u002Fhierarchical-namespaces",[34],"Hierarchical Namespace Controller (HNC)"," gives namespaces parent-child relationships, automatically propagating RBAC RoleBindings and ResourceQuotas down to child namespaces. Like Capsule, it lets you delegate namespace creation — normally requiring cluster-level permissions — down to a team's own namespace. However, as also noted in vCluster's blog comparison, cluster-scoped resources like ClusterRole and PersistentVolume sit outside the hierarchy and remain global. HNC is fundamentally a tool for \"structuring and managing namespaces,\" not a mechanism for enforcing comprehensive tenant boundaries the way Capsule does.",[11,182,184],{"id":183},"_4-which-approach-should-you-choose-decision-criteria","4. Which Approach Should You Choose? — Decision Criteria",[16,186,187],{},"The three approaches can be organized along two axes: isolation strength and operational cost.",[16,189,190],{},[22,191],{"alt":192,"src":193},"Decision flowchart for isolation strength vs operational cost","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Fsection04.webp",[195,196,197,204,209],"ul",{},[198,199,200,203],"li",{},[55,201,202],{},"HNC",": Lowest operational cost, but cannot isolate cluster-scoped resources. Best suited for delegating namespace management among internal teams that already share the same trust level.",[198,205,206,208],{},[55,207,78],{},": Compensates for namespace isolation's weaknesses through automatic policy inheritance, offering a good balance of cost and isolation. Well suited for sharing a cluster across multiple trusted business units or teams.",[198,210,211,213],{},[55,212,160],{},": Provides the strongest isolation (at the virtual control plane level), at the cost of increased operational complexity and resource overhead. Best suited for SaaS-style use cases hosting untrusted external customers, or when tenants need different Kubernetes versions or CRDs.",[16,215,216,221],{},[30,217,220],{"href":218,"rel":219},"https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fbest-practices\u002Fenterprise-multitenancy?hl=ja",[34],"Google Cloud's GKE multi-tenancy best practices"," also recommend, as a baseline, the combination of dedicated per-tenant namespaces, NetworkPolicy-based traffic control, Admission Control enforcing security standards, and namespace-level ResourceQuota settings. In other words, what Capsule automates is exactly the set of components that would otherwise need to be manually assembled even on a managed service like GKE.",[16,223,224,225,228,229,234,235,240],{},"Designing and operating this setup from scratch is no small amount of engineering work. This is precisely where it becomes valuable to have tenant management built into a managed Kubernetes platform as a core feature. ",[30,226,66],{"href":64,"rel":227},[34]," comes with a ",[30,230,233],{"href":231,"rel":232},"https:\u002F\u002Fwww.rancher.com\u002F",[34],"Rancher","-based management foundation as standard, letting you operate while visualizing multi-cluster, multi-tenant state. Built on ",[30,236,239],{"href":237,"rel":238},"https:\u002F\u002Fk3s.io\u002F",[34],"K3s",", a lightweight Kubernetes distribution, it also offers strong cost efficiency compared to EKS\u002FAKS. For teams that want to build tenant-level policy management into their setup from day one, it's worth considering as an option.",[11,242,244],{"id":243},"_5-summary","5. Summary",[16,246,247],{},"Namespace isolation is a starting point for Kubernetes multi-tenancy, not an endpoint. Unless you solve the design problem of consistently enforcing policy at the tenant level, the risk of incidents keeps compounding as the number of tenants grows.",[16,249,250],{},"Capsule offers a practical option: layering a lightweight abstraction — the Tenant CRD — on top of the existing namespace model to achieve automatic inheritance of NetworkPolicy, ResourceQuota, and RBAC, along with self-service delegation. If you need stronger isolation, vCluster is an option; if you just want to structure your existing namespaces hierarchically, HNC is another. Understanding each tradeoff and identifying the isolation strength your cluster actually needs is the first step toward good multi-tenant design.",[16,252,253,254,258,259,262,263,268],{},"If you're planning to share a single Kubernetes cluster across multiple business units or clients, it's worth considering handing this kind of tenant isolation over to a managed platform rather than building it from scratch. Reach out via ",[30,255,257],{"href":64,"rel":256},[34],"Kubo Cloud",", or for environments requiring stricter data sovereignty, ",[30,260,166],{"href":164,"rel":261},[34]," — get in touch through our ",[30,264,267],{"href":265,"rel":266},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"contact page",".",{"title":270,"searchDepth":271,"depth":271,"links":272},"",2,[273,277,278,283,284],{"id":13,"depth":271,"text":14,"children":274},[275],{"id":49,"depth":276,"text":50},3,{"id":70,"depth":271,"text":71},{"id":127,"depth":271,"text":128,"children":279},[280,281,282],{"id":140,"depth":276,"text":141},{"id":153,"depth":276,"text":154},{"id":170,"depth":276,"text":171},{"id":183,"depth":271,"text":184},{"id":243,"depth":271,"text":244},"2026-07-25","Splitting environments by namespace doesn't automatically carry over policies or resource limits. This article breaks down the pitfalls of Kubernetes multi-tenancy and compares three practical solutions: Capsule, vCluster, and HNC.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation\u002Feyecatch.webp","en",{},true,"\u002Fblog\u002Fen\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation",{"title":5,"description":286},"blog\u002Fen\u002Fkubernetes-multi-tenancy-capsule-namespace-isolation",[296,297,298,299,300,301],"k3s","kubernetes","multi-tenancy","capsule","namespace","managed-kubernetes","mkJJhQ8GqjsS1NAK06CxXPUnjLVCqpl6qBwk00RD9j4",[304,312,320,328,337,345],{"path":305,"title":306,"description":307,"date":308,"tags":309},"\u002Fblog\u002Fen\u002Fkubernetes-namespace-environment-cost-design","How Many Environments Do You Really Need? Kubernetes Environment Design That Doesn't Break the Bank","Every new dev, test, and staging environment adds to your Kubernetes cloud bill. Learn how namespace isolation, ResourceQuota, and a hybrid dedicated-cluster-for-production model balance cost and isolation.","2026-07-21",[297,296,300,310,301,311],"cost-optimization","resource-quota",{"path":313,"title":314,"description":315,"date":316,"tags":317},"\u002Fblog\u002Fen\u002Fkubevirt-calico-live-migration-networking","Moving a VM Doesn't Have to Break the Connection: Inside KubeVirt and Calico's Live Migration Magic","Why doesn't live migrating a VM (KubeVirt) between Kubernetes nodes break the connection? We break down Calico's IP persistence and BGP route convergence, and what it means for teams moving off VMware.","2026-08-07",[296,297,318,319,301],"kubevirt","networking",{"path":321,"title":322,"description":323,"date":324,"tags":325},"\u002Fblog\u002Fen\u002Fai-generated-kubernetes-manifest-resource-overprovisioning","Kubernetes Resource Design Can't Be Left to AI: Why 'Working' YAML Is Wasting 69% of Your Cloud Bill","AI-generated Kubernetes manifests pass kubectl apply and 'work' — but getting Kubernetes resource design wrong drives massive overprovisioning. Here's why AI struggles with production-grade requests\u002Flimits and what to check before you ship.","2026-08-04",[296,297,326,327,301],"resource-management","capacity-planning",{"path":329,"title":330,"description":331,"date":332,"tags":333},"\u002Fblog\u002Fen\u002Fkubernetes-microservices-chatty-calls-latency","One Order, Five Hidden Service Calls: The Real Cause of Latency in Kubernetes Microservices' \"Chatty Calls\"","A single checkout request was quietly triggering five separate service calls behind the scenes. The culprit isn't bad code — it's the \"chatty call\" architecture that Kubernetes microservices tend to fall into. This article explains the distributed N+1 problem and how to fix it.","2026-08-02",[297,296,334,335,336,301],"microservices","service-mesh","latency",{"path":338,"title":339,"description":340,"date":341,"tags":342},"\u002Fblog\u002Fen\u002Fkubernetes-ai-inference-reversal-conformance-design","Inference Has Overtaken Training: What KubeCon Japan Revealed About Kubernetes Cluster Design in the AI Era","AI compute demand has flipped from training to inference, with inference compute projected to reach 1.5x training capacity by 2030. Drawing on KubeCon Japan discussions and the CNCF AI Conformance Program, this article outlines what Kubernetes\u002FK3s clusters need to look like in the inference era.","2026-08-01",[297,296,343,344,301],"ai-inference","cncf",{"path":346,"title":347,"description":348,"date":349,"tags":350},"\u002Fblog\u002Fen\u002Fhybrid-k3s-edge-metrics-network-overhead","2,000 IoT Devices Were Clogging the Network. The Day Push Metrics Bit Back in a Hybrid K3s Deployment","A field report from a large-scale K3s edge deployment covering 2,000+ devices: why lightweight Kubernetes gets chosen, and the hidden network cost of push-based metrics collection in a hybrid cluster architecture, backed by concrete numbers. For engineers and platform operators.","2026-07-31",[296,297,351,352,301],"edge-computing","hybrid-cluster",1786701443299]