Kubernetes Multi Tenancy
Share a Kubernetes cluster in a secure way with multiple users, teams, and departments.
Avoid clusters sprawl, reduce costs, and save from the operational burden.
Kubernetes Single Tenancy vs Multi-Tenancy
Implementing a multi-tenancy architecture in Kubernetes is one of the most strategic decisions, as it has long term implications to operational efficiency, scale velocity and cost.
Cost
With single-tenancy, an admin has to setup a separate cluster for each user, group, or department. Each cluster has its own components and all these components have to be deployed for each tenant, so single tenancy costs more per tenant. With multi-tenancy, because a cluster is shared between several tenants, there are less cost for cluster components, and so lower cost per tenant.
Agility
The journey to a kubernetes-based infrastructure usually starts small and scales rapidly after validation. In this journey, while the lack of a robust multi-tenancy architecture may not be impactful in smaller deployments, it becomes a serious issue as companies scale, and ultimately need to manage and pay for larger infrastructure. Hence making a multi-tenancy decision early is very important.
Operations
Adopting the one cluster per tenant model, the operations team has to manage multiple clusters requiring more management overhead, monitoring, compliance and security. Kubernetes deployment is complex and time consuming. You can automate or rely on a managed service like EKS, AKS, GKE, however adopting a multi-tenant modes there is less overhead and complexity.
Kubernetes Multi-Tenancy Types
Typically virtualisation makes things easier to use by enabling agility and new usage models. Multi-tenancy is all about virtualise Kubernetes.
Native Multi Tenancy
Kubernetes is not a multi-tenant system out of the box. While it is possible to configure isolation through namespaces, implementing a true multi-tenancy is challenging because of the flat nature of namespaces. Cluster resources cannot be shared between multiple namespaces belonging to the same tenant, so native Kubernetes multi-tenancy is only limited to few and simpler use cases.
Soft Multi Tenancy
Soft multi-tenancy involves isolating only some components, usually nodes for workload while sharing other parts, usually the control plane. This is most suitable for friend tenants, the main use case is several projects or departments running workloads in the same organisation. In these scenarios, the intention of multi-tenancy is to prevent accidental access and assist with separation of concerns between tenants.
Hard Multi Tenancy
Hard multi-tenancy enforces stricter tenant isolation, preventing any negative impact from another tenant, including malicious behaviour. This model allows for hostile tenants, such as serving infrastructure to many different organisations or public services. Implementing hard multi-tenancy in Kubernetes requires a more complex setup, for example, creating a virtual cluster configuration for each tenant.
Free Assessment
Start building your self-service and multi-tenant Kubernetes platform with help of Clastix engineers.